On Sun, Jun 10, 2012 at 02:47:40PM +0200, Jan Kiszka wrote:
> On 2012-06-10 14:42, Michael S. Tsirkin wrote:
> > On Sun, Jun 10, 2012 at 02:33:03PM +0200, Jan Kiszka wrote:
> >> On 2012-06-10 14:16, Michael S. Tsirkin wrote:
> >>> On Sun, Jun 10, 2012 at 02:09:20PM +0200, Jan Kiszka wrote:
> O
On 2012-06-10 14:42, Michael S. Tsirkin wrote:
> On Sun, Jun 10, 2012 at 02:33:03PM +0200, Jan Kiszka wrote:
>> On 2012-06-10 14:16, Michael S. Tsirkin wrote:
>>> On Sun, Jun 10, 2012 at 02:09:20PM +0200, Jan Kiszka wrote:
On 2012-06-10 13:39, Michael S. Tsirkin wrote:
> It's OK to use rec
On Sun, Jun 10, 2012 at 02:33:03PM +0200, Jan Kiszka wrote:
> On 2012-06-10 14:16, Michael S. Tsirkin wrote:
> > On Sun, Jun 10, 2012 at 02:09:20PM +0200, Jan Kiszka wrote:
> >> On 2012-06-10 13:39, Michael S. Tsirkin wrote:
> >>> It's OK to use recursion but when done through a callback
> >>> like
On 2012-06-10 14:16, Michael S. Tsirkin wrote:
> On Sun, Jun 10, 2012 at 02:09:20PM +0200, Jan Kiszka wrote:
>> On 2012-06-10 13:39, Michael S. Tsirkin wrote:
>>> It's OK to use recursion but when done through a callback
>>> like this it's unreadable.
>>
>> Isn't the alternative poking into foreign
On Sun, Jun 10, 2012 at 01:18:15PM +0200, Jan Kiszka wrote:
> >> @@ -318,6 +322,9 @@ PCIBus *pci_register_bus(DeviceState *parent,
> >> const char *name,
> >> MemoryRegion *address_space_io,
> >> uint8_t devfn_min, int nirq);
> >>
On Sun, Jun 10, 2012 at 02:09:20PM +0200, Jan Kiszka wrote:
> On 2012-06-10 13:39, Michael S. Tsirkin wrote:
> > It's OK to use recursion but when done through a callback
> > like this it's unreadable.
>
> Isn't the alternative poking into foreign bridge device states for their
> secondary buses?
On 2012-06-10 13:39, Michael S. Tsirkin wrote:
> It's OK to use recursion but when done through a callback
> like this it's unreadable.
Isn't the alternative poking into foreign bridge device states for their
secondary buses?
> Also, you need to setup you cache after intx cache has been
> initial
On Sun, Jun 10, 2012 at 01:18:15PM +0200, Jan Kiszka wrote:
> On 2012-06-10 13:11, Michael S. Tsirkin wrote:
> > From commit log it would seem that even irq changes should
> > invoke this. So why isn't this notifier at the host bridge then?
>
> Can't follow, where does the commit
On 2012-06-10 13:11, Michael S. Tsirkin wrote:
> From commit log it would seem that even irq changes should
> invoke this. So why isn't this notifier at the host bridge then?
Can't follow, where does the commit log imply this? It is only about
routing changes, not IRQ level c
On Sun, Jun 10, 2012 at 12:44:05PM +0200, Jan Kiszka wrote:
> On 2012-06-10 12:33, Michael S. Tsirkin wrote:
> > On Sun, Jun 10, 2012 at 12:05:10PM +0200, Jan Kiszka wrote:
> >> On 2012-06-10 11:48, Michael S. Tsirkin wrote:
> >>> On Mon, Jun 04, 2012 at 10:52:14AM +0200, Jan Kiszka wrote:
> T
On 2012-06-10 12:33, Michael S. Tsirkin wrote:
> On Sun, Jun 10, 2012 at 12:05:10PM +0200, Jan Kiszka wrote:
>> On 2012-06-10 11:48, Michael S. Tsirkin wrote:
>>> On Mon, Jun 04, 2012 at 10:52:14AM +0200, Jan Kiszka wrote:
This per-device notifier shall be triggered by any interrupt router
>>>
On Sun, Jun 10, 2012 at 12:05:10PM +0200, Jan Kiszka wrote:
> On 2012-06-10 11:48, Michael S. Tsirkin wrote:
> > On Mon, Jun 04, 2012 at 10:52:14AM +0200, Jan Kiszka wrote:
> >> This per-device notifier shall be triggered by any interrupt router
> >> along the path of a device's legacy interrupt si
On 2012-06-10 11:48, Michael S. Tsirkin wrote:
> On Mon, Jun 04, 2012 at 10:52:14AM +0200, Jan Kiszka wrote:
>> This per-device notifier shall be triggered by any interrupt router
>> along the path of a device's legacy interrupt signal on routing changes.
>> For simplicity reasons and as this is a
On Mon, Jun 04, 2012 at 10:52:14AM +0200, Jan Kiszka wrote:
> This per-device notifier shall be triggered by any interrupt router
> along the path of a device's legacy interrupt signal on routing changes.
> For simplicity reasons and as this is a slow path anyway, no further
> details on the routin
On 2012-06-07 15:14, Michael S. Tsirkin wrote:
> On Mon, Jun 04, 2012 at 10:52:14AM +0200, Jan Kiszka wrote:
>> This per-device notifier shall be triggered by any interrupt router
>> along the path of a device's legacy interrupt signal on routing changes.
>> For simplicity reasons and as this is a
On Mon, Jun 04, 2012 at 10:52:14AM +0200, Jan Kiszka wrote:
> This per-device notifier shall be triggered by any interrupt router
> along the path of a device's legacy interrupt signal on routing changes.
> For simplicity reasons and as this is a slow path anyway, no further
> details on the routin
This per-device notifier shall be triggered by any interrupt router
along the path of a device's legacy interrupt signal on routing changes.
For simplicity reasons and as this is a slow path anyway, no further
details on the routing changes are provided. Instead, the callback is
expected to use pci
17 matches
Mail list logo
