From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: assumptions when hvm guest uses string instructions on MMIO memory Date: Wed, 29 Nov 2006 16:29:55 +0000 Message-ID: <456DC393.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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