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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.09.14 at 11:44, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> 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.

No - additionally to having a per-vCPU inject_trap field, you'd also
add a per-domain one.

Jan


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