Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

[Xen-devel] assumptions when hvm guest uses string instructions on MMIO

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] assumptions when hvm guest uses string instructions on MMIO memory
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 29 Nov 2006 16:29:55 +0000
Delivery-date: Wed, 29 Nov 2006 08:28:25 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm wondering if the assumptions currently made are appropriate:

- movs assumes that either address is not in MMIO space (What if the
  guest uses it e.g. on video memory for scrolling?)
- stos and lods assume that the mmio memory is physically contiguous,
  while movs doesn't (and even ins/outs for PIO don't, although I'm
  not clear why, as it still seems to be assumed that the memory
  accessed is not in MMIO space)

Likewise I find it at least strange that all the I/O related
hvm_copy_{from,to}_guest_virt invocations have their return value
cast to void instead of forcing page faults into the guest. While I
can see the point for single datum instructions (the CPU supposedly
did the checking, except perhaps for ins/outs), movs where the
non-mmio address crosses a page boundary and lods/stos because
they're not being broken up would still seem to cause issues. Even
in the single datum case I think it would be much more consistent
to force a fault into the guest rather than silently ignoring any
problems.

Thanks, Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>