On 08/05/2010 02:50 PM, Nadav Har'El wrote:
On Tue, Jun 15, 2010, Gleb Natapov wrote about "Re: [PATCH 9/24] Implement VMCLEAR":
On Tue, Jun 15, 2010 at 04:50:35PM +0300, Avi Kivity wrote:
On 06/15/2010 04:47 PM, Gleb Natapov wrote:
Architectural errors (bad alignment) should update flags. Internal
errors (ENOMEM, vpmtr pointing outside of RAM) should not.
vpmtr pointing outside of RAM is architectural error (or not?). SDM
says "The operand of this instruction is always 64 bits and is always in
memory", but may be they mean "not in register". Anyway internal errors
should generate error exit to userspace which this patch is also
missing.
I'm a bit puzzled what I am supposed to do when the guest-physical
address I get as a parameter to VMCLEAR (after I read this address from guest
virtual memory) is beyond the guest's actual memory, i.e., gfn_to_page
fails on this address. Is this a normal "architectural error" and I should
VMfail(VMCLEAR with invalid physical address)? #GP? Or something else?
The SMD says
"ensure that data for VMCS referenced by the operand is in memory"
but it doesn't appear to say what to do if that is not the case. When the
address itself is faulty (e.g., more than 32 bits in 32 bit mode) the SDM
says VMfail(VMCLEAR with invalid physical address) - but it doesn't say to
do that when the physical address is "simply" beyond the amount of available
memory.
In any case, I don't think this should be considered an internal error, or
that we have a reason to exit to user space in this case.
I think it's safe to KVM_REQ_SHUTDOWN in this case.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
