> Ditto.
> For xenoprof, ipsr.pp shouldn't be changed.
> This code always sets ipsr.pp.
> add IA64_PSR_PP to mask. not to mipsr.
>
Didn't notice this, thanks
>> diff -r f2457c7aff8d xen/arch/ia64/vmx/vmx_vcpu.c
>> --- a/xen/arch/ia64/vmx/vmx_vcpu.c Fri Apr 25 20:13:52 2008 +0900
>> +++ b/xen/arch/ia64/vmx/vmx_vcpu.c Fri May 09 10:58:37 2008 +0800
>> @@ -172,11 +172,6 @@ IA64FAULT vmx_vcpu_set_rr(VCPU *vcpu, u6 {
>> u64 rrval;
>>
>> - if (unlikely(is_reserved_rr_rid(vcpu, val))) {
>> - gdprintk(XENLOG_DEBUG, "use of invalid rrval %lx\n", val);
>> - return IA64_RSVDREG_FAULT;
>> - }
>> -
>> VMX(vcpu,vrr[reg>>VRN_SHIFT]) = val;
>> switch((u64)(reg>>VRN_SHIFT)) {
>> case VRN7:
>
> Without the check, VTi domain guest may access other domain's page
> or xen's page. So it can't be dropped.
> Do you find that calling is_reserved_rr_rid() is heavy?
> If so, please make it an inline function.
>
int is_reserved_rr_rid(VCPU* vcpu, u64 reg_value)
{
ia64_rr rr = { .rrval = reg_value };
if (rr.rid >= (1UL << vcpu->domain->arch.rid_bits))
return 1;
return 0;
}
Because vcpu->domain is not mapped by TR, this function can not be
called in fast path.
Xen will provide number of rr bits to guest Os. So good behavior OS will
not use invalid rr, as least for linux and windows.
In this case, Do we really need this check?
Or, do you have any other suggestion?
Thanks,
Anthony
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home