[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <547C7E59.9040408@suse.com>
Date: Mon, 01 Dec 2014 15:42:33 +0100
From: Juergen Gross <jgross@...e.com>
To: "Luis R. Rodriguez" <mcgrof@...e.com>,
David Vrabel <david.vrabel@...rix.com>
CC: Andrew Cooper <andrew.cooper3@...rix.com>, x86@...nel.org,
kvm@...r.kernel.org, "Luis R. Rodriguez" <mcgrof@...not-panic.com>,
linux-kernel@...r.kernel.org, Davidlohr Bueso <dbueso@...e.de>,
Joerg Roedel <jroedel@...e.de>,
Jan Beulich <JBeulich@...e.com>,
xen-devel@...ts.xenproject.org, boris.ostrovsky@...cle.com,
Borislav Petkov <bp@...e.de>, Olaf Hering <ohering@...e.de>
Subject: Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private hypercall
when non CONFIG_PREEMPT
On 12/01/2014 02:32 PM, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 11:01:18AM +0000, David Vrabel wrote:
>> On 28/11/14 04:49, Juergen Gross wrote:
>>> On 11/27/2014 07:50 PM, Andrew Cooper wrote:
>>>>
>>>> XenServer uses
>>>>
>>>> https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
>>>>
>>>>
>>>> to deal with these issues. That patch is based on 3.10.
>>>
>>> Clever. :-)
>>>
>>>>
>>>> I can remember whether this has been submitted upstream before (and
>>>> there were outstanding issues), or whether it fell at an inconvenient
>>>> time with our development cycles.
>>>
>>> I found
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2014-02/msg02540.html
>>>
>>> and nothing else.
>>
>> I dropped it because it copy-and-paste a bunch of otherwise generic x86
>> assembler and looked unlikely to get an x86 maintainer ack. If you
>> think otherwise, feel free to pick it up and run with it.
>
> I was trying to run with it, but my biggest gripe with this was
> the use of preempt_schedule_irq(), but we can review that on the
> other thread.
I think this can be handled completely inside xen_evtchn_do_upcall().
xen_preemptible_hcall_begin() (possibly with another name) could take
the pointer of a function as parameter which is used as continuation
point after an asynchronous interrupt in the critical section.
Parameter for that function would be the exception frame of the
original interrupt to be able to continue at the interrupted position
after e.g. calling schedule().
Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists