qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hw/arm/virt: smbios: inform guest of kvm


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt: smbios: inform guest of kvm
Date: Thu, 8 Oct 2015 19:42:16 +0100

On 28 September 2015 at 16:31, Andrew Jones <address@hidden> wrote:
> On Thu, Sep 24, 2015 at 12:13:08PM +0200, Andrew Jones wrote:
>> On Wed, Sep 23, 2015 at 08:43:39AM -0700, Peter Maydell wrote:
>> > On 23 September 2015 at 07:18, Andrew Jones <address@hidden> wrote:
>> > > ARM/AArch64 KVM guests don't have any way to identify
>> > > themselves as KVM guests (x86 guests use a CPUID leaf). Now, we
>> > > could discuss all sorts of reasons why guests shouldn't need to
>> > > know that, but then there's always some case where it'd be
>> > > nice... Anyway, now that we have SMBIOS tables in ARM guests,
>> > > it's easy for the guest to know that it's a QEMU instance. This
>> > > patch takes that one step further, also identifying KVM, when
>> > > appropriate. Again, we could debate why generally nothing
>> > > should care whether it's of type QEMU or QEMU/KVM, but again,
>> > > sometimes it's nice to know...
>> >
>> > This doesn't seem great to me, because it's ACPI/SMBIOS
>> > specific. A mechanism that worked whether the guest was
>> > booted via APCI or DT would seem preferable to me...
>>
>> SMBIOS is populated on both ACPI and devicetree boots. We already
>> have detection in virt-what and systemd-detect-virt for DT boots,
>> although it only detects QEMU (it can't determine if KVM is used).
>> That detection is DT-specific, and much more of a heuristic, it
>> checks for the presence of the fw-cfg node in the DT. Actually, I'd
>> like to patch those virt detection tools to try SMBIOS first (which,
>> with this patch, could also give KVM info), and then fall back to
>> trying the current DT-only, QEMU-only detection, before giving up.
>>
>
> Hi Peter,
>
> Anymore thoughts on this?

Well, OK I guess, but this all seems worryingly ad-hoc...

Applied to  target-arm.next.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]