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 <pet...@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
