From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O Date: Wed, 30 Jan 2013 11:29:58 -0600 Message-ID: <87r4l260kp.fsf@codemonkey.ws> References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de> <51094024.20803@redhat.com> <87vcae8wbk.fsf@codemonkey.ws> <51095049.7090407@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Juan Quintela , KVM devel mailing list , qemu-devel , Alexander Graf , Benjamin Herrenschmidt , qemu-ppc , =?utf-8?Q?Herv=C3=A9?= Poussineau , David Gibson , Alon Levy , "Michael S. Tsirkin" To: Andreas =?utf-8?Q?F=C3=A4rber?= , Gerd Hoffmann Return-path: Received: from mail-ie0-f182.google.com ([209.85.223.182]:45038 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753674Ab3A3RaE convert rfc822-to-8bit (ORCPT ); Wed, 30 Jan 2013 12:30:04 -0500 Received: by mail-ie0-f182.google.com with SMTP id k14so1527786iea.13 for ; Wed, 30 Jan 2013 09:30:03 -0800 (PST) In-Reply-To: <51095049.7090407@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Andreas F=C3=A4rber writes: > 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, = 0x3b0); >>> >>> 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 becaus= e qxl >>> 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= for >> 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... Nope. You can use composition: QXLDevice is-a VGACommonState QXLPCI is-a PCIDevice has-a QXLDevice > Modern object-oriented languages have tried to avoid multi-inheritenc= e > due to arising complications, I thought. Wouldn't object if someone > wanted to do the dirty implementation work though. ;) There is no need for MI. > Another such example is EHCI, with PCIDevice and SysBusDevice fronten= ds, > 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, ...). Yes, this is all about chipset modelling. Chipsets should derive from device and then be embedded in the appropriate bus device. =46or instance. SerialState is-a DeviceState ISASerialState is-a ISADevice, has-a SerialState MMIOSerialState is-a SysbusDevice, has-a SerialState This is what we're doing in practice, we just aren't modeling the chipsets and we're open coding the relationships (often in subtley different ways). Regards, Anthony Liguori >> The VGA accessors should be exposed as a memory region but the sub c= lass >> 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 t= hink >>> 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 h= ow to >>> forward the access to the vga code though. >>> >>=20 >> That should be possible with priorities, but I think it's wrong. Th= ere >> 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 insid= e > the Class (rather than static const) might be a short-term solution f= or > 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=C3=BCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N= =C3=BCrnberg