Re: [Qemu-devel] Windows balloon driver PFN issue

[Peter Xu <peterx@redhat.com>]

On Thu, Feb 01, 2018 at 04:24:40AM +0200, Michael S. Tsirkin wrote:
> On Thu, Feb 01, 2018 at 10:18:53AM +0800, Peter Xu wrote:
> > On Wed, Jan 31, 2018 at 04:03:12PM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Jan 31, 2018 at 05:28:35PM +0800, Peter Xu wrote:
> > > > Hi, Michael and the list,
> > > > 
> > > > I observed this on windows 8 enterprise guests, when doing memory ballooning:
> > > > 
> > > > 23892@1517298572.328354:virtio_balloon_to_target balloon target: 0x80000000 num_pages: 524288
> > > > 23892@1517298638.542819:virtio_balloon_get_config num_pages: 524288 actual: 0
> > > > 23892@1517298638.542974:virtio_balloon_handle_output section name: pc.ram gpa: 0x174604000
> > > > 23892@1517298638.543059:virtio_balloon_handle_output section name: pc.ram gpa: 0x0
> > > > 23892@1517298638.543135:virtio_balloon_handle_output section name: pc.ram gpa: 0x17460a000
> > > > 23892@1517298638.543140:virtio_balloon_handle_output section name: pc.ram gpa: 0x0
> > > > 23892@1517298638.543143:virtio_balloon_handle_output section name: pc.ram gpa: 0x17460b000
> > > > 23892@1517298638.543146:virtio_balloon_handle_output section name: pc.ram gpa: 0x0
> > > > 23892@1517298638.543148:virtio_balloon_handle_output section name: pc.ram gpa: 0x17460c000
> > > > 23892@1517298638.543152:virtio_balloon_handle_output section name: pc.ram gpa: 0x0
> > > > 23892@1517298638.543154:virtio_balloon_handle_output section name: pc.ram gpa: 0x17460d000
> > > > 23892@1517298638.543159:virtio_balloon_handle_output section name: pc.ram gpa: 0x0
> > > > 23892@1517298638.543162:virtio_balloon_handle_output section name: pc.ram gpa: 0x17460e000
> > > > 23892@1517298638.543165:virtio_balloon_handle_output section name: pc.ram gpa: 0x0
> > > > 23892@1517298638.543167:virtio_balloon_handle_output section name: pc.ram gpa: 0x17460f000
> > > > 23892@1517298638.543170:virtio_balloon_handle_output section name: pc.ram gpa: 0x0
> > > > ...
> > > > 
> > > > I think it's very possible that these zero addresses (please let me
> > > > know what the first 4K page is used for if anyone knows, since IIUC
> > > > that's what we throw away now) are half of the 64bit PFN.  Or say, not
> > > > sure whether this means a windows guest driver bug that is using
> > > > 64bits for PFN rather than 32bits (and I suppose the protocol is using
> > > > 32bit for PFNs).
> > > > 
> > > > Michael, do you know what to do with this?
> > > > 
> > > > Thanks,
> > > 
> > > PFN is GPA>>12.  Do you have more than 1<<44 bytes of memory in this VM then?
> > 
> > No.  But isn't it still not good to drop the page at offset zero (and
> > drop it NNN times)?
> 
> Absolutely - looks like a bug. I just don't know why does this happen.

IMHO if we are using a PFN array like this:

   u64 pfn_array[];

In the windows guest driver, then we'll see this (as mentioned
above).  But for sure this is wild guess of mine.

> 
> >  And I'm not sure what will happen if guest has
> > 1<<44 bytes; then we'll possibly drop very random addresses since a
> > real address will be splitted?
> > 
> > Thanks,
> 
> The balloon won't work, period. There was an interface change to fix
> that but implementation issues remained and contributor seems to be busy
> with page hints.

Okay.  So IIUC this is already a known issue for the driver owner.
Then it seems that there's nothing more I can do for now...

Thanks,

-- 
Peter Xu