On 17.05.2009, at 22:58, Avi Kivity wrote:
Alexander Graf wrote:
I can't think why it was done for writes. Normally, a guest page
fault would be trapped and reflected a long time before emulation,
in FNAME(page_fault)(), after walk_addr().
Can you give some details on the situation?
Alexander Graf wrote:
If we couldn't find a page on read_emulated, it might be a good
idea to tell the guest about that and inject a #PF.
We do the same already for write faults. I don't know why it was
not implemented for reads.
I can't think why it was done for writes. Normally, a
On 17.05.2009, at 21:59, Avi Kivity a...@redhat.com wrote:
Alexander Graf wrote:
If we couldn't find a page on read_emulated, it might be a good
idea to tell the guest about that and inject a #PF.
We do the same already for write faults. I don't know why it was
not implemented for reads.
Alexander Graf wrote:
I can't think why it was done for writes. Normally, a guest page
fault would be trapped and reflected a long time before emulation, in
FNAME(page_fault)(), after walk_addr().
Can you give some details on the situation? What instruction was
executed, and why kvm
If we couldn't find a page on read_emulated, it might be a good
idea to tell the guest about that and inject a #PF.
We do the same already for write faults. I don't know why it was
not implemented for reads.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/x86/kvm/x86.c |7 +--
1
On Fri, May 15, 2009 at 10:22:17AM +0200, Alexander Graf wrote:
If we couldn't find a page on read_emulated, it might be a good
idea to tell the guest about that and inject a #PF.
We do the same already for write faults. I don't know why it was
not implemented for reads.
Have you checked
