On Tue, Sep 10, 2013 at 02:12:56PM +0100, Peter Maydell wrote:
On 10 September 2013 14:02, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 10, 2013 at 01:50:47PM +0100, Peter Maydell wrote:
On 10 September 2013 13:39, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at
On Tue, 2013-09-10 at 14:12 +0100, Peter Maydell wrote:
On 10 September 2013 14:02, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 10, 2013 at 01:50:47PM +0100, Peter Maydell wrote:
On 10 September 2013 13:39, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at
On 15 September 2013 08:14, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 10, 2013 at 02:12:56PM +0100, Peter Maydell wrote:
On 10 September 2013 14:02, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 10, 2013 at 01:50:47PM +0100, Peter Maydell wrote:
On 10 September 2013
On Sun, Sep 15, 2013 at 11:56:40AM +0100, Peter Maydell wrote:
On 15 September 2013 08:14, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 10, 2013 at 02:12:56PM +0100, Peter Maydell wrote:
On 10 September 2013 14:02, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 10, 2013 at
On 15 September 2013 12:05, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 11:56:40AM +0100, Peter Maydell wrote:
The alias will win for the addresses it handles. But if
the alias is a container with holes then it doesn't handle
the holes and the lower priority background
On Sun, Sep 15, 2013 at 12:23:41PM +0100, Peter Maydell wrote:
On 15 September 2013 12:05, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 11:56:40AM +0100, Peter Maydell wrote:
The alias will win for the addresses it handles. But if
the alias is a container with holes
On 15 September 2013 13:17, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 12:23:41PM +0100, Peter Maydell wrote:
. If it's a pure container then it
doesn't respond for areas that none of its subregions
cover (it can't, it has no idea what it should do).
Interesting. This
On Sun, Sep 15, 2013 at 02:24:07PM +0100, Peter Maydell wrote:
On 15 September 2013 13:17, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 12:23:41PM +0100, Peter Maydell wrote:
. If it's a pure container then it
doesn't respond for areas that none of its subregions
cover
On 15 September 2013 14:39, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 02:24:07PM +0100, Peter Maydell wrote:
Yes, that's true, but even then it's usually just overlaps
of subregions within a single container and there isn't
a need to worry about within-container versus
On Sun, Sep 15, 2013 at 02:49:32PM +0100, Peter Maydell wrote:
On 15 September 2013 14:39, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 02:24:07PM +0100, Peter Maydell wrote:
Yes, that's true, but even then it's usually just overlaps
of subregions within a single
On 15 September 2013 15:08, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 02:49:32PM +0100, Peter Maydell wrote:
Yes, but if we were applying a sensible set of priorities
then you don't need to care at all about the contents
of the pci hole container, because the pci hole
On Sun, Sep 15, 2013 at 03:08:38PM +0100, Peter Maydell wrote:
On 15 September 2013 15:08, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 02:49:32PM +0100, Peter Maydell wrote:
Yes, but if we were applying a sensible set of priorities
then you don't need to care at all
On 15 September 2013 15:20, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 03:08:38PM +0100, Peter Maydell wrote:
Well, that's your choice, but I'd be really surprised if the
PCI controller allowed PCI BARs to get mapped over the
top of builtin devices like that.
Well it
On Sun, Sep 15, 2013 at 03:49:00PM +0100, Peter Maydell wrote:
On 15 September 2013 15:20, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 03:08:38PM +0100, Peter Maydell wrote:
Well, that's your choice, but I'd be really surprised if the
PCI controller allowed PCI BARs to
On 15 September 2013 16:05, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 03:49:00PM +0100, Peter Maydell wrote:
On 15 September 2013 15:20, Michael S. Tsirkin m...@redhat.com wrote:
Actually you previosly wrote:
the versatilePB's PCI controller only responds to
On Sun, Sep 15, 2013 at 04:08:26PM +0100, Peter Maydell wrote:
On 15 September 2013 16:05, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 03:49:00PM +0100, Peter Maydell wrote:
On 15 September 2013 15:20, Michael S. Tsirkin m...@redhat.com wrote:
Actually you previosly
On 15 September 2013 16:31, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 15, 2013 at 04:08:26PM +0100, Peter Maydell wrote:
The aborts I refer to above are if you misprogram the
device to try to do a bus master access to some part of
PCI memory space other than where the host
On Mon, Sep 09, 2013 at 02:16:41PM +0100, Peter Maydell wrote:
On 9 September 2013 14:07, Marcel Apfelbaum marce...@redhat.com wrote:
This is exactly my point. ALL device on the bus can be masters
of a DMA transaction. So adding an interface as suggested by
Michael:
On 10 September 2013 13:39, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 02:16:41PM +0100, Peter Maydell wrote:
memory_region_init_alias(pci_dev-bus_master_enable_region,
OBJECT(pci_dev), bus master,
On Tue, Sep 10, 2013 at 01:50:47PM +0100, Peter Maydell wrote:
On 10 September 2013 13:39, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 02:16:41PM +0100, Peter Maydell wrote:
memory_region_init_alias(pci_dev-bus_master_enable_region,
On 10 September 2013 14:02, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 10, 2013 at 01:50:47PM +0100, Peter Maydell wrote:
On 10 September 2013 13:39, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 02:16:41PM +0100, Peter Maydell wrote:
On Tue, Sep 10, 2013 at 02:12:56PM +0100, Peter Maydell wrote:
On 10 September 2013 14:02, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 10, 2013 at 01:50:47PM +0100, Peter Maydell wrote:
On 10 September 2013 13:39, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at
Created a MemoryRegion with negative priority that
spans over all the pci address space.
It intercepts the accesses to unassigned pci
address space and will follow the pci spec:
1. returns -1 on read
2. does nothing on write
3. sets the RECEIVED MASTER ABORT bit in the STATUS register
of
On Mon, Sep 09, 2013 at 02:11:54PM +0300, Marcel Apfelbaum wrote:
Created a MemoryRegion with negative priority that
spans over all the pci address space.
It intercepts the accesses to unassigned pci
address space and will follow the pci spec:
1. returns -1 on read
2. does nothing on write
On Mon, 2013-09-09 at 14:40 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 02:11:54PM +0300, Marcel Apfelbaum wrote:
Created a MemoryRegion with negative priority that
spans over all the pci address space.
It intercepts the accesses to unassigned pci
address space and will
On Mon, Sep 09, 2013 at 03:11:55PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 14:40 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 02:11:54PM +0300, Marcel Apfelbaum wrote:
Created a MemoryRegion with negative priority that
spans over all the pci address space.
It
On Mon, 2013-09-09 at 15:23 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 03:11:55PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 14:40 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 02:11:54PM +0300, Marcel Apfelbaum wrote:
Created a MemoryRegion with
On 9 September 2013 13:43, Marcel Apfelbaum marce...@redhat.com wrote:
The scenario is covered only for the primary bus and not for buses
behind the PCI bridge (the later being handled differently.)
In this case, isn't the Host Bridge always device 00.0?
No. For instance the host controller
On Mon, Sep 09, 2013 at 01:52:11PM +0100, Peter Maydell wrote:
On 9 September 2013 13:43, Marcel Apfelbaum marce...@redhat.com wrote:
The scenario is covered only for the primary bus and not for buses
behind the PCI bridge (the later being handled differently.)
In this case, isn't the Host
On 9 September 2013 13:59, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 01:52:11PM +0100, Peter Maydell wrote:
It would be conceptually nicer not to treat host bridges as
a special case but instead to just report the abort back
to whatever the PCI master was (which might
On Mon, 2013-09-09 at 13:52 +0100, Peter Maydell wrote:
On 9 September 2013 13:43, Marcel Apfelbaum marce...@redhat.com wrote:
The scenario is covered only for the primary bus and not for buses
behind the PCI bridge (the later being handled differently.)
In this case, isn't the Host Bridge
On Mon, 2013-09-09 at 14:02 +0100, Peter Maydell wrote:
On 9 September 2013 13:59, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 01:52:11PM +0100, Peter Maydell wrote:
It would be conceptually nicer not to treat host bridges as
a special case but instead to just report
On 9 September 2013 14:07, Marcel Apfelbaum marce...@redhat.com wrote:
This is exactly my point. ALL device on the bus can be masters
of a DMA transaction. So adding an interface as suggested by
Michael: pci_set_master_for_master_abort(PCIBus *, PCIDevice *)
for the general case (a device
On 9 September 2013 14:15, Marcel Apfelbaum marce...@redhat.com wrote:
On Mon, 2013-09-09 at 14:02 +0100, Peter Maydell wrote:
Can you just pick the device which is (a subclass of)
TYPE_PCI_HOST_BRIDGE, or do we have host bridges which
aren't using that class?
This is what I would really want
On Mon, 2013-09-09 at 14:19 +0100, Peter Maydell wrote:
On 9 September 2013 14:15, Marcel Apfelbaum marce...@redhat.com wrote:
On Mon, 2013-09-09 at 14:02 +0100, Peter Maydell wrote:
Can you just pick the device which is (a subclass of)
TYPE_PCI_HOST_BRIDGE, or do we have host bridges which
On 9 September 2013 14:29, Marcel Apfelbaum marce...@redhat.com wrote:
My issue is that we have at least 2 ways to model the bridges:
1. TYPE_PCI_HOST_BRIDGE
* derives from TYPE_SYS_BUS_DEVICE
* has a bus
* one of the bus devices is a TYPE_I440FX_PCI_DEVICE which
derives from
On Mon, 2013-09-09 at 14:16 +0100, Peter Maydell wrote:
On 9 September 2013 14:07, Marcel Apfelbaum marce...@redhat.com wrote:
This is exactly my point. ALL device on the bus can be masters
of a DMA transaction. So adding an interface as suggested by
Michael:
On Mon, Sep 09, 2013 at 03:43:49PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 15:23 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 03:11:55PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 14:40 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 02:11:54PM
On Mon, Sep 09, 2013 at 02:02:47PM +0100, Peter Maydell wrote:
On 9 September 2013 13:59, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 01:52:11PM +0100, Peter Maydell wrote:
It would be conceptually nicer not to treat host bridges as
a special case but instead to just
On Mon, Sep 09, 2013 at 04:07:53PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 13:52 +0100, Peter Maydell wrote:
On 9 September 2013 13:43, Marcel Apfelbaum marce...@redhat.com wrote:
The scenario is covered only for the primary bus and not for buses
behind the PCI bridge (the
On Mon, 2013-09-09 at 14:39 +0100, Peter Maydell wrote:
On 9 September 2013 14:29, Marcel Apfelbaum marce...@redhat.com wrote:
My issue is that we have at least 2 ways to model the bridges:
1. TYPE_PCI_HOST_BRIDGE
* derives from TYPE_SYS_BUS_DEVICE
* has a bus
* one of the bus
On Mon, Sep 09, 2013 at 04:29:04PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 14:19 +0100, Peter Maydell wrote:
On 9 September 2013 14:15, Marcel Apfelbaum marce...@redhat.com wrote:
On Mon, 2013-09-09 at 14:02 +0100, Peter Maydell wrote:
Can you just pick the device which is (a
On Mon, 2013-09-09 at 16:58 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 03:43:49PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 15:23 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 03:11:55PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 14:40 +0300,
On Mon, 2013-09-09 at 17:04 +0300, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 04:29:04PM +0300, Marcel Apfelbaum wrote:
On Mon, 2013-09-09 at 14:19 +0100, Peter Maydell wrote:
On 9 September 2013 14:15, Marcel Apfelbaum marce...@redhat.com wrote:
On Mon, 2013-09-09 at 14:02 +0100,
On 9 September 2013 15:04, Marcel Apfelbaum marce...@redhat.com wrote:
By the way, I am not sure that the upstream transactions (DMA)
can actually end with a master abort. Master abort would happen
if a transaction will not be claimed by any device on the bus.
But in DMA transactions, maybe
On Mon, 2013-09-09 at 15:21 +0100, Peter Maydell wrote:
On 9 September 2013 15:04, Marcel Apfelbaum marce...@redhat.com wrote:
By the way, I am not sure that the upstream transactions (DMA)
can actually end with a master abort. Master abort would happen
if a transaction will not be claimed
On 9 September 2013 15:51, Marcel Apfelbaum marce...@redhat.com wrote:
On Mon, 2013-09-09 at 15:21 +0100, Peter Maydell wrote:
No, it's perfectly possible for a bus master transaction
to abort. The PC's host controller happens to be set up so
that bus master DMA covers the whole of the PCI
On Mon, Sep 09, 2013 at 03:58:36PM +0100, Peter Maydell wrote:
On 9 September 2013 15:51, Marcel Apfelbaum marce...@redhat.com wrote:
On Mon, 2013-09-09 at 15:21 +0100, Peter Maydell wrote:
No, it's perfectly possible for a bus master transaction
to abort. The PC's host controller happens
On Mon, Sep 09, 2013 at 03:21:44PM +0100, Peter Maydell wrote:
On 9 September 2013 15:04, Marcel Apfelbaum marce...@redhat.com wrote:
By the way, I am not sure that the upstream transactions (DMA)
can actually end with a master abort. Master abort would happen
if a transaction will not be
On 9 September 2013 17:00, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 03:58:36PM +0100, Peter Maydell wrote:
On 9 September 2013 15:51, Marcel Apfelbaum marce...@redhat.com wrote:
On Mon, 2013-09-09 at 15:21 +0100, Peter Maydell wrote:
No, it's perfectly possible for a
On 2013-09-09 18:58, Peter Maydell wrote:
On 9 September 2013 17:54, Jan Kiszka jan.kis...@siemens.com wrote:
DMA requests from one device to another targeting anything else but
RAM-backed regions will have to be rejected by QEMU in the future. We
cannot map this sanely on a per-device locking
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 18:58, Peter Maydell wrote:
Why is a DMA request any different from any other communication
between two devices?
Other communication between devices requiring to take the target
device's lock while holding the
On 2013-09-09 18:34, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 05:02:15PM +0100, Peter Maydell wrote:
On 9 September 2013 17:00, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 03:58:36PM +0100, Peter Maydell wrote:
On 9 September 2013 15:51, Marcel Apfelbaum
Il 09/09/2013 19:27, Jan Kiszka ha scritto:
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 18:58, Peter Maydell wrote:
Why is a DMA request any different from any other communication
between two devices?
Other
Il 09/09/2013 20:06, Jan Kiszka ha scritto:
archive, was in the context of lock-less MMIO dispatching), and the
consensus back then was that device-to-device DMA is generally a bug
that is not worth supporting in all its beauty. But if you know a
concrete scenario / guest where it matters,
On Mon, Sep 09, 2013 at 07:27:48PM +0200, Jan Kiszka wrote:
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 18:58, Peter Maydell wrote:
Why is a DMA request any different from any other communication
between two
On Mon, Sep 09, 2013 at 05:02:15PM +0100, Peter Maydell wrote:
On 9 September 2013 17:00, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 03:58:36PM +0100, Peter Maydell wrote:
On 9 September 2013 15:51, Marcel Apfelbaum marce...@redhat.com wrote:
On Mon, 2013-09-09 at
On 9 September 2013 17:54, Jan Kiszka jan.kis...@siemens.com wrote:
DMA requests from one device to another targeting anything else but
RAM-backed regions will have to be rejected by QEMU in the future. We
cannot map this sanely on a per-device locking model. The filtering will
take place
On 9 September 2013 18:27, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
Other communication between devices requiring to take the target
device's lock while holding the one of the
On 2013-09-09 19:41, Peter Maydell wrote:
On 9 September 2013 18:27, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
Other communication between devices requiring to take the target
device's
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 18:58, Peter Maydell wrote:
Why is a DMA request any different from any other communication
between two devices?
Other communication between devices requiring to take
On 2013-09-09 20:59, Peter Maydell wrote:
On 9 September 2013 19:49, Jan Kiszka jan.kis...@siemens.com wrote:
Well, even if you resolve the locking issues in all the interesting
devices (not impossible, just pretty costly in several regards), you
cannot reasonably allow device A talking to
On 9 September 2013 19:49, Jan Kiszka jan.kis...@siemens.com wrote:
Well, even if you resolve the locking issues in all the interesting
devices (not impossible, just pretty costly in several regards), you
cannot reasonably allow device A talking to device B triggering a
request on A issuing a
On 2013-09-09 20:03, Paolo Bonzini wrote:
Il 09/09/2013 19:27, Jan Kiszka ha scritto:
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 18:58, Peter Maydell wrote:
Why is a DMA request any different from any other
On Mon, Sep 09, 2013 at 07:59:06PM +0100, Peter Maydell wrote:
On 9 September 2013 19:49, Jan Kiszka jan.kis...@siemens.com wrote:
Well, even if you resolve the locking issues in all the interesting
devices (not impossible, just pretty costly in several regards), you
cannot reasonably allow
On Mon, Sep 09, 2013 at 08:11:25PM +0200, Paolo Bonzini wrote:
Il 09/09/2013 20:06, Jan Kiszka ha scritto:
archive, was in the context of lock-less MMIO dispatching), and the
consensus back then was that device-to-device DMA is generally a bug
that is not worth supporting in all its beauty.
On Mon, Sep 09, 2013 at 08:49:53PM +0200, Jan Kiszka wrote:
On 2013-09-09 20:03, Paolo Bonzini wrote:
Il 09/09/2013 19:27, Jan Kiszka ha scritto:
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 18:58, Peter
67 matches
Mail list logo
