Rebuild the "bios-tables-test" UEFI boot images with the SMBIOS entry
point reporting that has been added in the previous patch.
Cc: "Philippe Mathieu-Daudé"
Cc: Igor Mammedov
Launchpad: https://bugs.launchpad.net/qemu/+bug/1821884
Signed-off-by: Laszlo Ersek
---
tests/d
application, and report the addresses in new fields
appended to the BIOS_TABLES_TEST structure.
Cc: "Philippe Mathieu-Daudé"
Cc: Igor Mammedov
Launchpad: https://bugs.launchpad.net/qemu/+bug/1821884
Signed-off-by: Laszlo Ersek
---
tests/uefi-test-tools/UefiTestToolsPkg/Include/Guid/BiosTa
On 04/24/19 15:47, Peter Maydell wrote:
> On Tue, 23 Apr 2019 at 18:15, Laszlo Ersek wrote:
>>
>> Picked up the new feedback tags from the v4 thread, which had been
>> posted at:
>> - https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg01549.html
>> - 201904
See also: https://github.com/puiterwijk/qemu-ovmf-secureboot/issues/25
** Bug watch added: github.com/puiterwijk/qemu-ovmf-secureboot/issues #25
https://github.com/puiterwijk/qemu-ovmf-secureboot/issues/25
--
You received this bug notification because you are a member of qemu-
devel-ml,
See also: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
** Bug watch added: bugzilla.tianocore.org/ #1747
https://bugzilla.tianocore.org/show_bug.cgi?id=1747
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Public bug reported:
The feature added in
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
and exposed by libvirt as
https://libvirt.org/formatdomain.html#elementsSysinfo
allows the user to specify up to 255 strings in the unofmatted area of
the Type
Hello Wainer,
(answering because I dislike ignoring emails without giving any feedback:)
On 04/23/19 21:28, Wainer dos Santos Moschetta wrote:
> Ping. More reviews needed.
>
> I've already got Philippe's reviewed-by, thanks!
I'm going to skip this one. According to "scripts/get_maintainer.pl",
; +}
> +
> static void fw_cfg_boot_set(void *opaque, const char *boot_device,
> Error **errp)
> {
>
My previous questions apply. From my POV,
Reviewed-by: Laszlo Ersek
complex code so I don't mind if you opt for the code duplication.)
(2) PPC highlights my question#2 from under "v3 3/7". Namely, we
extracted the x86 constants into "hw/i386/fw_cfg.h". But the PPC
constants already exist in "include/hw/ppc/ppc.h". (My point being the
difference in the "include/" pathname prefix.) Should we be consistent?
If you decide to stick with this variant:
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
ch_wellknown_keys[i].name;
> +}
> +}
> +return NULL;
> +}
> +
> static void fw_cfg_boot_set(void *opaque, const char *boot_device,
> Error **errp)
> {
>
Same questions. From my POV:
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
} fw_cfg_arch_wellknown_keys[] = {
> +{FW_CFG_ACPI_TABLES, "acpi_tables"},
> +{FW_CFG_SMBIOS_ENTRIES, "smbios_entries"},
> +{FW_CFG_IRQ0_OVERRIDE, "irq0_override"},
> +{FW_CFG_E820_TABLE, "e820_tables"},
s/e820_tables/e820_table/
Reviewe
IRQ0_OVERRIDE (FW_CFG_ARCH_LOCAL + 2)
> -#define FW_CFG_E820_TABLE (FW_CFG_ARCH_LOCAL + 3)
> -#define FW_CFG_HPET (FW_CFG_ARCH_LOCAL + 4)
> -
> #define E820_NR_ENTRIES 16
>
> struct e820_entry {
>
I'm not insisting on any particular code changes here, just please
consider (1) and (2) above in some way. (Stating why the code is fine
as-is is OK by me too.)
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
; + *
> + * @key: The uint16 selector key.
> + *
> + * Returns: The stringified architecture-specific name if the selector
> + * refers to a well-known numerically defined item, or NULL on
> + * key lookup failure.
> + */
We might want to document that we expect F
ftmmu/qemu-system-aarch64: No such file or directory
Apply Phil's fix to this make target too.
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Tested-by: Igor Mammedov
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-
tools", where an $(EDK2_EFIROM) pre-requisite would be
misleading.
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Acked-by: Michael S. Tsirkin
Reviewed-by: Igor Mammedov
---
Notes:
pull:
- pick up Phil's R-b / T-b
ines the
"-n" option argument for "build", from the MAKEFLAGS variable (i.e. based
on the presence of a make job server).
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Michal Privoznik
Reviewed-by: Michael S. Tsi
Suggested-by: Michael S. Tsirkin
Suggested-by: Philippe Mathieu-Daudé
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Tested-by: Igor Mammedov
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Igor Mammedov
---
Notes
e check" and other ad-hoc tests
one might want to run in the build directory.
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Michael S. Tsirkin
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
---
Notes:
pull:
.txt: Update e-mail address for Julien Grall
Krzysztof Koch (1):
ShellPkg/UefiShellAcpiViewCommandLib: Add support for PPTT
Laszlo Ersek (47):
EmulatorPkg: require GCC48 or later
OvmfPkg: require GCC48 or later
Vlv2TbltDevicePkg: assume GCC48 or later
BaseTools/tools_def.
Update the README file with information on the images added previously,
and provide firmware descriptor documents that conform to
"docs/interop/firmware.json".
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Reviewed-by: Michael S. Tsirkin
Tested-by: Igor Mammedov
org/show_bug.cgi?id=1607>. For now, work
around the issue (in advance) by forcing Python2. (The workaround is a
no-op before we move to edk2-stabe201903 in the roms/edk2 submodule.)
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-by:
Extract the dense logic for architecture and toolchain massaging from
"tests/uefi-test-tools/build.sh", to a set of small functions. We'll reuse
these functions for building full platform firmware images.
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by
Add the "efi" target to "Makefile".
Introduce "Makefile.edk2" for building and cleaning the firmware images
and varstore templates.
Collect the common bits from the recipes in the helper script
"edk2-build.sh".
Signed-off-by: Laszlo Ersek
Reviewed-by:
Add the files built by the last patch: (compressed) binaries, and the
cumulative license text that covers them.
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Michael S. Tsirkin
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Igor
Adapt the qemu_edk2_get_toolchain() function in "roms/edk2-funcs.sh" in
advance to edk2 commit 8d7cdfae8cb8 ("OvmfPkg: require GCC48 or later",
2019-01-08), which is part of the "edk2-stable201903" tag.
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daud
inaries are meant to be used by both end-users and by the "BIOS tables"
unit tests in qtest ("make check").
--------
Laszlo Ersek (12):
roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.s
(more precisely, the nvram element will be auto-generated when you exit
"virsh edit", and the nvram file will be created (copied) from the
varstore template when you launch the domain)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Hi José,
your domain XML is bogus with regard to the firmware configuration. You
have:
/var/lib/libvirt/qemu/nvram/os-1-ovmf.fd
and no element, and you write that "os-1-ovmf.fd" is a copy of
"OVMF_VARS.fd".
The element, with @type='pflash', no other attributes, and then
no sibling
On 04/18/19 11:28, Andrew Jones wrote:
> Hi all,
>
> First some background:
>
> For the userspace side of AArch64 guest SVE support we need to
> expose KVM's allowed vector lengths bitmap to the user and allow
> the user to choose a subset of that bitmap. Since bitmaps are a
> bit awkward to
This bug report is invalid, for a less important reason and for a more
important reason.
(1) The less important reason is that "/pci@i0cf8/*@6" is a string that
would never be generated by QEMU, as a bootorder entry. QEMU places
specific OpenFirmware device paths into the "bootorder" fw_cfg file.
On 04/18/19 07:02, Joachim Durchholz wrote:
> Am 17.04.19 um 20:27 schrieb Laszlo Ersek:
>> So, let's look at your original question again (which was not a problem
>> statement):
>
> So you need an explicit problem statement to know that somebody might
> have a problem
Hi Joachim,
On 04/17/19 19:09, Joachim Durchholz wrote:
> Sorry, I'm done having to argue against(!) a person who's stonewalling
> me by wilfully ignoring differences ("doesn't work perfectly"
> interpreted as "does not work at all"), discounting
> just-for-testing-purpose workarounds as if they
On 04/16/19 09:24, Gerd Hoffmann wrote:
> On Mon, Apr 15, 2019 at 03:10:09PM -0400, John Snow wrote:
>>
>>
>> On 4/13/19 5:02 AM, Joachim Durchholz wrote:
>>> Hi all,
>>>
>>> what's the reasoning behind "We need a terminal output" in curses.c?
>
> curses needs a terminal.
>
>>> I don't really
configure: num-blocks
> realize
> map
> virt_flash_map1() for flash[1]
> configure: num-blocks
> realize
> map
>
th -machine");
> -exit(1);
> -}
> -pflash_blk[i] = blk_by_legacy_dinfo(pflash_drv);
> -qdev_prop_set_drive(DEVICE(pcms->flash[i]),
> - "drive", pflash_blk[i], _fatal);
> -loc_pop();
> +pflash_blk[i] = pflash_cfi01_get_blk(pcms->flash[i]);
> }
>
> /* Reject gaps */
>
Reviewed-by: Laszlo Ersek
On 04/16/19 11:13, Markus Armbruster wrote:
> Factored out of pc_system_firmware_init() so the next commit can reuse
s/Factored/Factor/
(no need to repost, can be done in the PULL)
with that:
Reviewed-by: Laszlo Ersek
Thanks!
Laszlo
> it in hw/arm/virt.c.
>
> Signed-of
On 04/12/19 19:49, Markus Armbruster wrote:
> Laszlo Ersek writes:
>
>> On 04/11/19 15:56, Markus Armbruster wrote:
>>> The ARM virt machines put firmware in flash memory. To configure it,
>>> you use -drive if=pflash,unit=0,... and optionally -drive
>>&g
On 04/12/19 09:52, Markus Armbruster wrote:
> Laszlo Ersek writes:
>
>> On 04/11/19 21:50, Laszlo Ersek wrote:
>>> On 04/11/19 21:35, Laszlo Ersek wrote:
>>>> On 04/11/19 15:56, Markus Armbruster wrote:
>>>>> Factored out of pc_system_firmware_in
On 04/12/19 10:05, Paolo Bonzini wrote:
> On 12/04/19 09:58, Laszlo Ersek wrote:
>> On 04/12/19 01:55, Singh, Brijesh wrote:
>>> There are limited numbers of the SEV guests that can be run concurrently.
>>> A management applications may need to know this limit so th
On 04/11/19 15:56, Markus Armbruster wrote:
> The ARM virt machines put firmware in flash memory. To configure it,
> you use -drive if=pflash,unit=0,... and optionally -drive
> if=pflash,unit=1,...
>
> Why two -drive? This permits setting up one part of the flash memory
> read-only, and the
is not exposed to the application. Add a new
> 'sev-max-guest' field in the query-sev-capabilities to provide this
> information.
>
> Cc: Paolo Bonzini
> Cc: Markus Armbruster
> Cc: Eric Blake
> Cc: Daniel P. Berrangé
> Cc: Laszlo Ersek
> Cc: Erik Skultety
> Cc:
On 04/11/19 21:02, Singh, Brijesh wrote:
>
>
> On 4/11/19 1:10 PM, Laszlo Ersek wrote:
>> On 04/11/19 19:59, Singh, Brijesh wrote:
>>> There are limited numbers of the SEV guests that can be run concurrently.
>>> A management applications may need to know this l
On 04/11/19 21:50, Laszlo Ersek wrote:
> On 04/11/19 21:35, Laszlo Ersek wrote:
>> On 04/11/19 15:56, Markus Armbruster wrote:
>>> Factored out of pc_system_firmware_init() so the next commit can reuse
>>> it in hw/arm/virt.c.
>>>
>>> Signed-off
On 04/11/19 21:35, Laszlo Ersek wrote:
> On 04/11/19 15:56, Markus Armbruster wrote:
>> Factored out of pc_system_firmware_init() so the next commit can reuse
>> it in hw/arm/virt.c.
>>
>> Signed-off-by: Markus Armbruster
>> ---
On 04/11/19 15:56, Markus Armbruster wrote:
> Factored out of pc_system_firmware_init() so the next commit can reuse
> it in hw/arm/virt.c.
>
> Signed-off-by: Markus Armbruster
> ---
> hw/block/pflash_cfi01.c | 30 ++
> hw/i386/pc_sysfw.c | 19
On 04/11/19 20:10, Laszlo Ersek wrote:
> On 04/11/19 19:59, Singh, Brijesh wrote:
>> There are limited numbers of the SEV guests that can be run concurrently.
>> A management applications may need to know this limit so that it can place
>> SEV VMs on hosts which have suitabl
is not exposed to the application. Add a new
> 'sev-max-guest' field in the query-sev-capabilities to provide this
> information.
>
> Cc: Paolo Bonzini
> Cc: Markus Armbruster
> Cc: Eric Blake
> Cc: Daniel P. Berrangé
> Cc: Laszlo Ersek
> Cc: Erik Skultety
>
On 04/10/19 17:10, Philippe Mathieu-Daudé wrote:
> On 4/10/19 4:58 PM, Laszlo Ersek wrote:
>> On 04/10/19 06:57, Philippe Mathieu-Daudé wrote:
>>> In commit 1cab464136b4 we incorrectly described the
>>> EDK2_BASETOOLS_OPTFLAGS can pass CPPFLAGS and CFLAGS
>>
> clean:
> rm -rf seabios/.config seabios/out seabios/builds
> $(MAKE) -C sgabios clean
And this seems to belong to:
[Qemu-devel] [PATCH for-4.1 v4 07/12]
roms: build edk2 firmware binaries and variable store templates
> @@ -166,3 +171,4 @@ clean:
> rm -rf u-boot/build.e500
> $(MAKE) -C u-boot-sam460ex distclean
> $(MAKE) -C skiboot clean
> + $(MAKE) -f Makefile.edk2 clean
>
Ditto.
So, for qemu-trivial's sake:
Nacked-by: Laszlo Ersek
Thanks
Laszlo
e more accurate.
>
> Reported-by: Laszlo Ersek
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> roms/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/roms/Makefile b/roms/Makefile
> index 1ff78b63bb3..d7fd6025e7c 100644
> --- a/ro
On 04/10/19 08:25, Olaf Hering wrote:
> Am Mon, 8 Apr 2019 13:05:07 +0200
> schrieb Laszlo Ersek :
>
>> Then build scripts could be updated to invoke:
>>
>> make -C roms \
>> EDK2_BASETOOLS_OPTFLAGS='...' \
>> EDK2_BASETOOLS_LDFLAGS='...' \
Suggested-by: Michael S. Tsirkin
Suggested-by: Philippe Mathieu-Daudé
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Tested-by: Igor Mammedov
Reviewed-by: Michael S. Tsirkin
---
Notes:
v4:
- no change
e check" and other ad-hoc tests
one might want to run in the build directory.
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Michael S. Tsirkin
---
Notes:
v4:
- no change
v3:
- pick up Michal's R-b
Add the files built by the last patch: (compressed) binaries, and the
cumulative license text that covers them.
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Michael S. Tsirkin
---
Notes:
v4:
- no change
v3
ftmmu/qemu-system-aarch64: No such file or directory
Apply Phil's fix to this make target too.
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Tested-by: Igor Mammedov
Reviewed-by: Michael S. Tsirkin
---
Notes:
v4:
- no change
v3:
- pick up Mic
org/show_bug.cgi?id=1607>. For now, work
around the issue (in advance) by forcing Python2. (The workaround is a
no-op before we move to edk2-stabe201903 in the roms/edk2 submodule.)
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-by:
Add the "efi" target to "Makefile".
Introduce "Makefile.edk2" for building and cleaning the firmware images
and varstore templates.
Collect the common bits from the recipes in the helper script
"edk2-build.sh".
Signed-off-by: Laszlo Ersek
Reviewed-by:
.txt: Update e-mail address for Julien Grall
Krzysztof Koch (1):
ShellPkg/UefiShellAcpiViewCommandLib: Add support for PPTT
Laszlo Ersek (47):
EmulatorPkg: require GCC48 or later
OvmfPkg: require GCC48 or later
Vlv2TbltDevicePkg: assume GCC48 or later
BaseTools/tools_def.
Update the README file with information on the images added previously,
and provide firmware descriptor documents that conform to
"docs/interop/firmware.json".
Signed-off-by: Laszlo Ersek
Reviewed-by: Michal Privoznik
Reviewed-by: Michael S. Tsirkin
Tested-by: Igor Mammedov
---
Not
Adapt the qemu_edk2_get_toolchain() function in "roms/edk2-funcs.sh" in
advance to edk2 commit 8d7cdfae8cb8 ("OvmfPkg: require GCC48 or later",
2019-01-08), which is part of the "edk2-stable201903" tag.
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daud
tools", where an $(EDK2_EFIROM) pre-requisite would be
misleading.
Signed-off-by: Laszlo Ersek
---
Notes:
v4:
- rebase: resolve conflicts with
- commit d912e795e029 ("roms: Rename the EFIROM variable to avoid
clashing with iPXE", 2019-04-09)
//mid.mail-archive.com/20190321113408.19929-1-lersek@redhat.com
Thanks,
Laszlo
Laszlo Ersek (12):
roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh"
roms/edk2-funcs.sh: require gcc-4.8+ for building i386 and x86_64
tests/uefi-test-tools/build.sh: work around Tiano
Extract the dense logic for architecture and toolchain massaging from
"tests/uefi-test-tools/build.sh", to a set of small functions. We'll reuse
these functions for building full platform firmware images.
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by
ines the
"-n" option argument for "build", from the MAKEFLAGS variable (i.e. based
on the presence of a make job server).
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Michal Privoznik
Reviewed-by: Mich
On 04/09/19 16:00, Peter Maydell wrote:
> On Tue, 9 Apr 2019 at 14:47, Philippe Mathieu-Daudé wrote:
>>
>> Hi,
>>
>> Two trivial fixes to avoid the latest EDK2 testing series to
>> cause trouble to downstream distributions (in particular if
>> they have PIE enforced).
>>
>> Since v2:
>> -
https://lists.opensuse.org/opensuse-factory/2017-06/msg00403.html
>
> Reported-by: Olaf Hering
> Suggested-by: Laszlo Ersek
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> roms/Makefile | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff
tool provided by the EDK2 project.
>
> To avoid the name clash and make the difference between the
> projects obvious, rename the variable used by the EDK2 project
> as EDK2_EFIROM.
>
> Fixes: f590a812c21074e82228de3e1dfb57b75fc02b62
> Reported-by: Olaf Hering
> Reviewed-by: Lasz
On 04/09/19 12:29, Shameer Kolothum wrote:
> This patch adds memory nodes corresponding to PC-DIMM regions.
> This will enable support for cold plugged device memory for Guests
> with DT boot.
>
> Signed-off-by: Shameer Kolothum
> Signed-off-by: Eric Auger
> ---
> hw/arm/boot.c | 42
On 04/08/19 15:43, Xiang Zheng wrote:
>
> On 2019/4/3 23:35, Laszlo Ersek wrote:
>>> I thought about your comments and wrote the following patch (just for test)
>>> which uses a file mapping to replace the anonymous mapping. UEFI seems to
>>> work
>>> f
On 04/05/19 17:33, Philippe Mathieu-Daudé wrote:
> Since commit f590a812c210 we build the EDK2 EfiRom utility
> unconditionally. This has been tested on all the Linux
> distribution providing continuous integration (namely Debian
> and Fedora). Not all distributions are able to build the
> EfiRom
_targets)) \
> $(patsubst %,bin-x86_64-efi/%.efidrv,$(pxerom_targets))
>
> -$(EFIROM):
> +$(EDK2_EFIROM):
> $(MAKE) -C edk2/BaseTools
>
> slof:
>
Upon reading your and Olaf's comments in the v1 thread:
[PATCH for-4.0] roms: Allow the EFIROM vari
On 04/08/19 11:09, Olaf Hering wrote:
> Am Mon, 8 Apr 2019 11:04:09 +0200
> schrieb Laszlo Ersek :
>
>> This is not a QEMU build failure, but an issue in the downstream
>> packaging that not only tries to build QEMU, but performs a
>> maintainer build on binary artif
On 04/05/19 12:59, Olaf Hering wrote:
> Am Fri, 5 Apr 2019 12:49:15 +0200
> schrieb Philippe Mathieu-Daudé :
>
>> The EDK2 submodule was added for UEFI testing, you don't need to compile
>> it to build/use QEMU.
>>
>> How did you end up compiling it?
>
> The qemu.spec file has this since a very
On 04/08/19 11:02, Laszlo Ersek wrote:
> On 04/05/19 17:33, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> Two trivial fixes to avoid the latest EDK2 testing series to
>> cause trouble to downstream distributions (in particular if
>> they have PIE enforced).
On 04/05/19 17:33, Philippe Mathieu-Daudé wrote:
> Hi,
>
> Two trivial fixes to avoid the latest EDK2 testing series to
> cause trouble to downstream distributions (in particular if
> they have PIE enforced).
I disgree with this.
(1) In the first commit message, you say,
"The iPXE project
Hi Igor,
On 04/04/19 12:14, Igor Mammedov wrote:
> On Tue, 2 Apr 2019 18:19:00 +0200
> Markus Armbruster wrote:
>
>> Signed-off-by: Markus Armbruster
>
> Reviewed-by: Markus Armbruster
did you mean: "R-b: Igor" instead?
Laszlo
On 04/03/19 16:12, Xiang Zheng wrote:
> Hi Laszlo and Markus,
>
> Thanks for your useful suggestions and comments! :)
>
> On 2019/3/27 2:36, Markus Armbruster wrote:
>> Laszlo Ersek writes:
>>
>>> On 03/26/19 17:39, Markus Armbruster wrote:
>>>>
On 04/03/19 14:10, Shameerali Kolothum Thodi wrote:
> So, the condition for hiding the hotpluggable memory nodes in question
> from the DT is:
>
> (aarch64 && firmware_loaded && acpi_enabled)
>>> While UEFI has bindings for both 32-bit and 64-bit ARM, ACPI has a
>>>
On 04/03/19 11:49, Igor Mammedov wrote:
> On Tue, 2 Apr 2019 17:38:26 +0200
> Laszlo Ersek wrote:
>
>> On 04/02/19 17:29, Auger Eric wrote:
>>> Hi Laszlo,
>>>
>>> On 4/1/19 3:07 PM, Laszlo Ersek wrote:
>>>> On 03/29/19 14:56, Auger Eric
On 04/02/19 17:52, Laszlo Ersek wrote:
> On 04/02/19 17:42, Auger Eric wrote:
>>>>> The firmware does consume DT:
>>>>>
>>>>> - If you start QEMU *with* "-no-acpi", then the DT is both consumed by
>>>>> the firmware (for
On 04/02/19 17:42, Auger Eric wrote:
> Hi Laszlo,
>
> On 4/2/19 12:33 PM, Laszlo Ersek wrote:
>> On 04/02/19 09:42, Igor Mammedov wrote:
>>> On Mon, 1 Apr 2019 15:07:05 +0200
>>> Laszlo Ersek wrote:
>>>
>>>> On 03/29/19 14:56, Auger Eric wr
On 04/02/19 17:29, Auger Eric wrote:
> Hi Laszlo,
>
> On 4/1/19 3:07 PM, Laszlo Ersek wrote:
>> On 03/29/19 14:56, Auger Eric wrote:
>>> Hi Ard,
>>>
>>> On 3/29/19 2:14 PM, Ard Biesheuvel wrote:
>>>> On Fri, 29 Mar 2019 at 14:12, Auger Eric
On 04/02/19 09:42, Igor Mammedov wrote:
> On Mon, 1 Apr 2019 15:07:05 +0200
> Laszlo Ersek wrote:
>
>> On 03/29/19 14:56, Auger Eric wrote:
>>> Hi Ard,
>>>
>>> On 3/29/19 2:14 PM, Ard Biesheuvel wrote:
>>>> On Fri, 29 Mar 2019
amm...@redhat.com;
>>>>> peter.mayd...@linaro.org; shannon.zha...@gmail.com;
>>>>> sa...@linux.intel.com; sebastien.bo...@intel.com
>>>>> Cc: Linuxarm ; xuwei (O) ;
>>>>> Laszlo Ersek ; Ard Biesheuvel
>>>>> ; Leif Lindhol
In order for the guest kernel to expose ACPI S3 suspend to a privileged
guest user, the guest kernel first checks if the platform (hardware and
firmware) support ACPI S3. This in turn depends on whether the DSDT
offers a package called _S3.
For example, on the "pc" machine type, S3 can be
On 03/27/19 17:15, Paolo Bonzini wrote:
> On 27/03/19 17:05, Daniel P. Berrangé wrote:
>> On Wed, Mar 27, 2019 at 04:58:23PM +0100, Paolo Bonzini wrote:
>>> On 27/03/19 16:30, Daniel P. Berrangé wrote:
Perhaps the VM test scripts should do a "HEAD" request for the image
every time to
On 03/27/19 16:30, Daniel P. Berrangé wrote:
> On Wed, Mar 27, 2019 at 03:25:19PM +, Peter Maydell wrote:
>> On Wed, 27 Mar 2019 at 14:31, Laszlo Ersek wrote:
>>> ... Which in turn raises the question: *before* Peter reported the "xz"
>>> failure first,
On 03/27/19 16:25, Peter Maydell wrote:
> On Wed, 27 Mar 2019 at 14:31, Laszlo Ersek wrote:
>> ... Which in turn raises the question: *before* Peter reported the "xz"
>> failure first, against my series, at
>>
>> https://lists.gnu.org/archive/html/qemu-d
On 03/27/19 16:06, Paolo Bonzini wrote:
> On 27/03/19 15:31, Laszlo Ersek wrote:
>> OK, let me be constructive here. Right now, the *current*
>> "tests/vm/openbsd" script is unusable for *any* testing. (My testing did
>> succeed agains the previous image,
(Keeping Fam on the address list, adding Dan & Markus)
On 03/27/19 14:18, Paolo Bonzini wrote:
> On 25/03/19 11:40, Laszlo Ersek wrote:
>>>>>
>>>>> (1) The image file at
>>>>> <http://download.patchew.org/openbsd-6.1-amd64.img.xz> has been
21113408.19929-1-lersek@redhat.com
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06148.html
)
** Changed in: qemu
Assignee: (unassigned) => Laszlo Ersek (Red Hat) (lersek)
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because yo
On 03/27/19 11:09, Igor Mammedov wrote:
> On Tue, 26 Mar 2019 15:16:57 +0100
> Laszlo Ersek wrote:
>
>> On 03/26/19 14:09, Igor Mammedov wrote:
>>> For testcase to use UEFI firmware, one needs to provide and specify
>>> firmwarei and varstore blobs names
On 03/26/19 17:39, Markus Armbruster wrote:
> Laszlo Ersek writes:
>> With the dynamic sizing in QEMU (which, IIRC, I had originally
>> introduced still in the 1MB times, due to the split between the
>> executable and varstore parts), both the 1MB->2MB switch, an
On 03/26/19 15:19, Laszlo Ersek wrote:
> On 03/26/19 14:09, Igor Mammedov wrote:
>> once FW provides a pointer to SMBIOS entry point like it does for
>> RSDP it should be possible to enable this one the same way.
>>
>> Signed-off-by: Igor Mammedov
>> ---
izes the flash devices.
>
> Else, firmware resides in ROM. The onboard flash devices aren't used
> then. pc_system_firmware_init() destroys them unrealized, along with
> the alias properties.
>
> The existing code to pick up drives defined with -drive if=pflash is
> replaced
qtest_add_func("acpi/q35/numamem", test_acpi_q35_tcg_numamem);
> qtest_add_func("acpi/piix4/dimmpxm", test_acpi_piix4_tcg_dimm_pxm);
> qtest_add_func("acpi/q35/dimmpxm", test_acpi_q35_tcg_dimm_pxm);
> +} else if (strcmp(arch, "aarch64") == 0) {
> +qtest_add_func("acpi/virt", test_acpi_virt_tcg);
> }
> ret = g_test_run();
> boot_sector_cleanup(disk);
>
With the Makefile.include hunk dropped (and regardless of the constants):
Reviewed-by: Laszlo Ersek
Thanks,
Laszlo
_uefi) {
> +g_assert(data->scan_len);
> +data->rsdp_addr = acpi_find_rsdp_address_uefi(data->qts,
> +data->ram_start, data->scan_len);
> +} else {
> +boot_sector_test(data->qts);
> +test_acpi_rsdp_address(data);
>
gt; +}
>
> assert(!global_qtest);
> qtest_quit(data->qts);
>
For now:
Reviewed-by: Laszlo Ersek
Can you file a LP item about this, and assign it to me? (I can assign it
to myself as well if you send me the link.)
... In fact, if we have a LP ticket, we could reference
On 03/26/19 07:17, Markus Armbruster wrote:
> Zheng Xiang writes:
>
>> Hi Peter,
>>
>> Thanks for your reply!
>>
>> On 2019/3/25 21:11, Peter Maydell wrote:
>>> On Mon, 25 Mar 2019 at 12:53, Xiang Zheng wrote:
Currently we fill the VIRT_FLASH space with two 64MB NOR images when
On 03/25/19 14:11, Peter Maydell wrote:
> On Mon, 25 Mar 2019 at 12:53, Xiang Zheng wrote:
>>
>> Currently we fill the VIRT_FLASH space with two 64MB NOR images when
>> using persistent UEFI variables on QEMU. Actually we only use a very
>> small part of the memory while the rest significant
801 - 900 of 4203 matches
Mail list logo
