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:
> > >>
>
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
> >>> b/arch/x86/inclu
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
>>> --- a/arch/x86/incl
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 @@ struc
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 {
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 f
> 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 al
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 inte
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 f
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
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.
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.
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 ;)
> 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 unsubs
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
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 o
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 instructio
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 inte
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 {
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 f
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 | inte
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 inte
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 f
23 matches
Mail list logo