Linux Virtualization - Jul 2015 - [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On 28/07/2015 18:42, Jan Kiszka wrote:
> > On the other hand interrupt remapping is absolutely necessary for
> > production use, hence my point that x86 does not promise API
stability.
> 
> Well, we currently implement the features that the Q35 used to expose.
> Adding interrupt remapping will require a new chipset and/or a hack
> switch to ignore compatibility.
Isn't the VT-d register space separate from other Q35 features and
backwards-compatible?  You could even add it to PIIX in theory just by
adding a DMAR.

It's not like for example SMRAM, where the registers are in the
northbridge configuration space and move around in every chipset generation.
> > ("Any kind of stability" actually didn't include
crashes; those are not
> > expected :))
> > 
> > The Google patches for userspace PIC and IOAPIC are proceeding well,
so
> > hopefully we can have interrupt remapping soon.
> 
> If the day had 48 hours... I'd love to look into this, first adding
QEMU
> support for the new irqchip architecture.
I hope I can squeeze in some time for that...  Google also had an intern
that was looking at it.

Paolo

On 2015-07-28 19:15, Paolo Bonzini wrote:
> 
> 
> On 28/07/2015 18:42, Jan Kiszka wrote:
>>> On the other hand interrupt remapping is absolutely necessary for
>>> production use, hence my point that x86 does not promise API
stability.
>>
>> Well, we currently implement the features that the Q35 used to expose.
>> Adding interrupt remapping will require a new chipset and/or a hack
>> switch to ignore compatibility.
> 
> Isn't the VT-d register space separate from other Q35 features and
> backwards-compatible?  You could even add it to PIIX in theory just by
> adding a DMAR.
Yes, it's practically working, but it's not accurate /wrt how that
hardware looked like in reality.
> 
> It's not like for example SMRAM, where the registers are in the
> northbridge configuration space and move around in every chipset
generation.
> 
>>> ("Any kind of stability" actually didn't include
crashes; those are not
>>> expected :))
>>>
>>> The Google patches for userspace PIC and IOAPIC are proceeding
well, so
>>> hopefully we can have interrupt remapping soon.
>>
>> If the day had 48 hours... I'd love to look into this, first adding
QEMU
>> support for the new irqchip architecture.
> 
> I hope I can squeeze in some time for that...  Google also had an intern
> that was looking at it.
Great!

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

On 28/07/2015 19:19, Jan Kiszka wrote:
> On 2015-07-28 19:15, Paolo Bonzini wrote:
>>
>>
>> On 28/07/2015 18:42, Jan Kiszka wrote:
>>>> On the other hand interrupt remapping is absolutely necessary
for
>>>> production use, hence my point that x86 does not promise API
stability.
>>>
>>> Well, we currently implement the features that the Q35 used to
expose.
>>> Adding interrupt remapping will require a new chipset and/or a hack
>>> switch to ignore compatibility.
>>
>> Isn't the VT-d register space separate from other Q35 features and
>> backwards-compatible?  You could even add it to PIIX in theory just by
>> adding a DMAR.
> 
> Yes, it's practically working, but it's not accurate /wrt how that
> hardware looked like in reality.
We've done that for a long time.  Real PIIX3 didn't have ACPI too, for
example (and it had a USB UHCI that is optional in QEMU).

Of course I'm not advocating adding the IOMMU to PIIX (assuming that
would work even just practically)... but I don't think adding interrupt
remapping to Q35 is a big deal.  It would be optional, just in case you
want to debug something without interrupt remapping, but it can be added.
>>>> The Google patches for userspace PIC and IOAPIC are proceeding
well, so
>>>> hopefully we can have interrupt remapping soon.
>>>
>>> If the day had 48 hours... I'd love to look into this, first
adding QEMU
>>> support for the new irqchip architecture.
>>
>> I hope I can squeeze in some time for that...  Google also had an
intern
>> that was looking at it.
> 
> Great!
In theory it's easy with the latest series.  All you need is support for
converting IOAPIC routes to KVM routes (and of course the glue code to
enable the capability and create the userspace devices); everything else
should work just by reusing the -machine kernel_irqchip=on code.  In
theory...

Paolo