[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC en
From: |
Michael S. Tsirkin |
Subject: |
Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement |
Date: |
Wed, 16 Mar 2022 06:47:48 -0400 |
On Wed, Mar 16, 2022 at 10:37:49AM +0000, David Woodhouse wrote:
> On Wed, 2022-03-16 at 05:56 -0400, Michael S. Tsirkin wrote:
> > On Wed, Mar 16, 2022 at 09:37:07AM +0000, David Woodhouse wrote:
> > > Yep, that's the guest operating system's choice. Not a qemu problem.
> > >
> > > Even if you have the split IRQ chip, if you boot a guest without kvm-
> > > msi-ext-dest-id support, it'll refuse to use higher CPUs.
> > >
> > > Or if you boot a guest without X2APIC support, it'll refuse to use
> > > higher CPUs.
> > >
> > > That doesn't mean a user should be *forbidden* from launching qemu in
> > > that configuration.
> >
> > Well the issue with all these configs which kind of work but not
> > the way they were specified is that down the road someone
> > creates a VM with this config and then expects us to maintain it
> > indefinitely.
> >
> > So yes, if we are not sure we can support something properly it is
> > better to validate and exit than create a VM guests don't know how
> > to treat.
>
> Not entirely sure how to reconcile that with what Daniel said in
> Yi9BTkZIM3iZsvdK@redhat.com/">https://lore.kernel.org/qemu-devel/Yi9BTkZIM3iZsvdK@redhat.com/ which
> was:
>
> > We've generally said QEMU should not reject / block startup of valid
> > hardware configurations, based on existance of bugs in certain guest
> > OS, if the config would be valid for other guest.
For sure, but is this a valid hardware configuration? That's
really the question.
> That said, I cannot point at a *specific* example of a guest which can
> use the higher CPUs even when it can't direct external interrupts at
> them. I worked on making Linux capable of it, as I said, but didn't
> pursue that in the end.
>
> I *suspect* Windows might be able to do it, based on the way the
> hyperv-iommu works (by cheating and returning -EINVAL when external
> interrupts are directed at higher CPUs).
>
>
--
MST
- Re: [PATCH 2/4] intel_iommu: Support IR-only mode without DMA translation, (continued)
Re: [PATCH 2/4] intel_iommu: Support IR-only mode without DMA translation, David Woodhouse, 2022/03/14
[PATCH 3/4] intel_iommu: Only allow interrupt remapping to be enabled if it's supported, David Woodhouse, 2022/03/14
Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, Igor Mammedov, 2022/03/16
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, David Woodhouse, 2022/03/16
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, Michael S. Tsirkin, 2022/03/16
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, David Woodhouse, 2022/03/16
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement,
Michael S. Tsirkin <=
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, Igor Mammedov, 2022/03/16
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, David Woodhouse, 2022/03/16
- Message not available
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, Igor Mammedov, 2022/03/17
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, David Woodhouse, 2022/03/17
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, Igor Mammedov, 2022/03/18
- Re: [PATCH 1/4] target/i386: Fix sanity check on max APIC ID / X2APIC enablement, David Woodhouse, 2022/03/18