From: malc <av1474@comtv.ru>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Alex Graf <agraf@suse.de>,
qemu-devel@nongnu.org, Michael Tsirkin <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 07/15] ac97: convert to new PCI API
Date: Wed, 10 Feb 2010 03:24:19 +0300 (MSK) [thread overview]
Message-ID: <alpine.LNX.2.00.1002100319330.18215@linmac> (raw)
In-Reply-To: <4B71F545.2080001@codemonkey.ws>
On Tue, 9 Feb 2010, Anthony Liguori wrote:
> On 02/09/2010 05:36 PM, malc wrote:
> > Let's see:
> >
> > Currently we have this
> >
> >
> > readb(...):
> > dostuff
> > return stuff
> >
> > readw(...):
> > dostuff
> > return stuff
> >
>
> And this is completely wrong.
It's completely right, until some future C standard implements proper
algebraic data types.
>
> For the most part, device models don't consistently handle access to registers
> via their non native sizes. Some devices return the lower part of a dword
> register when accessed with a word accessor. Some devices only return the
> register when there's a dword access.
That's up to device to register an accessor and return what's appropriate.
>
> What's worse, is that if a device only registers a byte accessor, because of
> the default accessors, a word access returns two registers but a dword access
> returns ~0U. Some device models actually rely on this behaviour.
>
> > You are replacing it with
> >
> > read(size...):
> > if (size == 1): do1
> > elif (size == 2): do2
> > else: # and here your code assumes that everything is handy dandy
> > # and size is 4
> > do4
> >
>
> This is ugly because it's a programmatic conversion. Once we have this API,
> we can switch to:
>
> read(addr, size...):
> switch(addr):
> case REG0:
> return s->reg0;
> case REG1:
> return s->reg1;
This is exactly equivalent to your original if, due to the C language
being what it is.
> Along with having a table like:
>
> pci_regs = { {REG0, DWORD}, {REG1, BYTE}, {REG2, BYTE}, {REG3, WORD} }
>
> That allows the PCI layer to invoke the callback and do the right operations
> to transparently handle the access size without the device model having to
> deal with it. The reason I've left size in the callback at all is that I
> suspect there will always be a device that behaves weirdly and needs to know
> about the accessor size. But for the most part, I think this model will make
> things much more consistent and eliminate a huge class of emulation bugs.
Eh? Care to name one emulation bug?
>
> We can even take it further, and do something like:
>
> pci_regs = {
> PCI_REG_DWORD(REG0, DeviceState, reg0),
> PCI_REG_BYTE(REG1, DeviceState, reg1),
> ...
> }
>
> In which case, we only need to handle the case in switch() if we need to
> implement a side effect of the register operation.
>
> But none of this is possible if we completely rely on every device to
> implement non-dword access in it's own broken way.
>
Lovely, we are heading full speed into fanatsy land, where PCI BUS itself
accesses device specific stuff.
--
mailto:av1474@comtv.ru
next prev parent reply other threads:[~2010-02-10 0:24 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-09 22:01 [Qemu-devel] [PATCH 0/15][RFC] New PCI interfaces Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 01/15] pci: add new bus functions Anthony Liguori
2010-02-10 8:09 ` Isaku Yamahata
2010-02-10 8:57 ` [Qemu-devel] " Michael S. Tsirkin
2010-02-09 22:01 ` [Qemu-devel] [PATCH 02/15] rtl8139: convert to new PCI interfaces Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 03/15] lsi53c895a: convert to new pci interfaces Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 04/15] e1000: convert to new pci interface Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 05/15] wdt_i6300esb: fix io type leakage Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 06/15] wdt_i6300esb: convert to new pci inteface Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 07/15] ac97: convert to new PCI API Anthony Liguori
2010-02-09 22:45 ` malc
2010-02-09 22:52 ` Anthony Liguori
2010-02-09 23:06 ` malc
2010-02-09 23:10 ` Anthony Liguori
2010-02-09 23:36 ` malc
2010-02-09 23:52 ` Anthony Liguori
2010-02-10 0:24 ` malc [this message]
2010-02-11 14:20 ` Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 08/15] es1370: convert to new pci interface Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 09/15] eepro100: " Anthony Liguori
2010-02-10 6:32 ` Stefan Weil
2010-02-10 9:49 ` [Qemu-devel] " Michael S. Tsirkin
2010-02-10 10:43 ` Markus Armbruster
2010-02-10 10:48 ` Michael S. Tsirkin
2010-02-10 14:13 ` [Qemu-devel] " Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 10/15] virtio-pci: " Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 11/15] pci: add pci_register_msix_region Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 12/15] ne2000: convert to new pci interface Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 13/15] pcnet: " Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 14/15] usb-uhci: " Anthony Liguori
2010-02-09 22:01 ` [Qemu-devel] [PATCH 15/15] pci: byte swap as PCI interface layer Anthony Liguori
2010-02-10 9:31 ` [Qemu-devel] Re: [PATCH 0/15][RFC] New PCI interfaces Michael S. Tsirkin
2010-02-10 18:34 ` [Qemu-devel] " Blue Swirl
2010-02-10 19:29 ` Anthony Liguori
2010-02-10 20:41 ` Richard Henderson
2010-02-10 21:13 ` Anthony Liguori
2010-02-12 17:40 ` Blue Swirl
2010-03-01 2:51 ` Paul Brook
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=alpine.LNX.2.00.1002100319330.18215@linmac \
--to=av1474@comtv.ru \
--cc=agraf@suse.de \
--cc=anthony@codemonkey.ws \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).