Re: large page size virtio issues

[Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Hollis Blanchard wrote:
> On Wed, 2008-11-05 at 08:06 -0600, Anthony Liguori wrote:
>   
>
>> I don't much like the idea of globally hard coding it to 4k. I'd rather 
>> make it architecture specific.
>>     
>
> Making the units architecture-specific doesn't solve the problem at all
> AFAICS. It doesn't even solve my original problem on PowerPC 440 since
> the guest page size can vary.
>
> AFAIK the only reason to use a PFN in this interface in the first place
> is to allow for physical addresses >32 bits. A hardcoded shift of 12
> gives you 44 bits of physical address space (16 TB). This actually isn't
> very big today, so using an architecture-specific hardcoded 4K size will
> become an issue anyways, *even on x86*.
>   

It's PIO on x86 so there's no way to do a 64-bit operation.

> Brainstorming backwards-compatible interface expansion possibilities:
>      1. Rename the current interface to "4K_PFN", and add another, let's
>         say "64K_PFN". Of course, if a guest with smaller pages uses the
>         new interface, it must properly align its queue allocation.
>      2. Rename the current interface to "4K_PFN". Use 64-bit writes to
>         set VIRTIO_PCI_QUEUE_PFN. 32-bit architectures couldn't use
>         this, which might be OK since practically speaking, I think
>         32-bit architectures can address at most 36 bits of physical
>         space. I also don't know what the semantics are of 64-bit PCI
>         writes (if it's not allowed on physical hardware) -- it looks
>         like Linux doesn't have an iowrite64, for example.
>      3. Rename the current interface to "4K_PFN". Use multiple writes
>         (high/low) to set VIRTIO_PCI_QUEUE_PFN. Not atomic. To simplify
>         backend implementation, you could require that PFN_HIGH writes
>         come before PFN_LOW.
>      4. Use multiple writes (set page size, set PFN). SET_PAGE_SIZE must
>         precede SET_PFN. Not atomic.
>      5. Create a variable-sized interface (still 32-bit write), where
>         the shift value is encoded in the value itself (I guess this is
>         the FP mantissa+exponent approach). For example, the low 8 bits
>         are the shift beyond 12, so a write of 0x10000004 would mean
>         physical address 1<<(12+4).
>   

I think we should just have a VIRTIO_PFN_SHIFT define that is 
architecture specific.

On x86, it'll be 4k.  You can make it whatever you want for PPC.  Fixing 
all architectures to be 4k is going to suck for architectures with < 4k 
pages.

Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html