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

[Peter Xu <peterx@redhat.com>]

On Mon, Feb 26, 2018 at 10:54:11AM +0200, Gal Hammer wrote:
> Hi Peter,
> 
> On Fri, Feb 2, 2018 at 12:11 PM, Peter Xu <peterx@redhat.com> wrote:
> > On Thu, Feb 01, 2018 at 02:48:20PM +0200, Michael S. Tsirkin wrote:
> >
> > [...]
> >
> >> > > > > 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.
> >>
> >> I don't see code like this anywhere in the windows balloon
> >> driver. It's here:
> >> https://github.com/virtio-win/kvm-guest-drivers-windows.git
> >
> > Thanks for the pointer.  I had a quick glance, the PFN array is
> > defined as:
> >
> >     PPFN_NUMBER             pfns_table;
> >
> > But I don't know what's sizeof(PPFN_NUMBER). :(
> 
> sizeof(PPFN_NUMBER) = sizeof(void*)
> 
> PFN_NUMBER is of an unsigned long type. Although it doesn't matter, as
> a pointer to it is always the same size, 4 bytes in a 32-bit CPU and 8
> bytes in 64-bit one.

Ah, it's not really PPFN_NUMBER that matters, it should be
PFN_NUMBER.  This is how the PFNs are copied in windows driver:

    RtlCopyMemory(ctx->pfns_table, MmGetMdlPfnArray(pPageMdl),
        ctx->num_pfns * sizeof(PFN_NUMBER));

I don't know these APIs, but it looks like MmGetMdlPfnArray() is
returning an PFN_NUMBER array.

And I don't know how the balloon spec says, but in QEMU it's always
using uint32_t as PFN.  See virtio_balloon_handle_output():

    while (iov_to_buf(elem->out_sg, elem->out_num, offset, &pfn, 4) == 4)

So I guess only if sizeof(PFN_NUMBER)==4 is true on both 32/64 bits
platforms of windows, otherwise there might be a problem.

Thanks,

-- 
Peter Xu