Message ID | 20210723193444.133412-1-peterx@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | memory: Sanity checks memory transaction when releasing BQL | expand |
On Fri, Jul 23, 2021 at 03:34:35PM -0400, Peter Xu wrote: > This is v2 of the series. It was actually got forgotten for months until it > was used to identify another potential issue of bql usage here (besides it > could still be helpful when debugging a previous kvm dirty ring issue in that > series): > > https://lore.kernel.org/qemu-devel/CH0PR02MB7898BBD73D0F3F7D5003BB178BE19@CH0PR02MB7898.namprd02.prod.outlook.com/ > > So I figured maybe it's still worth to have it, hence a repost. > > There're some changes against v1: > > - patch "cpus: Introduce qemu_cond_timedwait_iothread()" is dropped because > it's introduced in another commit already (b0c3cf9407e64). > > - two more patches to move do_run_on_cpu() into softmmu/ to fix a linux-user > compliation issue. > > Please review, thanks. > > === Original Cover letter === > > This is a continuous work of previous discussion on memory transactions [1]. > It should be helpful to fail QEMU far earlier if there's misuse of BQL against > the QEMU memory model. > > One example is run_on_cpu() during memory commit. That'll work previously, but > it'll fail with very strange errors (like KVM ioctl failure due to memslot > already existed, and it's not guaranteed to trigger constantly). Now it'll > directly fail when run_on_cpu() is called. > > Please have a look, thanks. > > [1] https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03205.html CC Phil too.
On 23.07.21 21:34, Peter Xu wrote: > This is v2 of the series. It was actually got forgotten for months until it > was used to identify another potential issue of bql usage here (besides it > could still be helpful when debugging a previous kvm dirty ring issue in that > series): > > https://lore.kernel.org/qemu-devel/CH0PR02MB7898BBD73D0F3F7D5003BB178BE19@CH0PR02MB7898.namprd02.prod.outlook.com/ > > So I figured maybe it's still worth to have it, hence a repost. > > There're some changes against v1: > > - patch "cpus: Introduce qemu_cond_timedwait_iothread()" is dropped because > it's introduced in another commit already (b0c3cf9407e64). > > - two more patches to move do_run_on_cpu() into softmmu/ to fix a linux-user > compliation issue. > > Please review, thanks. > > === Original Cover letter === > > This is a continuous work of previous discussion on memory transactions [1]. > It should be helpful to fail QEMU far earlier if there's misuse of BQL against > the QEMU memory model. > > One example is run_on_cpu() during memory commit. That'll work previously, but > it'll fail with very strange errors (like KVM ioctl failure due to memslot > already existed, and it's not guaranteed to trigger constantly). Now it'll > directly fail when run_on_cpu() is called. > Functions that silently drop the BQL are really nasty. I once fall into a similar trap calling pause_all_vcpus() from within memory_region_transaction_begin(), while resizing RAM blocks.
On Tue, Jul 27, 2021 at 02:41:17PM +0200, David Hildenbrand wrote: > Functions that silently drop the BQL are really nasty. I once fall into a > similar trap calling pause_all_vcpus() from within > memory_region_transaction_begin(), while resizing RAM blocks. Yes, hopefull the series can help all these cases too. Thanks for reviewing!