[Xen-devel] I/O port access handling for PVH

["Jan Beulich" <JBeulich@xxxxxxxx>]

George,

since you asked on Friday, I though about the situation some more
over the weekend.

On PV, the requirement to trap all INs and OUTs is a result from us
needing the enforce two levels of restrictions - Xen's and the guest
kernel's. I.e. we can't make use of the hardware's access control
mechanisms, as we can't put two I/O bit maps in place, and we
(obviously) can't run the guest kernel at IOPL 0.

On PVH, otoh, we do have two bitmaps, and hence we could at
least allow those port accesses to go without interception that
Xen doesn't need to do any internal state keeping on (and of
course also only for those the guest is allowed to access). That
would make - for PVH - unnecessary a significant part of
emulate_privileged_op(): In essence, all you'd need to wire up
are guest_io_read() and guest_io_write().

In particular it would then hopefully be safe to do all that without
the on-stack emulation stub, as this ought to be necessary only
for Dom0, which ought to always have direct access to such
"special" I/O ports. With one apparent caveat: SVM sets
GENERAL1_INTERCEPT_SMI (for a reason that escapes my right
now), and hence control doesn't transfer directly to SMM when
an SMI occurs (and consequently registers aren't expected). But
I would hope that this intercept isn't really needed, and hence
could be dropped at least for PVH guests.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel