Re: [Xen-devel] [PATCH v3 5/7] vpci: fix execution of long running operations

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

On Thu, Nov 08, 2018 at 09:25:26AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 14:20, <roger.pau@xxxxxxxxxx> wrote:
> > On Thu, Nov 08, 2018 at 06:04:11AM -0700, Jan Beulich wrote:
> >> >>> On 08.11.18 at 13:47, <roger.pau@xxxxxxxxxx> wrote:
> >> > My point would be that on x86 I think the only way to have preemptible
> >> > long-running operations inside of Xen is to block the guest vCPU and
> >> > run them in a tasklet, or at least this seems the less invasive one.
> >> > 
> >> > Do you still have objections to this patch/approach?
> >> 
> >> Well, I still don't understand why you think you need to introduce
> >> a tasklet in the first place. That's because I still don't understand
> >> what you think is wrong with the current approach (leaving aside
> >> the exact placement of where the vpci hook needs to be called).
> > 
> > The current approach doesn't prevent the vCPU from returning to guest
> > context with pending work.
> > 
> > Placing the pending work hook (vpci_process_pending) in hvm_do_resume
> > is not going to solve this unless we raise and process a scheduler
> > softirq, and then this leads to the recursion problem.
> 
> Which recursion problem? I still haven't seen an outline taking into
> account what I have written in earlier replies. In particular I don't
> see a softirq handler itself calling do_softirq() anywhere.

I could place the vPCI pending work hook in hvm_do_resume or
handle_hvm_io_completion and then simply do a
raise_softirq(SCHEDULER_SOFTIRQ) and return in order to preempt. The
do_softirq() call in the svm/vmx guest entry path is called with a
clean stack so there's no stack overflow issue there.

Do you think this would be better than blocking the vCPU and using a
tasklet?

Thanks, Roger.

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