From: "Andreas Färber" <afaerber@suse.de>
To: Anthony Liguori <anthony@codemonkey.ws>,
Gerd Hoffmann <kraxel@redhat.com>
Cc: "KVM devel mailing list" <kvm@vger.kernel.org>,
"Juan Quintela" <quintela@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Alexander Graf" <agraf@suse.de>,
qemu-devel <qemu-devel@nongnu.org>,
qemu-ppc <qemu-ppc@nongnu.org>,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Alon Levy" <alevy@redhat.com>,
"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: KVM call minutes 2013-01-29 - Port I/O
Date: Wed, 30 Jan 2013 17:54:33 +0100 [thread overview]
Message-ID: <51095049.7090407@suse.de> (raw)
In-Reply-To: <87vcae8wbk.fsf@codemonkey.ws>
Am 30.01.2013 17:33, schrieb Anthony Liguori:
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
>>> 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 because 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.
>
> The best way to handle this would be to remodel how we do VGA.
>
> 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...
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 class
> ought to be responsible for actually adding it to a subregion.
>
>>
>> That twist makes it a bit hard to convert vga ...
>>
>> Anyone knows how one would do that with the memory api instead? I think
>> 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.
>>
>
> 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.
>
> Regards,
>
> Anthony Liguori
>
>> Anyone has clues / suggestions?
>>
>> thanks,
>> Gerd
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-01-30 16:54 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 15:41 KVM call minutes 2013-01-29 Juan Quintela
2013-01-29 16:01 ` Paolo Bonzini
2013-01-29 16:47 ` Anthony Liguori
2013-01-29 17:36 ` Paolo Bonzini
2013-01-29 20:53 ` Alexander Graf
2013-01-29 21:39 ` Anthony Liguori
2013-01-30 7:02 ` What to do about non-qdevified devices? (was: KVM call minutes 2013-01-29) Markus Armbruster
2013-01-30 8:39 ` What to do about non-qdevified devices? Andreas Färber
2013-01-30 10:36 ` What to do about non-qdevified devices? (was: KVM call minutes 2013-01-29) Peter Maydell
2013-01-30 12:35 ` What to do about non-qdevified devices? Markus Armbruster
2013-01-30 13:44 ` [Qemu-devel] " Andreas Färber
2013-01-30 16:58 ` Paolo Bonzini
2013-01-30 17:14 ` [Qemu-devel] " Andreas Färber
2013-01-31 18:48 ` Markus Armbruster
2013-01-30 14:37 ` [Qemu-devel] " Anthony Liguori
2013-01-30 11:39 ` [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O Andreas Färber
2013-01-30 11:48 ` Peter Maydell
2013-01-30 12:31 ` Michael S. Tsirkin
2013-01-30 13:24 ` [Qemu-devel] " Anthony Liguori
2013-01-30 14:11 ` Michael S. Tsirkin
2013-01-30 12:32 ` Alexander Graf
2013-01-30 13:09 ` Markus Armbruster
2013-01-30 15:08 ` [Qemu-devel] " Anthony Liguori
2013-01-30 17:55 ` Andreas Färber
2013-01-30 20:20 ` Michael S. Tsirkin
2013-01-30 20:33 ` [Qemu-devel] " Andreas Färber
2013-01-30 20:55 ` Michael S. Tsirkin
2013-01-30 13:59 ` [Qemu-devel] " Anthony Liguori
2013-01-30 21:05 ` Benjamin Herrenschmidt
2013-01-30 21:39 ` [Qemu-devel] " Anthony Liguori
2013-01-30 21:54 ` Benjamin Herrenschmidt
2013-01-30 22:20 ` Michael S. Tsirkin
2013-01-30 22:32 ` Benjamin Herrenschmidt
2013-01-30 22:49 ` Michael S. Tsirkin
2013-01-30 23:02 ` Benjamin Herrenschmidt
2013-01-30 23:28 ` Alex Williamson
2013-01-31 10:49 ` Michael S. Tsirkin
2013-01-31 16:34 ` Alex Williamson
2013-01-31 21:11 ` Michael S. Tsirkin
2013-01-31 21:21 ` Alex Williamson
2013-01-31 22:20 ` Michael S. Tsirkin
2013-01-31 21:44 ` Benjamin Herrenschmidt
2013-01-31 22:37 ` Michael S. Tsirkin
2013-01-31 23:25 ` Alex Williamson
2013-01-31 21:22 ` Benjamin Herrenschmidt
2013-01-31 22:28 ` Michael S. Tsirkin
2013-01-30 15:45 ` [Qemu-devel] " Gerd Hoffmann
2013-01-30 16:33 ` Anthony Liguori
2013-01-30 16:54 ` Andreas Färber [this message]
2013-01-30 17:29 ` Anthony Liguori
2013-01-30 20:08 ` Michael S. Tsirkin
2013-01-30 20:19 ` Peter Maydell
2013-01-30 20:19 ` [Qemu-devel] " Andreas Färber
2013-01-30 21:07 ` Benjamin Herrenschmidt
2013-01-30 21:42 ` [Qemu-devel] " Anthony Liguori
2013-01-30 17:08 ` Paolo Bonzini
2013-01-30 21:08 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51095049.7090407@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=alevy@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=david@gibson.dropbear.id.au \
--cc=hpoussin@reactos.org \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.