Re: Re: [PATCH v2] x86/nSVM: Check the L1 IOPM_BASE and MSRPM_BASE

On 05.08.2026 10:36, Jan Beulich wrote:
>On 29.07.2026 16:38, Abdelkareem Abdelsaamad wrote:
>> @@ -294,6 +296,24 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>>      enum hvm_translation_result ret;
>>      unsigned long *ns_viomap;
>>      bool ioport_80 = true, ioport_ed = true;
>> +    gfn_t ns_iopm_end =
>> +        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), (IOPM_PAGES_COUNT - 1));
>> +    gfn_t ns_msrpm_end =
>> +        gfn_add(gaddr_to_gfn(ns_vmcb->_msrpm_base_pa), (MSRPM_PAGES_COUNT - 1));
>
>Nit: Why the excess parentheses around the 2nd arguments each? Without them
>the 2nd instance also more obviously stays within line length limits.
>
I will address in V3.

>> +    if ( gfn_x(ns_iopm_end) > domain_get_maximum_gpfn(v->domain) )
>
>I don't think using domain_get_maximum_gpfn() is correct here. Imo you want
>to merely check against what the guest is told in CPUID. 
I will switch to using gfn_valid() in V3 to properly align with what is valid
for the guest.
>...Everything else
>ought to be properly covered by hvm_copy_from_guest_phys() /
>hvm_map_guest_frame_ro() already. In fact for the MSR bitmap I thus can't
>see why further checking would be needed. 
Indeed,  I rechecked the call and confirmed that an invalid address should be
caught downstream in __hvm_copy() -> hvm_translate_get_page(). I will drop this
check in V3.
>..And for the I/O bitmap it looks
>to be a matter of better error handling, rather than introducing extra
>checking.
>
I tested with the address (0xffffffffffffffffUL) assigned to the VMCB::IOPM and
this just passes successfully without any error reported because it is all the
time mapped to a valid host address. So, I think an explicit extra check is
required here rather than just better error reporting.

> +    {
> +        gdprintk(XENLOG_ERR, "%s invalid _iopm_base_pa address (%#"PRIx64")\n",
> +                 __func__, ns_vmcb->_iopm_base_pa);
> +        return 1;

>Why literal 1? Yes, there is another such return in the function, but no, we
>don't want to extend that. Aiui NSVM_ERROR_VVMCB is meant here.
I will change both in V3.

>Jan