From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= Subject: Re: KVM call minutes 2013-01-29 - Port I/O Date: Wed, 30 Jan 2013 17:54:33 +0100 Message-ID: <51095049.7090407@suse.de> References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de> <51094024.20803@redhat.com> <87vcae8wbk.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: KVM devel mailing list , Juan Quintela , "Michael S. Tsirkin" , Alexander Graf , qemu-devel , qemu-ppc , =?ISO-8859-1?Q?Herv=E9_Poussineau?= , Alon Levy , David Gibson To: Anthony Liguori , Gerd Hoffmann Return-path: In-Reply-To: <87vcae8wbk.fsf@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org Am 30.01.2013 17:33, schrieb Anthony Liguori: > Gerd Hoffmann writes: >=20 >>> hw/qxl.c: portio_list_add(qxl_vga_port_list, >>> pci_address_space_io(dev), 0x3b0); >>> hw/vga.c: portio_list_add(vga_port_list, address_space_io, 0x3= b0); >> >> That reminds me I should solve this in a more elegant way. >> >> qxl takes over the vga io ports. The reason it does this is because q= xl >> switches into vga mode in case the vga ports are accessed while not in >> vga mode. After doing the check (and possibly switching mode) the vga >> handler is called to actually handle it. >=20 > The best way to handle this would be to remodel how we do VGA. >=20 > Make VGACommonState a proper QOM object and use it as the base class fo= r > QXL, CirrusVGA, QEMUVGA (std-vga), and VMwareVGA. That would require polymorphism since we already need to derive from PCIDevice or ISADevice respectively for interfacing with the bus... Modern object-oriented languages have tried to avoid multi-inheritence due to arising complications, I thought. Wouldn't object if someone wanted to do the dirty implementation work though. ;) Another such example is EHCI, with PCIDevice and SysBusDevice frontends, sharing an EHCIState struct and having helper functions operating on that core state only. Quite a few device share such a pattern today actually (serial, m48t59, ...). > The VGA accessors should be exposed as a memory region but the sub clas= s > ought to be responsible for actually adding it to a subregion. >=20 >> >> That twist makes it a bit hard to convert vga ... >> >> Anyone knows how one would do that with the memory api instead? I thin= k >> taking over the ports is easy as the memory regions have priorities so= I >> can simply register a region with higher priority. I have no clue how = to >> forward the access to the vga code though. >> >=20 > That should be possible with priorities, but I think it's wrong. There > aren't two VGA devices. QXL is-a VGA device and the best way to > override behavior of base VGA device is through polymorphism. In this particular case QXL is-a PCI VGA device though, so we can decouple it from core VGA modeling. Placing the MemoryRegionOps inside the Class (rather than static const) might be a short-term solution for overriding read/write handlers of a particular VGA MemoryRegion. :) Cheers, Andreas > This isn't really a memory API issue, it's a modeling issue. >=20 > Regards, >=20 > Anthony Liguori >=20 >> Anyone has clues / suggestions? >> >> thanks, >> Gerd --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg