On 1/18/23 14:10, Gerd Hoffmann wrote:
> Hi,
>
>> ... you could introduce a new fw_cfg boolean switch (and explain it in
>> the hang message) that meant: "I know what this QEMU bug is, I
>> understand its consequences are obscure, risky, and far-reaching in
>> OVMF, I've been warned, I know what
On 1/18/23 14:10, Ard Biesheuvel wrote:
> On Wed, 18 Jan 2023 at 12:50, Laszlo Ersek wrote:
>>
>> On 1/18/23 08:25, Gerd Hoffmann wrote:
>>> On Tue, Jan 17, 2023 at 05:43:53PM +0100, Ard Biesheuvel wrote:
On Tue, 17 Jan 2023 at 13:37, Gerd Hoffmann wrote:
>
> Hi,
>
In
On Wed, 18 Jan 2023 at 12:50, Laszlo Ersek wrote:
>
> On 1/18/23 08:25, Gerd Hoffmann wrote:
> > On Tue, Jan 17, 2023 at 05:43:53PM +0100, Ard Biesheuvel wrote:
> >> On Tue, 17 Jan 2023 at 13:37, Gerd Hoffmann wrote:
> >>>
> >>> Hi,
> >>>
> >> In particular the firmware makes no further dec
Hi,
> ... you could introduce a new fw_cfg boolean switch (and explain it in
> the hang message) that meant: "I know what this QEMU bug is, I
> understand its consequences are obscure, risky, and far-reaching in
> OVMF, I've been warned, I know what I'm doing". That's a relatively
> small additi
On 1/18/23 08:25, Gerd Hoffmann wrote:
> On Tue, Jan 17, 2023 at 05:43:53PM +0100, Ard Biesheuvel wrote:
>> On Tue, 17 Jan 2023 at 13:37, Gerd Hoffmann wrote:
>>>
>>> Hi,
>>>
>> In particular the firmware makes no further decisions based on
>> whether QEMU advertized some of these featur
On Tue, Jan 17, 2023 at 05:43:53PM +0100, Ard Biesheuvel wrote:
> On Tue, 17 Jan 2023 at 13:37, Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > >> In particular the firmware makes no further decisions based on
> > > >> whether QEMU advertized some of these features.
> > > >
> > > > I was thinking the
On Tue, 17 Jan 2023 at 13:37, Gerd Hoffmann wrote:
>
> Hi,
>
> > >> In particular the firmware makes no further decisions based on
> > >> whether QEMU advertized some of these features.
> > >
> > > I was thinking the other way around: When cpu hotplug is disabled in
> > > qemu it should be safe
Hi,
> >> In particular the firmware makes no further decisions based on
> >> whether QEMU advertized some of these features.
> >
> > I was thinking the other way around: When cpu hotplug is disabled in
> > qemu it should be safe to skip the whole cpu hotplug checking dance.
> > See test patch b
On 1/13/23 13:22, Gerd Hoffmann wrote:
> On Fri, Jan 13, 2023 at 11:10:54AM +0100, Laszlo Ersek wrote:
>> On 1/13/23 10:32, Gerd Hoffmann wrote:
>>> On Fri, Jan 13, 2023 at 07:03:54AM +0100, Gerd Hoffmann wrote:
Hi,
> - QEMU can be configured with other compat properties on the
On Fri, 13 Jan 2023 at 13:22, Gerd Hoffmann wrote:
>
> On Fri, Jan 13, 2023 at 11:10:54AM +0100, Laszlo Ersek wrote:
> > On 1/13/23 10:32, Gerd Hoffmann wrote:
> > > On Fri, Jan 13, 2023 at 07:03:54AM +0100, Gerd Hoffmann wrote:
> > >> Hi,
> > >>
> > >>> - QEMU can be configured with other compa
On Fri, Jan 13, 2023 at 11:10:54AM +0100, Laszlo Ersek wrote:
> On 1/13/23 10:32, Gerd Hoffmann wrote:
> > On Fri, Jan 13, 2023 at 07:03:54AM +0100, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >>> - QEMU can be configured with other compat properties on the command
> >>> line so that "CPU hotplug with S
On 1/13/23 10:32, Gerd Hoffmann wrote:
> On Fri, Jan 13, 2023 at 07:03:54AM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
>>> - QEMU can be configured with other compat properties on the command
>>> line so that "CPU hotplug with SMI" and "CPU hot-unplug with SMI" *not*
>>> be offered to the firmware. Th
On Fri, Jan 13, 2023 at 07:03:54AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > - QEMU can be configured with other compat properties on the command
> > line so that "CPU hotplug with SMI" and "CPU hot-unplug with SMI" *not*
> > be offered to the firmware. Then QEMU will reject hotplug attempts, and
Hi,
> - QEMU can be configured with other compat properties on the command
> line so that "CPU hotplug with SMI" and "CPU hot-unplug with SMI" *not*
> be offered to the firmware. Then QEMU will reject hotplug attempts, and
> the SMM hotplug code in edk2 will not be triggered by the (virtual)
> h
On 12/01/2023 17:58, Laszlo Ersek wrote:
The case is that both QEMU and edk2 check for each other's supported
features. It's a complex interwoven feature set with security
impact, which is exactly why we added feature negotiation at every
step -- effectively mutual negotiation wherever necessary
On 1/12/23 09:28, Laszlo Ersek wrote:
> In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
> protocol is (effectively) broken such that it suggests that switching from
> the legacy interface to the modern interface works, but in reality the
> switch never happens. The sympto
On 1/12/23 18:58, Laszlo Ersek wrote:
> Your proposal is entirely justified, from a practical / user
> perspective, but I'm not the right person for it.
This should do what you propose (untested), but I hate the code myself.
diff --git a/OvmfPkg/Library/PlatformInitLib/Platform.c
b/OvmfPkg/Libr
On 1/12/23 17:08, Michael Brown wrote:
> On 12/01/2023 13:22, Laszlo Ersek wrote:
Detect the issue in PlatformMaxCpuCountInitialization(), and
print an error message and *hang* if the issue is present.
>>>
>>> Would this mean that OVMF would refuse to start with all current
>>> distro ver
On 12/01/2023 13:22, Laszlo Ersek wrote:
Detect the issue in PlatformMaxCpuCountInitialization(), and
print an error message and *hang* if the issue is present.
Would this mean that OVMF would refuse to start with all current
distro versions of qemu (when not using KVM), or am I
misunderstandin
On 1/12/23 11:09, Ard Biesheuvel wrote:
> On Thu, 12 Jan 2023 at 10:56, Michael Brown wrote:
>>
>> On 12/01/2023 08:28, Laszlo Ersek wrote:
>>> In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
>>> protocol is (effectively) broken such that it suggests that switching from
On 1/12/23 10:55, Michael Brown wrote:
> On 12/01/2023 08:28, Laszlo Ersek wrote:
>> In QEMU v5.1.0, the CPU hotplug register block misbehaves: the
>> negotiation
>> protocol is (effectively) broken such that it suggests that switching
>> from
>> the legacy interface to the modern interface works,
On Thu, 12 Jan 2023 at 10:56, Michael Brown wrote:
>
> On 12/01/2023 08:28, Laszlo Ersek wrote:
> > In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
> > protocol is (effectively) broken such that it suggests that switching from
> > the legacy interface to the modern inter
On 12/01/2023 08:28, Laszlo Ersek wrote:
In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
protocol is (effectively) broken such that it suggests that switching from
the legacy interface to the modern interface works, but in reality the
switch never happens. The symptom h
In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
protocol is (effectively) broken such that it suggests that switching from
the legacy interface to the modern interface works, but in reality the
switch never happens. The symptom has been witnessed when using TCG
accelerati
24 matches
Mail list logo