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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.11.18 at 17:59, <roger.pau@xxxxxxxxxx> wrote:
> 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?

At least it would better fit with the rest of how things currently
get done.

Jan



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