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