Re: [Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 09/17/09 08:56, Nakajima, Jun wrote:
>> I very much expect that it'll need fixing/(re)implementing on both the
>> kernel and hypervisor side...
>>     
> To me, leveraging the native MMU code, rather than using existing API/ABI, 
> would simplify both the guest and hypervisor side if hardware MMU 
> virtualization is present. For example:
> - today a 64-bit PV guest builds/switches page tables depending on the 
> kernel/user mode. It's not required anymore.
>   
The two pagetables are largely shared, so it really comes down to
maintaining an additional L4 page.  If the domain is running in a HAP
container, then then the "kernel" pagetable would have proper U/S bit
its pagetable entries (ie, Xen wouldn't strip them off, or set global on
user mappings) and then loading a new pagetable would just mean
reloading cr3 with the kernel pagetable.  In other words, we can still
do an efficient pagetable swap without needing to change the guest or
the ABI at all; the user pagetable would be unused and ignored, but that
isn't a huge burden.

> - we can automatically get large page support (2MB, 1GB)
>   
Once the requirement to mark pagetable pages RO goes away, then it would
be easy to add large-page support.

> I thought pv_xxx_ps (such as pv_time, pv_cpu_ops, pv_mmu_ops, etc.) was 
> designed to choose the right pv_ops accordingly depending on the features 
> available. 
>   

Sure.  It would be easy to either use new special-purpose just plain
native versions of those ops if that's the right thing to do; but it
would be nice if a current unmodified PV guest worked within a HVM
container and got at least some benefit from doing so.  Also, pagetable
issues have repercussions beyond just the raw pagetable update functions.

Of course you can get both these features just by booting the kernel as
an hvm guest.  But if we're talking about giving PV kernels some
benefits from hvm/hap hardware features, I think we should looking at it
from the perspective of starting with a PV kernel then adding
incremental changes.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel