On 07/28/2010 03:18 PM, Roedel, Joerg wrote:
The guest (L2 in this case) is doomed since it execution cannot
continue. But L1 and L0 are fine. The problem with L2 avoiding
intercepts is that L2 can change control registers and take over L1.
Right too. We can not ignore it. The right fix is
On Wed, Jul 28, 2010 at 07:57:36AM -0400, Avi Kivity wrote:
> If the instruction opcode is on mmio, the processor never sees the
> opcode and thus can not intercept. Or the processor may see one
> instruction, which is not intercepted, but by the time the emulator
> kicks in a different instru
On 07/28/2010 02:51 PM, Roedel, Joerg wrote:
On Wed, Jul 28, 2010 at 07:34:11AM -0400, Avi Kivity wrote:
On 07/28/2010 02:25 PM, Roedel, Joerg wrote:
On Wed, Jul 28, 2010 at 06:28:06AM -0400, Avi Kivity wrote:
We have a slightly different problem, if the nested guest manages to get
an inst
On Wed, Jul 28, 2010 at 07:34:11AM -0400, Avi Kivity wrote:
> On 07/28/2010 02:25 PM, Roedel, Joerg wrote:
> > On Wed, Jul 28, 2010 at 06:28:06AM -0400, Avi Kivity wrote:
> >> We have a slightly different problem, if the nested guest manages to get
> >> an instruction to be emulated by the host (
On 07/28/2010 02:25 PM, Roedel, Joerg wrote:
On Wed, Jul 28, 2010 at 06:28:06AM -0400, Avi Kivity wrote:
We have a slightly different problem, if the nested guest manages to get
an instruction to be emulated by the host (if the guest assigned it the
cirrus framebuffer, for example, so from L1's
On Wed, Jul 28, 2010 at 06:28:06AM -0400, Avi Kivity wrote:
> We have a slightly different problem, if the nested guest manages to get
> an instruction to be emulated by the host (if the guest assigned it the
> cirrus framebuffer, for example, so from L1's point of view it is RAM,
> but from L0'
On 07/28/2010 12:37 PM, Roedel, Joerg wrote:
Can it be really this simple? Suppose we emulate a nested guest
instruction just before vmexit, doesn't that invalidate
vmcb->control.next_rip? Can that happen?
Good point. I looked again into it. The documentation states:
The next seque
On Tue, Jul 27, 2010 at 02:32:35PM -0400, Avi Kivity wrote:
> On 07/27/2010 07:14 PM, Joerg Roedel wrote:
> > This patch implements the emulations of the svm next_rip
> > feature in the nested svm implementation in kvm.
> >
> > Signed-off-by: Joerg Roedel
> > ---
> > arch/x86/kvm/svm.c |8 +
On 07/27/2010 07:14 PM, Joerg Roedel wrote:
This patch implements the emulations of the svm next_rip
feature in the nested svm implementation in kvm.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kv
This patch implements the emulations of the svm next_rip
feature in the nested svm implementation in kvm.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7d10f2c..b44c
10 matches
Mail list logo
