public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH] testdev: adjust for ISA irq changes
Date: Sun, 29 May 2011 17:36:16 +0200	[thread overview]
Message-ID: <4DE267F0.5070908@web.de> (raw)
In-Reply-To: <4DE2659F.1010706@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On 2011-05-29 17:26, Avi Kivity wrote:
> On 05/29/2011 06:21 PM, Jan Kiszka wrote:
>> >  Suppose our motherboard wired
>> >  the PCI links to GSI16-19 (or GSI16-23, as we once wanted before we
>> had
>> >  MSI-X)?  We'd need an API to access non-ISA interrupt lines.
>> >
>> >  So what's the clean fix here?  gsi_get_irq()?
>>
>> Maybe. Depends on the requirements of the testdev. If you also want to
>> address PIC and IOAPIC separately or simulate injection from a specific
>> device, we need more logic.
> 
> It's impossible to address them separately, the input lines are tied
> together (esp. with kvm irq routing).

That's just how user land implements it ATM. Needs fixing for chipsets
like Q35 that allow the guest to configure the routing. Fortunately, the
KVM kernel interface supports this already.

>  I think using GSIs is the right
> thing here.

It really depends on what you want to test with testdev. It's an
artificial thing anyway, so you are free to inject wherever and whatever
you want. But I guess GSI is what was the intention so far.

> 
>> We also need a better interface to discover and track legacy IRQ routes
>> for device assignment. Markus is currently collecting requirements for
>> qdev enhancements, and I think generic IRQ manipulation and discovery
>> belongs there.
> 
> Possibly.  But note that attempting to shoehorn everything into
> bus/device model may not work.  Motherboard devices, especially, often
> bypass the bus/device relationship, just because everything is available
> to them on the motherboard, and because hardware designers didn't go to
> software engineering schools but instead do what's necessary to get
> things working.  We have to be prepared for exceptions.

Yes, the IRQ tree should probably be independent of the qdev tree. I was
thinking of qdev as the infrastructure that allows to build and maintain
that tree and to associate IRQ pins with qdev devices.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

  reply	other threads:[~2011-05-29 15:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-29 12:57 [PATCH] testdev: adjust for ISA irq changes Avi Kivity
2011-05-29 15:05 ` Jan Kiszka
2011-05-29 15:10   ` Avi Kivity
2011-05-29 15:21     ` Jan Kiszka
2011-05-29 15:26       ` Avi Kivity
2011-05-29 15:36         ` Jan Kiszka [this message]
2011-05-30 15:34           ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DE267F0.5070908@web.de \
    --to=jan.kiszka@web.de \
    --cc=armbru@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox