Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Thu, Mar 17, 2022 at 12:07 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 17.03.2022 16:59, Tamas K Lengyel wrote:
> > On Thu, Mar 17, 2022 at 11:06 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>
> >> On 17.03.2022 15:43, Tamas K Lengyel wrote:
> >>> On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>>> On 10.03.2022 19:44, Tamas K Lengyel wrote:
> >>>>> @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct 
> >>>>> domain *d, hvm_domain_context_t *h)
> >>>>>      v->arch.dr6   = ctxt.dr6;
> >>>>>      v->arch.dr7   = ctxt.dr7;
> >>>>>
> >>>>> +    hvm_set_interrupt_shadow(v, ctxt.interruptibility_info);
> >>>>
> >>>> Setting reserved bits as well as certain combinations of bits will
> >>>> cause VM entry to fail. I think it would be nice to report this as
> >>>> an error here rather than waiting for the VM entry failure.
> >>>
> >>> Not sure if this would be the right spot to do that since that's all
> >>> VMX specific and this is the common hvm code.
> >>
> >> Well, it would be the VMX hook to do the checking, with an error
> >> propagated back here.
> >
> > I'm actually against it because the overhead of that error-checking
> > during vm forking would be significant with really no benefit. We are
> > copying the state from the parent where it was running fine before, so
> > doing that sanity checking thousands of times per second when we
> > already know its fine is bad.
>
> I can see your point, but my concern is not forking but normal migration
> or restoring of guests, where the incoming data is of effectively
> unknown origin.

IMHO for that route the error checking is better performed at the
toolstack level that sends the data to Xen.

Tamas