Re: [Xen-devel] [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 09/02/2014 12:33 PM, Jan Beulich wrote:
>>>> On 02.09.14 at 11:18, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> While we need to set the data per-domain and have whatever VCPU inject
>> the page fault - _but_only_if_ it's in usermode and its CR3 points to
>> something interesting.
> 
> Right - but none of this is an argument against adding a wildcard
> specifier for the vCPU passed in the existing interface and -
> assuming this is a tools only interface - add the additional qualifiers
> (and perhaps even make the code obey to them when used in a
> vCPU-centric invocation).

But adding a wildcard for the VCPU would effectively mean that this part
of the HVMOP_inject_trap case handling code would need to be modified to
use per-domain data instead of per-VCPU data (which with a wildcard
would not make sense):

        rc = -ENOENT;
        if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid]) == NULL )
            goto param_fail8;

        if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
            rc = -EBUSY;
        else
        {
            v->arch.hvm_vcpu.inject_trap.vector = tr.vector;
            v->arch.hvm_vcpu.inject_trap.type = tr.type;
            v->arch.hvm_vcpu.inject_trap.error_code = tr.error_code;
            v->arch.hvm_vcpu.inject_trap.insn_len = tr.insn_len;
            v->arch.hvm_vcpu.inject_trap.cr2 = tr.cr2;
            rc = 0;
        }

The alternative would be to set the data to _all_ of the VCPUs for the
wildcard case, but that could potentially trigger a page fault for every
VCPU.

While I can't possibly have any technical arguments against using a
wildcard for the VCPU (-1 looks like a likely candidate) and adding a
bool_t usermode and an unsigned long cr3 parameter / member, those
changes might somewhat warp the design of HVMOP_inject_trap.


Thanks,
Razvan Cojocaru

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