On 2012-06-01 18:05, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 2012 at 05:54:15PM +0200, Jan Kiszka wrote:
>> On 2012-06-01 17:28, Michael S. Tsirkin wrote:
> So I won't object to adding a new API but if we do
> it properly this won't help compatibility :(
It will as this API do
On Fri, Jun 01, 2012 at 05:34:14PM +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote:
> > On 2012-06-01 15:27, Michael S. Tsirkin wrote:
> > > On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
> > >> On 2012-05-30 22:31, Michael S. Tsirkin wrote
On Fri, Jun 01, 2012 at 05:54:15PM +0200, Jan Kiszka wrote:
> On 2012-06-01 17:28, Michael S. Tsirkin wrote:
> >>> So I won't object to adding a new API but if we do
> >>> it properly this won't help compatibility :(
> >>
> >> It will as this API does not touch the parts that affect the vmstate
> >
On 2012-06-01 17:30, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote:
>> On 2012-06-01 16:34, Michael S. Tsirkin wrote:
>>> On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote:
On 2012-06-01 15:27, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 20
On 2012-06-01 17:28, Michael S. Tsirkin wrote:
>>> So I won't object to adding a new API but if we do
>>> it properly this won't help compatibility :(
>>
>> It will as this API does not touch the parts that affect the vmstate
>> (ie. semantics of irq_count won't change).
>
> Yes but irq_count in v
On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote:
> On 2012-06-01 16:34, Michael S. Tsirkin wrote:
> > On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote:
> >> On 2012-06-01 15:27, Michael S. Tsirkin wrote:
> >>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
> O
On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote:
> On 2012-06-01 16:34, Michael S. Tsirkin wrote:
> > On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote:
> >> On 2012-06-01 15:27, Michael S. Tsirkin wrote:
> >>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
> O
On 2012-06-01 16:34, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote:
>> On 2012-06-01 15:27, Michael S. Tsirkin wrote:
>>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
On 2012-05-30 22:31, Michael S. Tsirkin wrote:
>>> So we'll just ha
On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote:
> On 2012-06-01 15:27, Michael S. Tsirkin wrote:
> > On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
> >> On 2012-05-30 22:31, Michael S. Tsirkin wrote:
> > So we'll just have PIIX_NUM_PIC_IRQS entries there and use
> >
On 2012-06-01 15:27, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
>> On 2012-05-30 22:31, Michael S. Tsirkin wrote:
> So we'll just have PIIX_NUM_PIC_IRQS entries there and use
> irq_count instead of the pic_levels bitmap.
Just that this
On 2012-06-01 15:28, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
>> On 2012-05-30 22:31, Michael S. Tsirkin wrote:
> So we'll just have PIIX_NUM_PIC_IRQS entries there and use
> irq_count instead of the pic_levels bitmap.
Just that this
On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
> On 2012-05-30 22:31, Michael S. Tsirkin wrote:
> >>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use
> >>> irq_count instead of the pic_levels bitmap.
> >>
> >> Just that this affects generic PCI code, not only PIIX-specific t
On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
> On 2012-05-30 22:31, Michael S. Tsirkin wrote:
> >>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use
> >>> irq_count instead of the pic_levels bitmap.
> >>
> >> Just that this affects generic PCI code, not only PIIX-specific t
On 2012-05-30 22:31, Michael S. Tsirkin wrote:
>>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use
>>> irq_count instead of the pic_levels bitmap.
>>
>> Just that this affects generic PCI code, not only PIIX-specific things.
>
> Yes but it's not a problem - pci_bus_irqs sets the map fun
On Wed, May 30, 2012 at 10:23:16PM +0200, Jan Kiszka wrote:
> On 2012-05-30 21:30, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 09:06:25PM +0200, Jan Kiszka wrote:
> >> On 2012-05-30 20:51, Michael S. Tsirkin wrote:
> >>> On Wed, May 30, 2012 at 09:29:13PM +0300, Michael S. Tsirkin wrote:
On 2012-05-30 21:30, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 09:06:25PM +0200, Jan Kiszka wrote:
>> On 2012-05-30 20:51, Michael S. Tsirkin wrote:
>>> On Wed, May 30, 2012 at 09:29:13PM +0300, Michael S. Tsirkin wrote:
On Wed, May 30, 2012 at 09:23:56PM +0300, Michael S. Tsirkin wr
On Wed, May 30, 2012 at 09:06:25PM +0200, Jan Kiszka wrote:
> On 2012-05-30 20:51, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 09:29:13PM +0300, Michael S. Tsirkin wrote:
> >> On Wed, May 30, 2012 at 09:23:56PM +0300, Michael S. Tsirkin wrote:
> >>> On Wed, May 30, 2012 at 07:57:04PM +020
On 2012-05-30 20:51, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 09:29:13PM +0300, Michael S. Tsirkin wrote:
>> On Wed, May 30, 2012 at 09:23:56PM +0300, Michael S. Tsirkin wrote:
>>> On Wed, May 30, 2012 at 07:57:04PM +0200, Jan Kiszka wrote:
On 2012-05-30 19:51, Jan Kiszka wrote:
>>>
On Wed, May 30, 2012 at 09:29:13PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 09:23:56PM +0300, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 07:57:04PM +0200, Jan Kiszka wrote:
> > > On 2012-05-30 19:51, Jan Kiszka wrote:
> > > >> Well, I'll stop ranting here. The patch th
On Wed, May 30, 2012 at 09:23:56PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 07:57:04PM +0200, Jan Kiszka wrote:
> > On 2012-05-30 19:51, Jan Kiszka wrote:
> > >> Well, I'll stop ranting here. The patch that I sent is not intrusive
> > >> and simply gives you a simple way to imple
On Wed, May 30, 2012 at 07:57:04PM +0200, Jan Kiszka wrote:
> On 2012-05-30 19:51, Jan Kiszka wrote:
> >> Well, I'll stop ranting here. The patch that I sent is not intrusive
> >> and simply gives you a simple way to implement pci_device_get_host_irq,
> >> also optimizing emulated devices somewhat
On 2012-05-30 19:51, Jan Kiszka wrote:
>> Well, I'll stop ranting here. The patch that I sent is not intrusive
>> and simply gives you a simple way to implement pci_device_get_host_irq,
>> also optimizing emulated devices somewhat. So if you think you need
>> pci_device_get_host_irq I think this
On 2012-05-30 19:41, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 07:29:52PM +0200, Jan Kiszka wrote:
>> On 2012-05-30 19:20, Michael S. Tsirkin wrote:
>>> On Wed, May 30, 2012 at 06:46:03PM +0200, Jan Kiszka wrote:
On 2012-05-30 18:17, Michael S. Tsirkin wrote:
> On Wed, May 30, 20
On Wed, May 30, 2012 at 07:29:52PM +0200, Jan Kiszka wrote:
> On 2012-05-30 19:20, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 06:46:03PM +0200, Jan Kiszka wrote:
> >> On 2012-05-30 18:17, Michael S. Tsirkin wrote:
> >>> On Wed, May 30, 2012 at 05:47:45PM +0200, Jan Kiszka wrote:
> O
On 2012-05-30 19:20, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 06:46:03PM +0200, Jan Kiszka wrote:
>> On 2012-05-30 18:17, Michael S. Tsirkin wrote:
>>> On Wed, May 30, 2012 at 05:47:45PM +0200, Jan Kiszka wrote:
On 2012-05-30 16:59, Michael S. Tsirkin wrote:
> On Wed, May 30, 20
On Wed, May 30, 2012 at 06:46:03PM +0200, Jan Kiszka wrote:
> On 2012-05-30 18:17, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 05:47:45PM +0200, Jan Kiszka wrote:
> >> On 2012-05-30 16:59, Michael S. Tsirkin wrote:
> >>> On Wed, May 30, 2012 at 04:46:14PM +0200, Jan Kiszka wrote:
> O
On 2012-05-30 18:17, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 05:47:45PM +0200, Jan Kiszka wrote:
>> On 2012-05-30 16:59, Michael S. Tsirkin wrote:
>>> On Wed, May 30, 2012 at 04:46:14PM +0200, Jan Kiszka wrote:
On 2012-05-30 16:42, Michael S. Tsirkin wrote:
> On Wed, May 30, 20
On Wed, May 30, 2012 at 05:47:45PM +0200, Jan Kiszka wrote:
> On 2012-05-30 16:59, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 04:46:14PM +0200, Jan Kiszka wrote:
> >> On 2012-05-30 16:42, Michael S. Tsirkin wrote:
> >>> On Wed, May 30, 2012 at 04:38:25PM +0200, Jan Kiszka wrote:
> O
On 2012-05-30 16:59, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 04:46:14PM +0200, Jan Kiszka wrote:
>> On 2012-05-30 16:42, Michael S. Tsirkin wrote:
>>> On Wed, May 30, 2012 at 04:38:25PM +0200, Jan Kiszka wrote:
On 2012-05-30 15:34, Michael S. Tsirkin wrote:
> Below's as far as
On Wed, May 30, 2012 at 04:46:14PM +0200, Jan Kiszka wrote:
> On 2012-05-30 16:42, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 04:38:25PM +0200, Jan Kiszka wrote:
> >> On 2012-05-30 15:34, Michael S. Tsirkin wrote:
> >>> Below's as far as I got - hopefully this
> >>> explains what I had i
On 2012-05-30 16:42, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 04:38:25PM +0200, Jan Kiszka wrote:
>> On 2012-05-30 15:34, Michael S. Tsirkin wrote:
>>> Below's as far as I got - hopefully this
>>> explains what I had in mind: for deep hierarchies
>>> this will save a bus scan so I think
On Wed, May 30, 2012 at 04:38:25PM +0200, Jan Kiszka wrote:
> On 2012-05-30 15:34, Michael S. Tsirkin wrote:
> > Below's as far as I got - hopefully this
> > explains what I had in mind: for deep hierarchies
> > this will save a bus scan so I think this makes sense
> > even in the absense of kvm ir
On 2012-05-30 15:34, Michael S. Tsirkin wrote:
> Below's as far as I got - hopefully this
> explains what I had in mind: for deep hierarchies
> this will save a bus scan so I think this makes sense
> even in the absense of kvm irqchip.
>
> Warning: completely untested and known to be incomplete.
>
On Wed, May 30, 2012 at 02:11:58PM +0200, Jan Kiszka wrote:
> On 2012-05-21 23:03, Michael S. Tsirkin wrote:
> > On Mon, May 21, 2012 at 05:35:34PM -0300, Jan Kiszka wrote:
> >> On 2012-05-21 16:05, Michael S. Tsirkin wrote:
> >>> On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
> @
On 2012-05-21 23:03, Michael S. Tsirkin wrote:
> On Mon, May 21, 2012 at 05:35:34PM -0300, Jan Kiszka wrote:
>> On 2012-05-21 16:05, Michael S. Tsirkin wrote:
>>> On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
@@ -386,6 +387,14 @@ static void piix3_set_irq(void *opaque, int pirq,
On Mon, May 21, 2012 at 03:58:57PM -0300, Jan Kiszka wrote:
> On 2012-05-21 14:34, Michael S. Tsirkin wrote:
> > On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
> >> Add a PCI IRQ path discovery function that walks from a given device to
> >> the host bridge, returning the IRQ number th
On Mon, May 21, 2012 at 05:35:34PM -0300, Jan Kiszka wrote:
> On 2012-05-21 16:05, Michael S. Tsirkin wrote:
> > On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
> >> @@ -386,6 +387,14 @@ static void piix3_set_irq(void *opaque, int pirq, int
> >> level)
> >> piix3_set_irq_level(pii
On 2012-05-21 16:05, Michael S. Tsirkin wrote:
> On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
>> @@ -386,6 +387,14 @@ static void piix3_set_irq(void *opaque, int pirq, int
>> level)
>> piix3_set_irq_level(piix3, pirq, level);
>> }
>>
>> +static int piix3_map_host_irq(void *o
On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
> @@ -386,6 +387,14 @@ static void piix3_set_irq(void *opaque, int pirq, int
> level)
> piix3_set_irq_level(piix3, pirq, level);
> }
>
> +static int piix3_map_host_irq(void *opaque, int pci_intx)
> +{
> +PIIX3State *piix3 = op
On 2012-05-21 14:34, Michael S. Tsirkin wrote:
> On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
>> Add a PCI IRQ path discovery function that walks from a given device to
>> the host bridge, returning the IRQ number that is reported to the
>> attached interrupt controller. For this pur
On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
> Add a PCI IRQ path discovery function that walks from a given device to
> the host bridge, returning the IRQ number that is reported to the
> attached interrupt controller. For this purpose, another PCI bridge
> callback function is intr
On 2012-05-21 11:36, Avi Kivity wrote:
> On 05/21/2012 04:13 PM, Jan Kiszka wrote:
>> Add a PCI IRQ path discovery function that walks from a given device to
>> the host bridge, returning the IRQ number that is reported to the
>> attached interrupt controller. For this purpose, another PCI bridge
>
On 05/21/2012 04:13 PM, Jan Kiszka wrote:
> Add a PCI IRQ path discovery function that walks from a given device to
> the host bridge, returning the IRQ number that is reported to the
> attached interrupt controller. For this purpose, another PCI bridge
> callback function is introduced: map_host_i
On Mon, 2012-05-21 at 10:13 -0300, Jan Kiszka wrote:
> Add a PCI IRQ path discovery function that walks from a given device to
> the host bridge, returning the IRQ number that is reported to the
> attached interrupt controller. For this purpose, another PCI bridge
> callback function is introduced:
Add a PCI IRQ path discovery function that walks from a given device to
the host bridge, returning the IRQ number that is reported to the
attached interrupt controller. For this purpose, another PCI bridge
callback function is introduced: map_host_irq. It is so far only
implemented by the PIIX3, ot
45 matches
Mail list logo
