Xen devel - Nov 2006 - assumptions when hvm guest uses string instructions on MMIO memory

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@lists.xensource.com
http://lists.xensource.com/xen-devel

>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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 29/11/06 16:29, "Jan Beulich" <jbeulich@novell.com> wrote:
> 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.
Although it''s not going to happen for 3.0.4 now, my changes to the
x86_emulate code are being done with the intention that it can replace the
mmio emulator for 3.0.5. This will present a clean uniform interface for all
memory accesses performed during emulation of an instruction.

So don''t get too worked up about the deficiencies of the current mmio
code,
but do feel free to kick the x86_emulate routines. :-)

 -- Keir


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