2011/1/25 Prasad Joshi <prasadjoshi124@xxxxxxxxx>: > Hello, > > This is to announce that, we have been able to pass-through a ATI > Radeon RV370 FireGL V3100 to Ubuntu VM. This card was attached to a > separate monitor, after passing-through the Keyboard and Mouse > everything worked as normal. > > The changes we made are very less, mostly disabling default QEMU VGA. > > But there are few problems that we are still working on > 1. The display on the monitor, probably only appears after the KMS is > enabled. It does not display the grub menu and booting log. Sounds like you're not enabling legacy VGA MMIO and I/O port space to the physical device. Without card specific drivers, seabios and grub have no way to write to the screen. > 2. If we intermix the QEMU default devices like Network or another > VGA. The VM does not work properly. We could see IO_PAGE_FAULT events > being logged in the system messages. I guess this is happening because > of some memory region conflicts. > > But if we pass-through a Network device and a GPU card to VM it works > perfectly. Till now we only observed problem when QEMU default devices > were intermixed with the pass-through ATI card. > > 3. Windows does not work at all. No display, lots of IO_PAGE_FAULT events. > > 4. The card that we used is somewhat old one. "Andrà Weidemann" > <Andre.Weidemann@xxxxxx> is trying to pass-through a relatively new > ATI card. We will have results very soon. > > 5. Nvidia or Intel IGD cards have not been tested. > > Currently I am focusing on solving problem 2 and 1. I am very new to > KVM and QEMU, I willÂappreciateÂif someone can help me or point me to > a correct direction. Once these problems are solved I will send the > patches for comments on this mailing list. As we've discussed on irc, vga routing and arbitration is a hard problem, especially if you want to support multiple graphics cards, potentially assigning some to guests and using others in the host. I'm not sure why you're having problems using an emulated nic alongside an assigned gfx card, but the lack of bios, grub, or windows support seems to indicate you're not properly handling the legacy address space. At a minimum, you need to do a cpu_register_physical_memory() for the VGA range starting at 0xa0000 and register ioport handers (register_ioport_read/write) for the range starting at 0x3b0. These need to be backed by a /dev/mem mapping for the mmio and in*/out* for the ioports. You'll also find there are some chipset routines that like to steal back ownership of these ranges, see for instance i440fx_update_memory_mappings(). That may be enough to get things working a little better, but it's a huge kludge. It would perhaps be nice if x86 supported HAVE_PCI_LEGACY in pci-sysfs so we could maybe let the kernel do the heavy lifting of reconfiguring chipset vga routing. This would avoid qemu needing to open /dev/mem and do raw ioport accesses as well. We also need proper vga arbitration so we don't stomp on other qemu instances or host userspace from accessing their cards. The vga_arbiter exists, but it doesn't seem to be widely used. I wonder if we might be better off letting the legacy pci-sysfs interface do the arbitration since X already knows how to use that on some architectures... numerous problems that need to be tacked here. So while your initial results are promising, my guess is that you're using card specific drivers and still need to consider some of the harder problems with generic support for vga assignment. I hacked on this for a bit trying to see if I could get vga assignment working with the vfio driver. Setting up the legacy access and preventing qemu from stealing it back should get you basic vga modes and might even allow the option rom to run to initialize the card for pre-boot. I was able to get this far on a similar ATI card. I never hard much luck with other cards though, and I was never able to get the vesa extensions working. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
