Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

Daniel P. Berrange wrote:
> On Fri, Feb 01, 2008 at 11:53:02AM -0600, Anthony Liguori wrote:
>   
>> Ian Jackson wrote:
>>     
>>> Anthony Liguori writes ("[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable > 2G support"):
>>>   
>>>       
>>>> The alternative is to change all the places that assume phys_ram_base + 
>>>> PA which I don't like very much.
>>>>     
>>>>         
>>> We would ideally like to do this for Xen, at least in the places we
>>> care about.  (Xen uses less of the qemu tree than KVM, I think.)
>>>   
>>>       
>> Support for the map cache in the Xen tree is a rather big change that 
>> I'm not going to attempt to support it in this patch series.
>>
>> I'd rather preserve the phys_ram_base + PA assumption because it allows 
>> us to be able to do support > 1 page DMA operations for our virtual IO 
>> drivers.  If you break the assumption that physically contiguous memory 
>> in the guest is virtual contiguous memory in the host, things get pretty 
>> ugly.
>>     
>
> Well Xen i386 has no choice but to use the map cache, since PAE lets 
> i386 guests have as much as 100 GB of memory & there's no way you can
> map that into QEMU's 32-bit userspace. So if virt IO has a dependancy
> on contigious memory access in QEMU its not going to play nice with
> Xen.
>   

For KVM (and it sounds like QEMU), we're just making the statement that 
32-bit hosts cannot support > 2GB guests.  I know that's a regression 
for Xen but in all fairness, I did raise this as an objection when the 
map cache was first introduced :-)

virtio could still be made to work with map cache.  You would just have 
to change it to be able to map more than one page contiguously.  As I 
mentioned though, it just starts getting ugly.

Regards,

Anthony Liguori

> Dan.
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/