Message-ID: <CALCETrW8jBXwCqXNMra667qk-CALOTvAXnQqYQuPBC_sWoJxHg@mail.gmail.com>
Date:	Sat, 2 Apr 2016 11:05:21 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Konstantin Ozerkov <kozerkov@...allels.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	George Dunlap <George.Dunlap@...citrix.com>,
	xen-devel <xen-devel@...ts.xenproject.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Jim Gettys <jg@...edesktop.org>,
	ALSA development <alsa-devel@...a-project.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	Dario Faggioli <dario.faggioli@...rix.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Joerg Roedel <joro@...tes.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mel Gorman <mgorman@...e.de>
Subject: Re: Getting rid of inside_vm in intel8x0

On Apr 2, 2016 12:07 PM, "Takashi Iwai" <tiwai@...e.de> wrote:
>
> On Sat, 02 Apr 2016 14:57:44 +0200,
> Andy Lutomirski wrote:
> >
> > On Fri, Apr 1, 2016 at 10:33 PM, Takashi Iwai <tiwai@...e.de> wrote:
> > > On Sat, 02 Apr 2016 00:28:31 +0200,
> > > Luis R. Rodriguez wrote:
> > >> If the former, could a we somehow detect an emulated device other than through
> > >> this type of check ? Or could we *add* a capability of some sort to detect it
> > >> on the driver ? This would not address the removal, but it could mean finding a
> > >> way to address emulation issues.
> > >>
> > >> If its an IO issue -- exactly what is the causing the delays in IO ?
> > >
> > > Luis, there is no problem about emulation itself.  It's rather an
> > > optimization to lighten the host side load, as I/O access on a VM is
> > > much heavier.
> > >
> > >> > > > This is satisfied mostly only on VM, and can't
> > >> > > > be measured easily unlike the IO read speed.
> > >> > >
> > >> > > Interesting, note the original patch claimed it was for KVM and
> > >> > > Parallels hypervisor only, but since the code uses:
> > >> > >
> > >> > > +#if defined(__i386__) || defined(__x86_64__)
> > >> > > +               inside_vm = inside_vm || boot_cpu_has(X86_FEATURE_HYPERVISOR);
> > >> > > +#endif
> > >> > >
> > >> > > This makes it apply also to Xen as well, this makes this hack more
> > >> > > broad, but does is it only applicable when an emulated device is
> > >> > > used ? What about if a hypervisor is used and PCI passthrough is
> > >> > > used ?
> > >> >
> > >> > A good question.  Xen was added there at the time from positive
> > >> > results by quick tests, but it might show an issue if it's running on
> > >> > a very old chip with PCI passthrough.  But I'm not sure whether PCI
> > >> > passthrough would work on such old chipsets at all.
> > >>
> > >> If it did have an issue then that would have to be special cased, that
> > >> is the module parameter would not need to be enabled for such type of
> > >> systems, and heuristics would be needed. As you note, fortunately this
> > >> may not be common though...
> > >
> > > Actually this *is* module parametered.  If set to a boolean value, it
> > > can be applied / skipped forcibly.  So, if there has been a problem on
> > > Xen, this should have been reported.  That's why I wrote it's no
> > > common case.  This comes from the real experience.
> > >
> > >> but if this type of work around may be
> > >> taken as a precedent to enable other types of hacks in other drivers
> > >> I'm very fearful of more hacks later needing these considerations as
> > >> well.
> > >>
> > >> > > > > There are a pile of nonsensical "are we in a VM" checks of various
> > >> > > > > sorts scattered throughout the kernel, they're all a mess to maintain
> > >> > > > > (there are lots of kinds of VMs in the world, and Linux may not even
> > >> > > > > know it's a guest), and, in most cases, it appears that the correct
> > >> > > > > solution is to delete the checks.  I just removed a nasty one in the
> > >> > > > > x86_32 entry asm, and this one is written in C so it should be a piece
> > >> > > > > of cake :)
> > >> > > >
> > >> > > > This cake looks sweet, but a worm is hidden behind the cream.
> > >> > > > The loop in the code itself is already a kludge for the buggy hardware
> > >> > > > where the inconsistent read happens not so often (only at the boundary
> > >> > > > and in a racy way).  It would be nice if we can have a more reliably
> > >> > > > way to know the hardware buggyness, but it's difficult,
> > >> > > > unsurprisingly.
> > >> > >
> > >> > > The concern here is setting precedents for VM cases sprinkled in the kernel.
> > >> > > The assumption here is such special cases are really paper'ing over another
> > >> > > type of issue, so its best to ultimately try to root cause the issue in
> > >> > > a more generalized fashion.
> > >> >
> > >> > Well, it's rather bare metal that shows the buggy behavior, thus we
> > >> > need to paper over it.   In that sense, it's other way round; we don't
> > >> > tune for VM.  The VM check we're discussing is rather for skipping the
> > >> > strange workaround.
> > >>
> > >> What is it exactly about a VM that enables this work around to be skipped?
> > >> I don't quite get it yet.
> > >
> > > VM -- at least the full one with the sound hardware emulation --
> > > doesn't have the hardware bug.  So, the check isn't needed.
> >
> > Here's the issue, though: asking "am I in a VM" is not a good way to
> > learn properties of hardware.  Just off the top of my head, here are
> > some types of VM and what they might imply about hardware:
> >
> > Intel Kernel Guard: your sound card is passed through from real hardware.
> >
> > Xen: could go either way.  In dom0, it's likely passed through.  In
> > domU, it could be passed through or emulated, and I believe this is
> > the case for all of the Xen variants.
> >
> > KVM: Probably emulated, but could be passed through.
> >
> > I think the main reason that Luis and I are both uncomfortable with
> > "am I in a VM" checks is that they're rarely the right thing to be
> > detecting, the APIs are poorly designed, and most of the use cases in
> > the kernel are using them as a proxy for something else and would be
> > clearer and more future proof if they tested what they actually need
> > to test more directly.
>
> Please, guys, take a look at the code more closely.  This is applied
> only to the known emulated PCI devices, and the driver shows the
> kernel message:
>
> static int snd_intel8x0_inside_vm(struct pci_dev *pci)
> ....
>         /* check for known (emulated) devices */
>         if (pci->subsystem_vendor == PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
>             pci->subsystem_device == PCI_SUBDEVICE_ID_QEMU) {
>                 /* KVM emulated sound, PCI SSID: 1af4:1100 */
>                 msg = "enable KVM";
>         } else if (pci->subsystem_vendor == 0x1ab8) {
>                 /* Parallels VM emulated sound, PCI SSID: 1ab8:xxxx */
>                 msg = "enable Parallels VM";
>         } else {
>                 msg = "disable (unknown or VT-d) VM";
>                 result = 0;
>         }

Now I'm more confused.  Why are you checking the PCI IDs *and* whether
a hypervisor is detected?  Why not check only the IDs?

In any event, at the very least the comment is misleading:

        /* detect KVM and Parallels virtual environments */
        result = kvm_para_available();
#ifdef X86_FEATURE_HYPERVISOR
        result = result || boot_cpu_has(X86_FEATURE_HYPERVISOR);
#endif

You're detecting KVM (sometimes) and the x86 "hypervisor" bit.  The
latter has no particularly well-defined meaning.  You're also missing
Xen PV, I believe, and I think that Xen PV + QEMU is a real thing, and
you'll fail to detect it, even though it can present a QEMU-emulated
card.

In other words, how is this code any different from a simple whitelist
of two specific cards that work a little differently from others?

--Andy

Powered by blists - more mailing lists