[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)



On 09/09/16 16:16, Jennifer Herbert wrote:
> On 01/08/16 12:32, Ian Jackson wrote:
>> I think we need to introduce a new hypercall (which I will call DMOP
>> for now) which may augment or replace some of HVMCTL.  Let me explain:
>>
> 
> I believe the new 'DMOP' hypercall is a good idea,  but following on
> from discussions, I propose a revised design, which I present below.
> Please let me know what you think.
> 
> Thanks,
> Jenny.
> 
> 
> DMOP  (multi-buffer variant)
> ============================
[...]
> Advantages of this system, over previouse DMOP proposals:
> 
> 
> *  The validation of address ranges is easily done by the privcmd driver,
>    using standard kernel mechanisms.  No need to get Xen thinking about
>    guest memory layout, which it should be independent of, and potentially
>    adding confusion.

+1.

The user address limit in Linux is a per-thread property, so trying to
pass this information to the hypervisor would require passing this
information in every dm_op, or switching the information on every task
switch.  The user address limit is also architecture specific, and would
require every arch to expose this via some new API.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.