| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH][RFC] Emulating real mode with x86_emulate
|
To: |
"Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>, Anthony Liguori <aliguori@xxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] Re: [PATCH][RFC] Emulating real mode with x86_emulate |
|
From: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
|
Date: |
Tue, 03 Apr 2007 07:25:43 +0100 |
|
Cc: |
"Yu, Wilfred" <wilfred.yu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> |
|
Delivery-date: |
Mon, 02 Apr 2007 23:25:12 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<1175557945.3593.16.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
Acd1gfcrYHbZARDuRVyd6bkM/W933AANvDSH |
|
Thread-topic: |
[Xen-devel] Re: [PATCH][RFC] Emulating real mode with x86_emulate |
|
User-agent: |
Microsoft-Entourage/11.3.3.061214 |
On 3/4/07 00:52, "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx> wrote:
Right, the idea was to have x86_emulate() be called instead of
vmentry(). I thought that being in the set_cr0 path would ensure that
we go through do_resume() again. Is this assumption incorrect?
Yes, This assumption is not right. arch_vmx_do_resume() is assigned to schedule tail, so that the vcpu context is saved/restored when another vcpu is scheduled on the physical cpu.
If you want to keep the check off the ‘fast’ return path (which actually isn’t all that fast as yet, sadly) then you can kick the SCHEDULE_SOFTIRQ from the set_cr0 path. This will take you the really slow path, through the scheduler, but will ultimately guarantee that you go through arch_vmx_do_resume() before returning to guest context.
I didn't want to just stick it in the set_cr0 path because we ought to
be able to pull the emulation loop into common code for SVM/VT and the
do_resume path seems like the only place where there's common place to
hook right now.
I thought the emulator will be needed only for VMX; why is it needed for SVM?
It would be really nice to make as much of this infrastructure as possible HVM-generic so that any HVM implementation can fall back to emulation to handle corner cases. In SVM case this may just be a few tricky instructions (SMSW springs to mind), but we’d like to share code if possible.
Also calling the x86_emulate() to emulate multiple instructions from vmx_do_resume() will block the physical cpu from other vcpus.
I think we discussed the approach of using the non-root context for for emulator within the Xen. Or did I misunderstanding it?
I think you did. It’s sufficient to check for softirq work at emulated-instruction boundaries.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home