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. Thanks, Nadav. -- Nadav Har'El | Thursday, Aug 5 2010, 25 Av 5770 nyh@xxxxxxxxxxxxxxxxxxx |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |Thousands of years ago, cats were http://nadav.harel.org.il |worshipped as gods. They never forgot. -- 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
