Re: [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID
Date: Fri, 22 Jan 2016 16:51:26 +0100	[thread overview]
Message-ID: <56A24FFE.7020807@citrix.com> (raw)
In-Reply-To: <56A2594D02000078000CA347@prv-mh.provo.novell.com>

El 22/01/16 a les 16.31, Jan Beulich ha escrit:
>>>> On 22.01.16 at 15:59, <roger.pau@citrix.com> wrote:
>> El 22/01/16 a les 14.34, Andrew Cooper ha escrit:
>>> On 22/01/16 12:43, Roger Pau Monné wrote:
>>>> IOAPIC: tied to LAPIC (so either both enabled or none).
>>>
>>> An IOAPIC is by no means required - they are only for turning legacy
>>> interrupts into MSIs.  It would be perfectly fine for a PVH domain to
>>> have an LAPIC and an SRIOV virtual function, without an IOAPIC at all.
>>>
>>> The presence of LAPICs and IOAPICs reside in the MADT ACPI table.
>>
>> Right, so as said in the reply to Jan, we will require ACPI in order to
>> enable any of this pieces. I don't have a problem with that, just wasn't
>> sure if this requirement was desired.
> 
> The question is whether a non-Dom0 HVMlite guest needs any
> of these in the first place. Because if it doesn't (and that's the
> mode we provide right now), making them dependent on ACPI
> availability should be quite fine: If we need them for some
> purpose in the guest, we'd need to make ACPI tables available.

I only foresee non-Dom0 HVMlite guests with pci-passthrough to ever
require any of those, but that's still a long shot...

>> If that's the plan, then I think we would also need to fixup the tables
>> provided to Dom0 in order to match what's available, but that can be
>> discussed later.
> 
> I don't see what you're getting at here: The IO-APIC information
> should be usable as is for Dom0 (as is the case for PV).

Well, the information it's usable, but the IO-APIC is not accessible by
Dom0, you need to use PHYSDEV ops in order to manage it. One of my aims
would be to get rid of quite of the PHYSDEV/PIRQ ops for Dom0, and
instead provide an emulated local and IO APICs. That would also allow us
to make use of posted-interrupts I assume (although I certainly need to
look more deeply into this).

In this case, how are we going to signal Dom0 that the local and IO
APICs reported by ACPI are usable using the bare mental interfaces?

>>>> So, we have the following devices that are assumed to be there: RTC,
>>>> PIC, PIT. Everything else I think can be signalled by other means
>>>> already available.
>>>>
>>>> IMHO, I think we could say that the PIC is never going to be available
>>>> to HVMlite guests (in any case we would enable the lapic/ioapic), and
>>>> maybe enable the RTC and PIT by default?
>>>>
>>>> Then I think we could get away without any Xen-specific way of reporting
>>>> enabled devices.
>>>
>>> DMLite is a new container type.  I would far rather it was assumed that
>>> there was no legacy hardware at all.
>>
>> So I take that you are in favour of only considering enabling the local
>> APIC and IO APIC maybe for HVMlite, because of the performance benefits,
>> while the other devices are _never_ going to be available to HVMlite
>> guests/hosts at all? (Dom0 already gets the hw VGA)
>>
>> IMHO, I would like to be able to eventually enable them in order to
>> provide an environment that's as close as possible to a compatible PC,
>> in order to reduce the amount of changes required in order to port an OS
>> to run in this mode.
> 
> I didn't think that's among the goals for HVMlite. Just like PV and PVH,
> HVMlite requires OS awareness.

Right, just getting rid of the PHYSDEV/PIRQ operations would be a big
win IMHO.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel