Re: [Xen-devel] [PATCH v4 2/5] vpci: fix deferral of long operations

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Nov 16, 2018 at 05:11:39AM -0700, Jan Beulich wrote:
> >>> On 14.11.18 at 12:57, <roger.pau@xxxxxxxxxx> wrote:
> > Current logic to handle long running operations has two flaws:
> > 
> >  - hvm_io_pending is only used by Intel code, fix this by moving the
> >    call to vpci_process_pending into handle_hvm_io_completion.
> 
> As mentioned before, the reference to Intel code is wrong here.
> The main caller is handle_pio(), and the Intel specific one sits in
> nested VMX code anyway, so is of basically no interest for the
> purposes here.
> 
> > @@ -186,6 +183,9 @@ bool handle_hvm_io_completion(struct vcpu *v)
> >      enum hvm_io_completion io_completion;
> >      unsigned int id;
> >  
> > +    if ( has_vpci(d) && vpci_process_pending(v) )
> > +        return false;
> 
> I think this would be the better place to raise the scheduler softirq.
> vpci_process_pending() should indicated to its caller just whether
> preemption is needed, but should not care how this is actually to
> be effected. This is benign now, but might change if a second
> caller would need adding.

Ack.

> > @@ -182,6 +185,7 @@ static void defer_map(struct domain *d, struct pci_dev 
> > *pdev,
> >      curr->vpci.mem = mem;
> >      curr->vpci.cmd = cmd;
> >      curr->vpci.rom_only = rom_only;
> > +    raise_softirq(SCHEDULE_SOFTIRQ);
> >  }
> 
> Why is this needed? The description doesn't mention it.

vPCI needs to raise a shceduler softirq in order to prevent the guest
from resuming execution after deferring a map/unmap operation. Without
this the guest might just resume execution while having pending work
if there's no scheduler softirq already pending.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel