|
Thanks for the comments. Frankly, I’m
guessing the bulk of the time in the COM port IO is VMEXIT time, and that saving
qemu round-trip would be a marginal effect**. As for the read’s flushing writes,
this happens automatically as a result of how the buffered_io page works (and
assuming one sticks to this design for IO buffering). If dir == IOREQ_READ
then attempt to buffered the IO request will fail. Thus, hvm_send_assist_req
is invoked. When qemu catches the “notify” event of the READ
it firsts dispatches *all* of the
buffered io requests before dispatching the READ. Thus order is preserved and inb
are synchronous from the vcpu point of view. As for controlling outbound FIFO depth,
adding a per range “max_depth” test to the “queue is full”
test already in use for mmio buffering would be straight forward. The interrupt issues are more
concerning. A one byte write “window” at 3F8 doesn’t
seem to have this issue (c.f.) ftp://ftp.phil.uni-sb.de/pub/staff/chris/The_Serial_Port But I agree that proxy device models are
not desirable when not performance critical. Regardless, they wouldn’t be
supported directly though a simple “hvm_buffered_io_intercept” call.
This would be more suited to the approach used in hvm_mmio_intercept to
do the lapic emulation. John ** For those interested, I’m looking
at the performance of using Windbg for Guest domain debug, and the time to do
the serial port based initialization of a kernel debug session. Starting a
WinDBG session on a Windows guest OS takes several minutes. Any suggestions to
optimize that process would be gladly entertained. From: Keir Fraser
[mailto:keir@xxxxxxxxxxxxx] Yes, it strikes me that this cannot
be done safely without providing a set of ‘proxy device models’ in
the hypervisor that know when it is safe to buffer and when the buffers must be
flushed, according to native hardware behaviour. Safety would depend on how the emulated device works. For
serial ports in particular, it's definitely not safe, since depending on the
model of UART emulated, and the settings of the UART control registers, every
outb may result in a serial interrupt and UART register changes that will have
to be processed before any further io can be done.
_______________________________________________ |
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel