On Fri, May 08, 2009 at 02:25:11AM -0300, Glauber Costa wrote:
On Wed, May 06, 2009 at 01:51:04PM +0300, Avi Kivity wrote:
Gleb Natapov wrote:
On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
diff --git a/arch/x86/include/asm/kvm_host.h
On Fri, May 08, 2009 at 10:18:14AM +0300, Gleb Natapov wrote:
On Fri, May 08, 2009 at 02:25:11AM -0300, Glauber Costa wrote:
On Wed, May 06, 2009 at 01:51:04PM +0300, Avi Kivity wrote:
Gleb Natapov wrote:
On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
diff --git
On Wed, May 06, 2009 at 01:51:04PM +0300, Avi Kivity wrote:
Gleb Natapov wrote:
On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
diff --git a/arch/x86/include/asm/kvm_host.h
b/arch/x86/include/asm/kvm_host.h
index 8e680c3..a49d07b 100644
---
On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8e680c3..a49d07b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -510,6 +510,8 @@ struct kvm_x86_ops {
Gleb Natapov wrote:
On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8e680c3..a49d07b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -510,6 +510,8 @@
Hmm, if the guest runs an infinite emulated 'mov ss', it will keep
toggling the MOV_SS bit, but STI will remain set, so we'll never allow
an interrupt into the guest kernel.
We have no choice but returning both flags, since svm does not differentiate
between them.
But see below for an
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow interrupts.
The same goes
Glauber Costa wrote:
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow interrupts.
The same goes
H. Peter Anvin wrote:
Avi Kivity wrote:
We don't emulate guest user mode.
Well, if guest userspace can convince its kernel to give it access to
some memory mapped I/O register, I guess it can execute repeated 'mov
ss, mmio' and starve the guest kernel.
It doesn't need a MMIO register to
H. Peter Anvin wrote:
Avi Kivity wrote:
Why do we care? The guest can only harm itself, and if it wants to
disable interrupts, it would be a lot easier for it to run a plain 'cli'.
I guess it would be a problem if we emulated 'mov ss' for ordinary
userspace or vm86 mode, but we don't.
Avi Kivity wrote:
We don't emulate guest user mode.
Well, if guest userspace can convince its kernel to give it access to
some memory mapped I/O register, I guess it can execute repeated 'mov
ss, mmio' and starve the guest kernel.
It doesn't need a MMIO register to do that, even.
Glauber Costa wrote:
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow
On Mon, Apr 13, 2009 at 04:06:50PM -0400, Glauber Costa wrote:
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3fc4623..0db1be7 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -513,6 +513,7 @@ struct kvm_x86_ops {
Avi Kivity wrote:
The comment about repeating 'mov ss' in the manual has that wonderful
word in it, May. That means we're perfectly allowed to ignore it and
just set the flag unconditionally.
Realistically, though, this should only be done for a limited number of
sequential instructions.
H. Peter Anvin wrote:
Avi Kivity wrote:
The comment about repeating 'mov ss' in the manual has that wonderful
word in it, May. That means we're perfectly allowed to ignore it and
just set the flag unconditionally.
Realistically, though, this should only be done for a limited number
Avi Kivity wrote:
Why do we care? The guest can only harm itself, and if it wants to
disable interrupts, it would be a lot easier for it to run a plain 'cli'.
I guess it would be a problem if we emulated 'mov ss' for ordinary
userspace or vm86 mode, but we don't.
Well, the answer is
Why? Do you see a guest filling all of memory with 'mov ss' and
expecting to break out of it via an interrupt?
Well I did try mapping a page of move ss all through memory on real
hardware long ago and seeing what happened on a 386 in real mode with
DOSEMU. I was disappointed ;)
--
To
Alan Cox wrote:
Why? Do you see a guest filling all of memory with 'mov ss' and
expecting to break out of it via an interrupt?
Well I did try mapping a page of move ss all through memory on real
hardware long ago and seeing what happened on a 386 in real mode with
DOSEMU. I was disappointed
Glauber Costa wrote:
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow
Avi Kivity wrote:
-rip = kvm_rip_read(vcpu);
-rip += vmcs_read32(VM_EXIT_INSTRUCTION_LEN);
-kvm_rip_write(vcpu, rip);
+if (!(interruptibility interruptibility_mask))
+vmcs_write32(GUEST_INTERRUPTIBILITY_INFO,
+ interruptibility |
21 matches
Mail list logo
