[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abo
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort |
Date: |
Mon, 16 Sep 2013 09:14:27 +0300 |
On Sun, Sep 15, 2013 at 10:41:26PM +0100, Peter Maydell wrote:
> On 15 September 2013 22:07, Michael S. Tsirkin <address@hidden> wrote:
> > On Sun, Sep 15, 2013 at 09:40:37PM +0100, Peter Maydell wrote:
> >> "native" means "if the device's MMIO callback does 'return 0x12345678;'
> >> for a 32 bit read then the guest CPU should see 0x12345678". That's
> >> almost always what you want for simple devices (which may in fact
> >> only support 32 bit accesses to registers), because it means you don't
> >> have to fill your device with explicit endianness swaps.
> >
> > But this means that you device behaves differently
> > depending on the endian-ness of the guest system.
> > So it only makes sense if the device is very
> > system specific
>
> If you mark a device as specifically DEVICE_LITTLE_ENDIAN
> or DEVICE_BIG_ENDIAN this is *also* very system specific.
No, this just means the device is always wired in
the same way on all systems. It's the pragmatic
choice for any bus that supports device plug-in.
> So you're a bit stuck either way. As I say, for basic "this just
> provides a bunch of registers" devices _NATIVE_ is the
> pragmatic answer, since it effectively models the way that the
> same bit of hardware is wired up to the bus differently if it's
> expected to be in a big or little endian system.
> (Any device where you can make byte accesses into the "middle"
> of a 32 bit register probably needs to think more carefully, but those
> are pretty rare.)
>
> >anything outside hw/<specific architecture>
> > is at least in theory not a system specific device
>
> This is wrong, by the way. hw/$arch contains:
> * board models
> * things we haven't properly separated out into self contained devices
> * random "not actually a device" things like boot code
>
> Anything that's really a device goes in its appropriate subdirectory
> (char, video, etc etc), whether it happens to be used only on one
> system or one architecture or not. (For instance all the interrupt
> controllers live in hw/intc though obviously they're hopelessly
> system specific.)
>
> -- PMM
Thanks for the clarification.
- [Qemu-devel] [PATCH v4 2/3] docs/memory: Explicitly state that MemoryRegion priority is signed, (continued)
- [Qemu-devel] [PATCH v4 2/3] docs/memory: Explicitly state that MemoryRegion priority is signed, Marcel Apfelbaum, 2013/09/15
- [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Marcel Apfelbaum, 2013/09/15
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Michael S. Tsirkin, 2013/09/15
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Peter Maydell, 2013/09/15
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Marcel Apfelbaum, 2013/09/15
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Michael S. Tsirkin, 2013/09/15
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Peter Maydell, 2013/09/15
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Michael S. Tsirkin, 2013/09/15
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Peter Maydell, 2013/09/15
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort,
Michael S. Tsirkin <=
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Peter Maydell, 2013/09/16
- Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort, Marcel Apfelbaum, 2013/09/15