WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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>