Re: HVM performance deficiencies

["Jonathan A. Kollasch" <jakllsch%kollasch.net@localhost>]

On Thu, Jan 14, 2010 at 06:21:30PM +0100, Wolfgang Solfrank wrote:
> Hi,
> 
> NetBSD has several performance deficiencies when run as an HVM guest
> under Xen.  The problem stems from the fact that the qemu hardware
> emulation isn't completely compatible with real hardware, and our
> drivers misidentify and/or misuse some features:
> 
> 1. While the emulated IDE-controller (part of the PIIX3 chipset)
> is capable of DMA (but not UDMA), and the emulated disk claims to
> support DMA mode 2 and UDMA mode 5, this is not detected.  The
> problem is that the disk claims to not support any PIO modes.
> Our ata driver finds this suspicious and assumes that DMA would
> be buggy, too (see sys/dev/ata.c, around line 1260), using only
> PIO mode 0 subsequently.  This results in excess interrupt
> handling overhead in the wd driver.
> 
> 2. The emulated realtek 8139C+ device doesn't implement the
> timer interrupt (while there is a compile time option in qemu
> to enable this, it's normally disabled, and I'm not sure whether
> it would be of much help either).  This interrupt is unconditionally
> (in contrast to the FreeBSD driver, which our driver claims to
> be based upon) used within our re(4) driver to reduce the transmission
> interrupt rate, i.e., the driver doesn't use 'TX done' interrupts, but
> instead posts several packets for transmission and then starts
> the timer for some short period, handling transmission completion
> when the timer triggers.  As the emulated device doesn't implement
> this timer, we get a lot of watchdog timeouts (see PR#41679).
> 
> While both could be fixed in qemu, there are situations where
> the qemu implementation isn't under the control of someone
> running NetBSD under Xen.  And as the OS is running as an HVM
> guest in this instances, the drivers should probably deal with
> this by default.

> So how to fix this?  Is runtime detection of the problem appropriate?
> If so, should it be targeted at qemu only (e.g. by comparing the
> disk model against "QEMU HARDDISK"), or should we aim for some
> wider approach (like always checking DMA modes even if the drive
> doesn't claim to support any PIO modes)?
> 

Adding quirks for quirkily emulated hardware that can easily be
fixed in the appropriate place seems like a Bad Move.

These are really quite simple fixes.
Define RTL8139_ONBOARD_TIMER, set word 64 to 3 in ide_identify(),
and switch to pci_piix4_ide_init() (from piix3) in pc_init1() so
that the controller claims to be capable of UDMA.

Please take these issues up with qemu and xen.

        Jonathan Kollasch