Re: [RFC PATCH 4/4] KVM: x86: Add support for local interrupt requests from userspace

From: Jan Kiszka <jan.kiszka@siemens.com>
To: Steve Rutherford <srutherford@google.com>
Cc: kvm@vger.kernel.org, Andrew Honig <ahonig@google.com>
Subject: Re: [RFC PATCH 4/4] KVM: x86: Add support for local interrupt requests from userspace
Date: Fri, 15 May 2015 15:27:23 +0200	[thread overview]
Message-ID: <5555F43B.4050303@siemens.com> (raw)
In-Reply-To: <20150513224157.GB24121@google.com>

On 2015-05-14 00:41, Steve Rutherford wrote:
> On Wed, May 13, 2015 at 08:12:59AM +0200, Jan Kiszka wrote:
>> On 2015-05-13 03:47, Steve Rutherford wrote:
>>> In order to enable userspace PIC support, the userspace PIC needs to
>>> be able to inject local interrupt requests.
>>>
>>> This adds the ioctl KVM_REQUEST_LOCAL_INTERRUPT and kvm exit
>>> KVM_EXIT_GET_EXTINT.
>>>
>>> The vm ioctl KVM_REQUEST_LOCAL_INTERRUPT makes a KVM_REQ_EVENT request
>>> on the BSP, which causes the BSP to exit to userspace to fetch the
>>> vector of the underlying external interrupt, which the BSP then
>>> injects into the guest. This matches the PIC spec, and is necessary to
>>> boot Windows.
>>
>> The API name seems too generic, given the fairly specific use case. As
>> it only allows to kick the BSP, not any VCPU, that should be clarified.
>> Maybe call it KVM_REQUEST_PIC_INJECTION or so. Or allow userspace to
>> specify the target VCPU, then it's a bit more generic again.
>>
>> Actually, when looking at the MultiProcessor spec, you will find
>> multiple models for injecting PIC interrupts into CPU APICs. Just in the
>> PIC Mode, the BSP is the only possible target. In the other modes, all
>> APICs can receive PIC interrupts, and either the IOAPIC or the local
>> APIC's LINT0 configuration decide about the effective target. We should
>> allow to model all modes, based on userspace decisions.
>>
> 
> Supporting the other modes seems reasonable, but I'm not certain I have an outlet for testing them for correctness. I'm not even certain which OSes use the other modes. Unless there is a common OS that uses the other modes, and a straightforward way for me to test the other modes, I'd rather just rename the API to be less generic.

The OS has to configure what the hardware provides, I bet Windows does
so as well. This is a hardware property, thus something userspace (QEMU
& Co.) may want to configure.

> 
>>>
>>> Boots and passes the KVM unit tests on intel x86 with the
>>> PIC/PIT/IOAPIC in userspace (under a non-QEMU VMM). Boots and passes
>>> the KVM unit tests under normal conditions as well.
>>
>> Do you plan to provide a reference implementation for an open source
>> userspace VMM as well, once the kernel side is settled?
>>
> 
> Not at the moment (given that I'm not all that familiar with QEMU). I'm definitely willing to help guide someone else through the process.

It would be fairly valuable to have this tested against a known, public
machine emulator so that we can validate all needs before setting the
new kernel ABI in stone.

I do have an interest in this API as well, sitting on IRQ remapping
hacks and their lacking x2APIC support for too long, but I unfortunately
can't promise bandwidth either. :/

Jan

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