Re: [Qemu-devel] [PATCH v19 3/9] pc: add a Virtual Machine Generation ID device

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 09, 2016 at 11:46:08AM +0100, Igor Mammedov wrote:
> > > > > 2. ACPI approach consumes guest usable RAM to allocate buffer
> > > > >    and then makes device to DMA data in that RAM.
> > > > >    That's a design point I don't agree with.    
> > > > 
> > > > Blame the broken VM GEN ID spec.
> > > > 
> > > > For VM GEN ID, instead of DMA we could make ACPI code read PCI BAR and
> > > > copy data over, this would fix rebalancing but there is a problem with
> > > > this approach: it can not be done atomically (while VM is not yet
> > > > running and accessing RAM).  So you can have guest read a partially
> > > > corrupted ID from memory.  
> > > 
> > > Yep, VM GEN ID spec is broken and we can't do anything about it as
> > > it's absolutely impossible to guaranty atomic update as guest OS
> > > has address of the buffer and can read it any time. Nothing could be
> > > done here.  
> > 
> > Hmm I thought we can stop VM while we are changing the ID.
> > But of course VM could be accessing it at the same time.
> > So I take this back, ACPI code reading PCI BAR and
> > writing data out to the buffer would be fine
> > from this point of view.
> spec is broken regardless of who reads BAR or RAM as read
> isn't atomic and UUID could be updated in the middle.
> So MS will have to live with that, unless they have a secret
> way to tell guest stop reading from that ADDR, do update and
> signal guest that it can read it.

And really, that the issue that's driving this up to v19.  There's no
good way to implement a bad spec.  It feels more like a failed
experiment than like a thought through interface.  So maybe we should
leave this alone, wait until we see an actual user - this way we can
figure out the implementation constraints better.

-- 
MST