Re: RFC/patch portability: split kvm_vm_ioctl v3

[Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>]

Arnd Bergmann wrote:
> On Monday 05 November 2007, Carsten Otte wrote:
>> Dong, Eddie wrote:
>>>> BTW, why we use vector here? shouldn't it be irq_line or irq_no?
>>> Maybe you mean the Channel Subsystem (1st piece of knowledge and 
>>> surprise known from s390 doc)  are emulated in Qemu, correct?
>> The vector field was introduced by Avi's comment. I just copied that 
>> over.
>> On s390, we only have irq numbers, no vectors.
> 
> Actually, you have neither irq numbers nor vectors on s390 right now.
> I/O subchannels are do not fit into the IRQ handling in Linux at
> all, and external interrupts are sufficiently different that you
> should not treat them as IRQ lines in Linux.
We're not emulating the I/O subsystem, and thus no I/O subchannels.

> However, I would suggest that you use either one external interrupt or
> the "thin" interrupt as an event source for an interrupt controller for
> all the virtio devices, and use the generic IRQ subsystem for that,
> including interrupt lines and vectors.
> 
> In case of the thin interrupt, your virtual interrupt controller would
> more or less just consist of one lowcore address from which you can
> read the pending interrupt vector after an interrupt has been caused,
> as well as a single hcall that does a 'acknowledge interrupt, get
> next pending irq vector into lowcore and tell me whether there was
> one' operation.
> 
> You'll also need an operation to associate a virtio device with an
> interrupt vector, but that belongs into virtio.

The irq subsystem does not fit the external interrupt model, and you'd 
definitely want to argue with Martin before suggesting to introduce 
the IRQ subsystem on s390. "Only over my dead body" was the last 
statement I do remember.
Plus I don't see a benefit from pretending to have an interrupt 
controller: virtio abstracts from this, and can well be implemented 
over extint and hypercall like Christian has done it. What's the 
problem you're trying to solve?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/