On 10/25/2009 06:45 PM, Alexander Graf wrote:
It's not. We can't use the guest memory for hsave because then the
guest could break the l1 state, so a malicious hypervisor could
break us.
Guest hsave should be used for storing guest state when switching
into the nested guest, not host state.
Am 26.10.2009 um 09:33 schrieb Avi Kivity a...@redhat.com:
On 10/25/2009 06:45 PM, Alexander Graf wrote:
It's not. We can't use the guest memory for hsave because then
the guest could break the l1 state, so a malicious hypervisor
could break us.
Guest hsave should be used for storing
On Sun, Oct 25, 2009 at 11:49:35AM +0200, Avi Kivity wrote:
On 10/24/2009 12:35 PM, Alexander Graf wrote:
Hm, thinking about this again, it might be useful to have an
currently in nested VM flag here. That way userspace can decide
if it needs to get out of the nested state (for migration) or
On 10/26/2009 11:11 AM, Alexander Graf wrote:
L1 hsave stores the architected state saved by vmrun, e.g. cs.sel,
next_rip, cr0, cr3, etc. The host intercept bitmap is not state
since it is calculated from the L1 intercept bitmap and host code.
Indeed it can be different from host to host
On 10/26/2009 11:17 AM, Joerg Roedel wrote:
On Sun, Oct 25, 2009 at 11:49:35AM +0200, Avi Kivity wrote:
On 10/24/2009 12:35 PM, Alexander Graf wrote:
Hm, thinking about this again, it might be useful to have an
currently in nested VM flag here. That way userspace can decide
if it
On Mon, Oct 26, 2009 at 11:21:12AM +0200, Avi Kivity wrote:
On 10/26/2009 11:17 AM, Joerg Roedel wrote:
On Sun, Oct 25, 2009 at 11:49:35AM +0200, Avi Kivity wrote:
On 10/24/2009 12:35 PM, Alexander Graf wrote:
Hm, thinking about this again, it might be useful to have an
currently in nested VM
On 10/26/2009 11:30 AM, Joerg Roedel wrote:
Which host state? As far as I can tell, it can all be regenerated.
The state which is loaded into the vcpu when a #vmexit is emulated. This
includes segments, control registers and the host rip for example.
All of this state does not
On Mon, Oct 26, 2009 at 11:39:46AM +0200, Avi Kivity wrote:
On 10/26/2009 11:30 AM, Joerg Roedel wrote:
Which host state? As far as I can tell, it can all be regenerated.
The state which is loaded into the vcpu when a #vmexit is emulated. This
includes segments, control registers and the
On 10/26/2009 11:56 AM, Joerg Roedel wrote:
On Mon, Oct 26, 2009 at 11:39:46AM +0200, Avi Kivity wrote:
On 10/26/2009 11:30 AM, Joerg Roedel wrote:
Which host state? As far as I can tell, it can all be regenerated.
The state which is loaded into the vcpu when a
On Mon, Oct 26, 2009 at 12:09:25PM +0200, Avi Kivity wrote:
On 10/26/2009 11:56 AM, Joerg Roedel wrote:
On Mon, Oct 26, 2009 at 11:39:46AM +0200, Avi Kivity wrote:
On 10/26/2009 11:30 AM, Joerg Roedel wrote:
Which host state? As far as I can tell, it can all be regenerated.
The state which
On 10/26/2009 12:45 PM, Joerg Roedel wrote:
Ok, parts of the state can be saved in guest memory. But thats
currently not done. This will need some care to not introduce a security
hole. But it shouldn't be too difficult.
The state thats not reproducible in an sane way is the intercept bitmap
On Mon, Oct 26, 2009 at 12:56:31PM +0200, Avi Kivity wrote:
On 10/26/2009 12:45 PM, Joerg Roedel wrote:
* nested intercepts
These are part of the guest vmcb. The host nested intercepts can be
recalculated, no?
* for nested nested paging: guest nested cr3 value
Part of the guest
On 10/20/2009 09:23 PM, Alexander Graf wrote:
If the nested hypervisor doesn't intercept INTR we don't support it
anyways.
That's a bug.
Really, pushing the whole nesting state over is not a good idea.
Isn't the entire state just one bit? Everything else should be saved to
guest
On 10/24/2009 12:35 PM, Alexander Graf wrote:
Hm, thinking about this again, it might be useful to have an
currently in nested VM flag here. That way userspace can decide if
it needs to get out of the nested state (for migration) or if it just
doesn't care.
Getting out of nested state
Am 25.10.2009 um 10:46 schrieb Avi Kivity a...@redhat.com:
On 10/20/2009 09:23 PM, Alexander Graf wrote:
If the nested hypervisor doesn't intercept INTR we don't support it
anyways.
That's a bug.
It's a question of how accurate we want to be.
Really, pushing the whole nesting state
On 10/25/2009 03:53 PM, Alexander Graf wrote:
Am 25.10.2009 um 10:46 schrieb Avi Kivity a...@redhat.com:
On 10/20/2009 09:23 PM, Alexander Graf wrote:
If the nested hypervisor doesn't intercept INTR we don't support it
anyways.
That's a bug.
It's a question of how accurate we want to
Am 25.10.2009 um 15:08 schrieb Avi Kivity a...@redhat.com:
On 10/25/2009 03:53 PM, Alexander Graf wrote:
Am 25.10.2009 um 10:46 schrieb Avi Kivity a...@redhat.com:
On 10/20/2009 09:23 PM, Alexander Graf wrote:
If the nested hypervisor doesn't intercept INTR we don't support
it anyways.
On 23.10.2009, at 21:34, Jan Kiszka wrote:
Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile
ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we can decide
how to
Marcelo Tosatti wrote:
On Tue, Oct 20, 2009 at 03:01:15PM +0200, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we
On Fri, Oct 23, 2009 at 03:08:21PM +0200, Jan Kiszka wrote:
Marcelo Tosatti wrote:
On Tue, Oct 20, 2009 at 03:01:15PM +0200, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for
Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we can decide
how to partition it into one ore more substates for
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we can decide
how to partition it into one ore more substates for the new
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we can decide
how to partition it into one
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we can decide
how
On Tue, Oct 20, 2009 at 03:19:41PM +0200, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state
On 20.10.2009, at 15:19, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile
ATM,
this is an attempt to collect the precise requirements for
additional
state fields. Once everyone
Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:19:41PM +0200, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for
On Tue, Oct 20, 2009 at 03:29:38PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:19:41PM +0200, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
On Tue, Oct 20, 2009 at 03:01:15PM +0200, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we can decide
how to
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we can decide
how
On 20.10.2009, at 15:37, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile
ATM,
this is an attempt to collect the precise requirements for
additional
state fields. Once everyone
On Tue, Oct 20, 2009 at 03:41:57PM +0200, Alexander Graf wrote:
On 20.10.2009, at 15:37, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit
volatile ATM,
this is an attempt to collect
On 20.10.2009, at 15:48, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:41:57PM +0200, Alexander Graf wrote:
On 20.10.2009, at 15:37, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit
On Tue, Oct 20, 2009 at 03:01:15PM +0200, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile ATM,
this is an attempt to collect the precise requirements for additional
state fields. Once everyone feels the list is complete, we can decide
how to
On Tue, Oct 20, 2009 at 03:51:02PM +0200, Alexander Graf wrote:
On 20.10.2009, at 15:48, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:41:57PM +0200, Alexander Graf wrote:
On 20.10.2009, at 15:37, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
On 20.10.2009, at 20:55, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:51:02PM +0200, Alexander Graf wrote:
On 20.10.2009, at 15:48, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:41:57PM +0200, Alexander Graf wrote:
On 20.10.2009, at 15:37, Jan Kiszka wrote:
Alexander Graf wrote:
On
On Tue, Oct 20, 2009 at 08:59:48PM +0200, Alexander Graf wrote:
On 20.10.2009, at 20:55, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:51:02PM +0200, Alexander Graf wrote:
On 20.10.2009, at 15:48, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:41:57PM +0200, Alexander Graf wrote:
On 20.10.2009, at 21:09, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 08:59:48PM +0200, Alexander Graf wrote:
On 20.10.2009, at 20:55, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:51:02PM +0200, Alexander Graf wrote:
On 20.10.2009, at 15:48, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at
On Tue, Oct 20, 2009 at 09:23:22PM +0200, Alexander Graf wrote:
On 20.10.2009, at 21:09, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 08:59:48PM +0200, Alexander Graf wrote:
On 20.10.2009, at 20:55, Gleb Natapov wrote:
On Tue, Oct 20, 2009 at 03:51:02PM +0200, Alexander Graf wrote:
39 matches
Mail list logo
