On 18 January 2017 at 17:26, Laszlo Ersek wrote:
> In brief, for one data point, I'd be fine if we didn't tie this change
> to machine types.
We seem to have arrived at a consensus that we don't need
to version-constrain this change, so I'm applying Ard's
patch to
On 01/18/17 18:02, Ard Biesheuvel wrote:
> On 18 January 2017 at 15:55, Laszlo Ersek wrote:
>> On 01/18/17 16:18, Igor Mammedov wrote:
>>> On Tue, 17 Jan 2017 10:56:53 +
>>> Peter Maydell wrote:
>>>
On 17 January 2017 at 09:49, Andrew Jones
On 18 January 2017 at 15:55, Laszlo Ersek wrote:
> On 01/18/17 16:18, Igor Mammedov wrote:
>> On Tue, 17 Jan 2017 10:56:53 +
>> Peter Maydell wrote:
>>
>>> On 17 January 2017 at 09:49, Andrew Jones wrote:
In some cases
On 01/18/17 16:18, Igor Mammedov wrote:
> On Tue, 17 Jan 2017 10:56:53 +
> Peter Maydell wrote:
>
>> On 17 January 2017 at 09:49, Andrew Jones wrote:
>>> In some cases the problem we're solving with the compat guards is
>>> a bit hypothetical,
On Tue, 17 Jan 2017 10:56:53 +
Peter Maydell wrote:
> On 17 January 2017 at 09:49, Andrew Jones wrote:
> > In some cases the problem we're solving with the compat guards is
> > a bit hypothetical, but, IMHO, nonetheless a good practice. While
>
On 17 January 2017 at 09:49, Andrew Jones wrote:
> On Mon, Jan 16, 2017 at 07:31:33PM +, Ard Biesheuvel wrote:
>> On 16 January 2017 at 18:20, Peter Maydell wrote:
>> > On 16 January 2017 at 17:30, Ard Biesheuvel
>> >
On Mon, Jan 16, 2017 at 11:35:04PM +0100, Laszlo Ersek wrote:
> On 01/16/17 22:23, Ard Biesheuvel wrote:
> > On 16 January 2017 at 21:13, Laszlo Ersek wrote:
> >> On 01/16/17 20:31, Ard Biesheuvel wrote:
> >>> On 16 January 2017 at 18:20, Peter Maydell
On 17 January 2017 at 09:49, Andrew Jones wrote:
> In some cases the problem we're solving with the compat guards is
> a bit hypothetical, but, IMHO, nonetheless a good practice. While
> we may be sure that AAVMF and Linux will be fine with this table
> changing under their
On 01/17/17 10:06, Ard Biesheuvel wrote:
> On 17 January 2017 at 08:50, Laszlo Ersek wrote:
>> (my reply is no longer related to the patch, so maybe I shouldn't send
>> it... I can't resist, sorry :))
>>
>> On 01/17/17 08:47, Ard Biesheuvel wrote:
>>> On 16 January 2017 at
On Mon, Jan 16, 2017 at 07:31:33PM +, Ard Biesheuvel wrote:
> On 16 January 2017 at 18:20, Peter Maydell wrote:
> > On 16 January 2017 at 17:30, Ard Biesheuvel
> > wrote:
> >> On 16 January 2017 at 17:25, Peter Maydell
On 17 January 2017 at 08:50, Laszlo Ersek wrote:
> (my reply is no longer related to the patch, so maybe I shouldn't send
> it... I can't resist, sorry :))
>
> On 01/17/17 08:47, Ard Biesheuvel wrote:
>> On 16 January 2017 at 22:35, Laszlo Ersek wrote:
>
>>>
(my reply is no longer related to the patch, so maybe I shouldn't send
it... I can't resist, sorry :))
On 01/17/17 08:47, Ard Biesheuvel wrote:
> On 16 January 2017 at 22:35, Laszlo Ersek wrote:
>> The UEFI memory map will reflect allocations from the GCD memory space,
>> for
On 16 January 2017 at 22:35, Laszlo Ersek wrote:
> On 01/16/17 22:23, Ard Biesheuvel wrote:
>> On 16 January 2017 at 21:13, Laszlo Ersek wrote:
>>> On 01/16/17 20:31, Ard Biesheuvel wrote:
On 16 January 2017 at 18:20, Peter Maydell
On 01/16/17 22:23, Ard Biesheuvel wrote:
> On 16 January 2017 at 21:13, Laszlo Ersek wrote:
>> On 01/16/17 20:31, Ard Biesheuvel wrote:
>>> On 16 January 2017 at 18:20, Peter Maydell wrote:
On 16 January 2017 at 17:30, Ard Biesheuvel
On 16 January 2017 at 21:13, Laszlo Ersek wrote:
> On 01/16/17 20:31, Ard Biesheuvel wrote:
>> On 16 January 2017 at 18:20, Peter Maydell wrote:
>>> On 16 January 2017 at 17:30, Ard Biesheuvel
>>> wrote:
On 16 January
On 01/16/17 20:31, Ard Biesheuvel wrote:
> On 16 January 2017 at 18:20, Peter Maydell wrote:
>> On 16 January 2017 at 17:30, Ard Biesheuvel
>> wrote:
>>> On 16 January 2017 at 17:25, Peter Maydell wrote:
On 13
On 16 January 2017 at 18:20, Peter Maydell wrote:
> On 16 January 2017 at 17:30, Ard Biesheuvel wrote:
>> On 16 January 2017 at 17:25, Peter Maydell wrote:
>>> On 13 January 2017 at 17:32, Ard Biesheuvel
On 16 January 2017 at 17:30, Ard Biesheuvel wrote:
> On 16 January 2017 at 17:25, Peter Maydell wrote:
>> On 13 January 2017 at 17:32, Ard Biesheuvel
>> wrote:
>>> Linux for arm64 v4.10 and later will complain if
On 16 January 2017 at 17:25, Peter Maydell wrote:
> On 13 January 2017 at 17:32, Ard Biesheuvel wrote:
>> Linux for arm64 v4.10 and later will complain if the ECAM config space is
>> not reserved in the ACPI namespace:
>>
>> acpi PNP0A08:00:
On 13 January 2017 at 17:32, Ard Biesheuvel wrote:
> Linux for arm64 v4.10 and later will complain if the ECAM config space is
> not reserved in the ACPI namespace:
>
> acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x3f00-0x3fff] not
> reserved in ACPI
Linux for arm64 v4.10 and later will complain if the ECAM config space is
not reserved in the ACPI namespace:
acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x3f00-0x3fff] not
reserved in ACPI namespace
The rationale is that OSes that don't consume the MCFG table should still
be able
21 matches
Mail list logo