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:50:55 +0000
Delivery-date: Wed, 29 Nov 2006 08:49:17 -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)

- What if the non-MMIO address of MOVS is also in a not present page?

>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>