mu/+bug/1831477
--------
Laszlo Ersek (6):
roms/Makefile.edk2: define edk2-stable201905 network feature test macros
roms/edk2: update submodule from edk2-stable201903 to edk2-stable201905
roms/Makefile.edk2: remove edk2-stable201903 network feature test ma
ef: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
roms/Makefile.edk2 | 10 ++
1 file changed, 10 insertions(+)
diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
index 822c547fec64..
ug/1831477
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
roms/Makefile.edk2 | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
index 071d6e454b68..6a19498d0738 100644
ptoPkg/OpensslLib: fix VS2017 build failure
474 b8993a34ae00 edk2: Update additional licenses in Readme.md
475 98d8f194e5a6 CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem
476 b66c4c4ff918 Revert "UefiPayloadPkg: Remove legacy PIC 8259 driver"
477 20d2e5a125e3 CryptoPkg/Open
; text file.
Cc: Philippe Mathieu-Daudé
Ref: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
roms/Makefile.edk2 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/roms/Makefile.edk2 b/roms/Makefi
Refresh the "pc-bios/README" file with edk2, OpenSSL, and Berkeley
SoftFloat release info, matching the edk2-stable201905 firmware images
added in the previous patch.
Cc: Philippe Mathieu-Daudé
Ref: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek
Reviewed-by
Rebuild the pc-bios/edk2-*.fd.bz2 binaries, and regenerate
pc-bios/edk2-licenses.txt, based on the edk2-stable201905 release.
Cc: Philippe Mathieu-Daudé
Ref: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu
uot;boot-sector.h"
>
Opinions vary whether empty commit message bodies are good style or not.
Personally I prefer to put at least one sentence in there, even if it
only repeats the subject line. Up to subsystem maintainers to decide I
guess.
With the commit message updated, or not:
Reviewed-by: Laszlo Ersek
mi.h". (I can't suggest just "ipmi.h", because
that isn't unique.)
With this update:
Reviewed-by: Laszlo Ersek
Thanks,
Laszlo
> There is no need to have this include publicly exposed,
> reduce the visibility by moving it in hw/smbios/.
>
> S
a/hw/smbios/smbios_type_38.c b/hw/smbios/smbios_type_38.c
> index d84e87d608..a1ad28d059 100644
> --- a/hw/smbios/smbios_type_38.c
> +++ b/hw/smbios/smbios_type_38.c
> @@ -12,7 +12,6 @@
> #include "hw/smbios/smbios.h"
> #include "qemu/error-report.h"
> #include "smbios_build.h"
> -#include "smbios_ipmi.h"
>
> /* SMBIOS type 38 - IPMI */
> struct smbios_type_38 {
>
Reviewed-by: Laszlo Ersek
ename include/hw/{smbios => firmware}/smbios.h (100%)
(1) Please replace the word "namespace" in the subject, and in the
commit message too, with "subdirectory".
(2) Please replace "firmware" -- both instances -- in the commit message
with "firmware interfac
superfluous already when it was first added in commit
c30e15658b1b ("smbios: implement smbios support for mach-virt", 2015-09-07).
As far as I can tell, anyway.
If you agree, I suggest mentioning commit c30e15658b1b in the commit
message, rather than commit af1f60a4022.
With such an update:
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
fw_cfg_add_i16(uint16_t key, uint32_t value) "key 0x%04" PRIx16 ", value
> 0x%" PRIx32
For the "value" parameter, you should use "uint16_t" here (and replace
PRIx32 with PRIx16, as well).
(In practice this will make no difference, but for consistency's sake,
we should do this.)
With the update:
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
> +fw_cfg_add_i32(uint16_t key, uint32_t value) "key 0x%04" PRIx16 ", value
> 0x%" PRIx32
> +fw_cfg_add_i64(uint16_t key, uint64_t value) "key 0x%04" PRIx16 ", value
> 0x%" PRIx64
>
I can only muster some random thoughts for this one, presently:
On 12/07/18 18:03, Philippe Mathieu-Daudé wrote:
> $ qemu-system-x86_64 -S -monitor stdio
> (qemu) info fw_cfg
> TypePermSizeSpecific Order Info
>signature RO 4 QEMU
>
On 12/07/18 18:04, Philippe Mathieu-Daudé wrote:
> Add a function to read the full content of file on the host, and add
> a new 'file' name item to the fw_cfg device.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/nvram/fw_cfg.c | 22 ++
> include/hw/nvram/fw_cf
On 12/12/18 17:04, Philippe Mathieu-Daudé wrote:
> Cc'ing Laszlo
Thanks.
As noted in the blurb, the edk2 side has been upstream for a while (it
was applied after an extremely long and thorough design discussion). As
long as the QEMU side conforms to the agreed-upon interface, I'm neutral
on the Q
Hi Igor,
On 04/25/19 12:43, Laszlo Ersek wrote:
> Repo: https://github.com/lersek/qemu.git
> Branch:smbios_lp_1821884
> Launchpad: https://bugs.launchpad.net/qemu/+bug/1821884
>
> In
>
> [Qemu-devel] [PATCH for 4.1 v2 09/13]
> tests: acpi: ignore SMBIOS tes
On 05/02/19 16:27, Igor Mammedov wrote:
> On Fri, 26 Apr 2019 19:11:50 +0200
> Laszlo Ersek wrote:
>
>> On 04/25/19 07:34, Igor Mammedov wrote:
>>> adds simple arm/virt test case that starts guest with
>>> bios-tables-test.aarch64.iso.qcow2 boot image whic
1,7 +542,8 @@ static void test_acpi_one(const char *params, test_data
> *data)
> "-net none -display none %s "
> "-drive id=hd0,if=none,file=%s,format=raw "
> "-device ide-hd,drive=hd0 ",
> - data->machine, "kvm:tcg", params ? params : "", disk);
> + data->machine, data->accel ? data->accel : "kvm:tcg",
> + params ? params : "", disk);
> }
>
> data->qts = qtest_init(args);
>
Reviewed-by: Laszlo Ersek
ress_uefi() helper
>
> Signed-off-by: Igor Mammedov
> Reviewed-by: Laszlo Ersek
> Reviewed-by: Philippe Mathieu-Daudé
> Tested-by: Philippe Mathieu-Daudé
> ---
> v4:
> * force test to use TCG accelerator
> v3:
> * use firmware blobs directly from pc-bios directory
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
Tested-by: Ph
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
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
;https://bugs.launchpad.net/qemu/+bug/1821884>:
"Extend uefi-test-tools to report SMBIOS location".
--------
Laszlo Ersek (2):
tests/uefi-test-tools: report the SMBIOS entry point structures
tests/uefi-boot-images: report the SMB
Hi Shameer,
On 05/03/19 15:35, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of
>> Shameerali Kolothum Thodi
>> Sent: 10 April 2019 09:49
>> To: Laszlo Ersek ; qemu-deve
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 0ce84a45ad5..f020102c866 100644
> --- a/ro
@echo " clean -- delete the files generated by the previous" \
> + "build targets"
>
> bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k
> cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin
>
Reviewed-by: Laszlo Ersek
Thanks!
Laszlo
oduced "hw/pflash_cfi01.c".
> header, "It does not support timings". 12 years later, we never
> had to model the device timings. Time to remove the unused timer,
> we can still add it back if required.
>
> Suggested-by: Laszlo Ersek
> Signed-off-by: Philippe Ma
On 05/05/19 22:05, Philippe Mathieu-Daudé wrote:
> The reset() code is used in various places, refactor it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/block/pflash_cfi01.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/hw/block/pflash_c
On 05/05/19 22:05, Philippe Mathieu-Daudé wrote:
> The reset() code is used in various places, refactor it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/block/pflash_cfi01.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
BTW: you didn't add an explicit "C
listed below.
>
> Add the DeviceReset handler and remove its call from the realize()
> function.
>
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1678713
> Reported-by: Laszlo Ersek
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/block/pflash_cfi01.c | 7 ++
On 05/05/19 22:06, Philippe Mathieu-Daudé wrote:
> The reset() code is used in various places, refactor it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/block/pflash_cfi02.c | 25 +++--
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/hw/block/pfl
listed below.
>
> Add the DeviceReset handler and remove its call from the realize()
> function.
>
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1678713
> Reported-by: Laszlo Ersek
- IMO, the above two tags should be dropped from the commit message, as
they are specific
eu-Daudé
> +T: git https://gitlab.com/philmd/qemu.git pflash-next
> +S: Maintained
> +F: hw/block/pflash_cfi*.c
> +F: include/hw/block/flash.h
> +
> SCSI
> M: Paolo Bonzini
> R: Fam Zheng
>
Acked-by: Laszlo Ersek
On 05/06/19 16:19, Philippe Mathieu-Daudé wrote:
> Hi,
>
> Two trivial patches waiting Laszlo's series to land.
... I think you can submit a pullreq with these two patches now --
because I believe that you refer to
[Qemu-devel] [PULL 00/12] bundle edk2 platform firmware with QEMU
above, and t
Hi Markus,
On 05/07/19 20:01, Markus Armbruster wrote:
> The subject is slightly misleading. Holes read as zero. So do
> non-holes full of zeroes. The patch avoids reading the former, but
> still reads the latter.
>
> Xiang Zheng writes:
>
>> Currently we fill the memory space with two 64MB
On 05/08/19 12:15, Shameerali Kolothum Thodi wrote:
> Hi,
>
> This series here[0] attempts to add support for PCDIMM in QEMU for
> ARM/Virt platform and has stumbled upon an issue as it is not clear(at least
> from Qemu/EDK2 point of view) how in physical world the hotpluggable
> memory is handled
On 05/08/19 14:50, Robin Murphy wrote:
> Hi Shameer,
>
> On 08/05/2019 11:15, Shameerali Kolothum Thodi wrote:
>> Hi,
>>
>> This series here[0] attempts to add support for PCDIMM in QEMU for
>> ARM/Virt platform and has stumbled upon an issue as it is not clear(at
>> least
>> from Qemu/EDK2 point
On 05/09/19 18:35, Igor Mammedov wrote:
> On Wed, 8 May 2019 22:26:12 +0200
> Laszlo Ersek wrote:
>
>> On 05/08/19 14:50, Robin Murphy wrote:
>>> Hi Shameer,
>>>
>>> On 08/05/2019 11:15, Shameerali Kolothum Thodi wrote:
>>>> Hi,
>>>&
On 03/01/19 18:39, Igor Mammedov wrote:
> On Fri, 1 Mar 2019 14:49:45 +0100
> Laszlo Ersek wrote:
>
>> On 02/28/19 15:02, Shameerali Kolothum Thodi wrote:
>>
>>> Ah..I missed the fact that, firmware indeed sees an update in the blob len
>>> here
>>&g
On 03/04/19 18:50, Markus Armbruster wrote:
> Alright, we can call object_get_class(dev_obj)->unparent(dev_obj).
>
> Final complication: if I call just that, the device's reference counter
> goes down to zero in the middle of device_unparent(), and we use after
> free. So I bracket he call with
lash_cfi02.c */
>
I generally prefer to keep the same order between declarations of
functions, and definitions of the same functions. Compare
pflash_cfi01_get_memory() here.
With that updated,
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
evice;
> -
> static void pc_isa_bios_init(MemoryRegion *rom_memory,
> MemoryRegion *flash_mem,
> int ram_size)
>
Looks sane, and the commit reference is precise.
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
On 03/04/19 20:48, Philippe Mathieu-Daudé wrote:
> PCMachineState will be used in the next patch.
> Since We can access PCMachineClass from it, directly use it.
> We can also access pcmc->pci_enabled, remove the isapc_ram_fw
> argument.
>
> Signed-off-by: Markus Armbruster
> [PMD: Extracted from
Hi Phil,
On 03/04/19 20:48, Philippe Mathieu-Daudé wrote:
> [PMD: rebased on 'pflash: Fixes and cleanups'
> replaced CFI_PFLASH01 -> PFLASH_CFI01]
[...]
> -#define FLASH_MAP_UNIT_MAX 2
> +static PFlashCFI01 *pc_pflash_create(const char *name)
> +{
> +DeviceState *dev = qdev_create(NUL
rive if=pflash,file=blob,format=raw,readonly for
>> loading your firmware code. To mitigate that we automatically pad in
>> the read-only case and warn the user when we have performed magic to
>> enable things to Just Work (tm).
>>
>> Signed-off-by: Alex Bennée
>&g
Hi,
in order to build any OVMF platform firmware image from the submodule at
"roms/edk2", the (recursive) OpenSSL submodule at
"roms/edk2/CryptoPkg/Library/OpensslLib/openssl" needs to be initialized
as well.
Am I right to think this would be the first recursive submodule in QEMU?
How should I ap
On 03/06/19 13:44, Daniel P. Berrangé wrote:
> On Wed, Mar 06, 2019 at 01:30:06PM +0100, Laszlo Ersek wrote:
>> Hi,
>>
>> in order to build any OVMF platform firmware image from the submodule at
>> "roms/edk2", the (recursive) OpenSSL submodule at
>> &quo
n you move from using -bios to using -drive
>> if=pflash,file=blob,format=raw,readonly for loading your firmware
>> code. To mitigate that we automatically pad in the read-only case and
>> warn the user when we have performed magic to enable things to Just
>> Work (tm).
&g
xtern PCIDevice *piix4_dev;
> int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn);
>
> /* pc_sysfw.c */
> -void pc_system_firmware_init(MemoryRegion *rom_memory,
> - bool isapc_ram_fw);
> +void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory);
>
> /* acpi-build.c */
> void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
>
Reviewed-by: Laszlo Ersek
Thanks!
Laszlo
Signed-off-by: Markus Armbruster
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/i386/pc.c | 2 +
> hw/i386/pc_sysfw.c | 243 ---
> include/hw/i386/pc.h | 3 +
> 3 files changed, 166 insertions(+), 82 deletions(-)
Thanks for addressing my comments!
Acked-by: Laszlo Ersek
Laszlo
On 03/07/19 20:08, Markus Armbruster wrote:
> Eric Blake writes:
>
>> On 3/7/19 11:23 AM, Markus Armbruster wrote:
>>> Signed-off-by: Markus Armbruster
>>>
>>> # Conflicts:
>>> # vl.c
>>
>> How'd you get git to preserve the leading #? Generally, I find conflicts
>> details useful for cherry-pi
On 03/07/19 18:24, Markus Armbruster wrote:
> The previous commit added a way to configure firmware with -blockdev
> rather than -drive if=pflash. Document it as the preferred way.
>
> Signed-off-by: Markus Armbruster
> ---
> docs/interop/firmware.json | 21 +++--
> 1 file chang
"hw/nvram/fw_cfg.h"
> #include "exec/address-spaces.h"
> #include "hw/acpi/piix4.h"
> #include "hw/acpi/pcihp.h"
>
Reviewed-by: Laszlo Ersek
Hi Phil,
most important comment at the bottom.
On 03/08/19 02:32, Philippe Mathieu-Daudé wrote:
> Add two helpers: one to represent a binary data as a string of
> hexadecimal values, and one to restore a such string into its
> original binary data.
>
> Signed-off-by: Philippe Mathieu-Daudé
> --
Hi Phil,
On 03/08/19 02:32, Philippe Mathieu-Daudé wrote:
> Add fw_cfg_arch_key_name() to be able to resolve architecture
> specific keys. All architectures do have specific keys, thus
> implement this function. Architectures that don't use the fw_cfg
> device don't have to implement this function
/* check BMP bpp */
> if (file_type == BMP_FILE) {
> -bmp_bpp = (content[28] + (content[29] << 8)) & 0x;
> +bmp_bpp = lduw_le_p(&content[28]);
> if (bmp_bpp != 24) {
> goto error;
> }
>
Reviewed-by: Laszlo Ersek
his/on its/
With that update:
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
> 'data' argument, but there is no such contract for 'size' (this is
> not a referenced pointer). We can simply remove it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/nvra
On 03/08/19 02:32, Philippe Mathieu-Daudé wrote:
> Each implementation (I/O and MEM) calls fw_cfg_file_slots_allocate()
> then fw_cfg_common_realize().
> Simplify by moving the fw_cfg_file_slots_allocate() call into
> fw_cfg_common_realize() where it belongs.
The patch does more than that, namely:
On 03/08/19 07:55, Thomas Huth wrote:
> On 08/03/2019 02.32, Philippe Mathieu-Daudé wrote:
>> Back in abe147e0ce4 when fw_cfg_add_file() was introduced, there
>> was no QOM design, object where not created and released at runtime.
s/object where/objects were/
>> Later 38f3adc34d finished the QOM
FWCfgState *s = FW_CFG(dev);
>
> g_free(s->files);
> +
> +g_free(s->entries[0]);
> +g_free(s->entries[1]);
> +g_free(s->entry_order);
> }
>
> FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
>
Reviewed-by: Laszlo Ersek
Hi Phil,
On 03/08/19 02:32, Philippe Mathieu-Daudé wrote:
> Due to the contract interface of fw_cfg_add_file(), the
> 'reboot_timeout' data has to be valid for the lifetime of the
> FwCfg object. For this reason it is copied on the heap with
> memdup().
>
> The object state, 'FWCfgState', is also
On 03/08/19 02:32, Philippe Mathieu-Daudé wrote:
> The 'file_data' is allocated by read_splashfile() (introduced in
> commit 3d3b8303c6f8). It is then used by fw_cfg_add_file(). Due
> to the contract interface of fw_cfg_add_file(), it has to be valid
> for the lifetime of the FwCfg object.
>
> Ke
On 03/08/19 02:32, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This series consists of:
> - trivial cleanups, add trace events (was in v1)
> - add QMP/HMP commands to display the list of fw_cfg entries (reworked from
> v1)
> - add unrealize() method and deallocate various buffers (new in v2)
> - add
On 03/08/19 07:24, Markus Armbruster wrote:
> From: Alex Bennée
>
> We reject undersized backends with a rather enigmatic "failed to read
> the initial flash content" error.
>
> We happily accept oversized images, ignoring their tail. Throwing
> away parts of firmware that way is pretty much ce
Hi,
I have a mostly-ready-for-posting patch set for $SUBJECT. My question is
what QEMU release I should be targeting with it.
The Soft Feature Freeze for 4.0 is on 2019-03-12. Here's why that's a
bit inconvenient for me.
The upcoming EDK2 stable release is edk2-stable201903, and it is planned
fo
M_FILE,format=@nvram-template.@format
> +# -machine pflash1=pflash1
> +# or equivalent -blockdev instead of -drive.
> +# With QEMU versions older than 4.0, you have to use
> +# -drive
> if=pflash,unit=1,readonly=off,file=FILENAME_OF_PRIVATE_NVRAM_FILE,format=@nvram-template.@format
> #
> # Since: 3.0
> ##
>
Awesome.
Reviewed-by: Laszlo Ersek
Thanks!
Laszlo
On 03/08/19 14:35, Kevin Wolf wrote:
> Am 08.03.2019 um 13:28 hat Markus Armbruster geschrieben:
>> Laszlo Ersek writes:
>>> This one has got to be one of the longest bike-shedding sessions! :)
>>>
>>> I'm fine with this patch, but I could suggest two imp
On 03/08/19 14:42, Daniel P. Berrangé wrote:
> On Fri, Mar 08, 2019 at 02:09:53PM +0100, Laszlo Ersek wrote:
>> Hi,
>>
>> I have a mostly-ready-for-posting patch set for $SUBJECT. My question is
>> what QEMU release I should be targeting with it.
>>
>> The So
On 03/08/19 16:06, Daniel P. Berrangé wrote:
> On Fri, Mar 08, 2019 at 03:48:07PM +0100, Laszlo Ersek wrote:
>> On 03/08/19 14:42, Daniel P. Berrangé wrote:
>>>> pc-bios/edk2-aarch64-code.fd | Bin 0 -> 67108864 bytes
>>>> pc-bios/edk2-arm-c
On 03/08/19 16:51, Igor Mammedov wrote:
> On Fri, 8 Mar 2019 15:06:12 +
> Daniel P. Berrangé wrote:
>
>> On Fri, Mar 08, 2019 at 03:48:07PM +0100, Laszlo Ersek wrote:
>>> On 03/08/19 14:42, Daniel P. Berrangé wrote:
>>>>> pc-bios/edk2-aarch64-code.f
On 03/08/19 19:07, Philippe Mathieu-Daudé wrote:
> On 3/8/19 6:31 PM, Eric Blake wrote:
>> On 3/8/19 5:08 AM, Philippe Mathieu-Daudé wrote:
>>
> {
> "return": [
> {
> "architecture_specific": false,
> "key": 0,
> "writeable": f
g/archive/html/qemu-devel/2019-03/msg02601.html
Note that the series was formatted with "--no-binary" (affecting patch
#8), therefore it cannot be applied with "git-am". See the remote
repo/branch reference near the top instead.
Thanks,
Laszlo
Laszlo Ersek (10):
roms: lift
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
---
roms/edk2-funcs.sh
core.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
---
tests/uefi-test-tools/build.sh | 3 +++
1 file changed, 3 insertions(+)
d
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
---
roms/edk2-funcs.sh | 14 +--
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
---
pc-bios/descriptors/50-edk2-i386-secure.json | 34 +++
pc-bios/descripto
setools", where an $(EFIROM) pre-requisite would be misleading.
Signed-off-by: Laszlo Ersek
---
roms/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/roms/Makefile b/roms/Makefile
index 78d5dd18c301..2e83ececa25a 100644
--- a/roms/Makefile
+++ b/roms/Makef
rdan Justen (1):
OvmfPkg/build.sh: Enable flash for qemu 3 or later
Julien Grall (1):
Maintainers.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
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
---
roms/edk2-funcs.sh | 25
1 file changed, 25 insertions(+)
diff --git a/roms/edk2-funcs.sh b/roms/edk2-f
Signed-off-by: Laszlo Ersek
---
Makefile | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index d2463c92371f..a29dc5f87a3d 100644
--- a/Makefile
+++ b/Makefile
@@ -714,9 +714,16 @@ spapr-rtas.bin slof.bin skiboot.lid \
palcode-clipper
Add the files built by the last patch: binaries, and the cumulative
license text that covers them.
Signed-off-by: Laszlo Ersek
---
pc-bios/edk2-licenses.txt | 209
pc-bios/edk2-aarch64-code.fd | Bin 0 -> 67108864 bytes
pc-bios/edk2-arm-code
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
---
roms/M
On 06/17/19 12:54, Peter Maydell wrote:
> On Fri, 14 Jun 2019 at 21:25, Laszlo Ersek wrote:
>>
>> The following changes since commit f3d0bec9f80e4ed7796fffa834ba0a53f2094f7f:
>>
>> Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-06-14'
On 06/20/19 14:07, Philippe Mathieu-Daudé wrote:
> Hi Laszlo,
>
> On 3/13/19 11:11 AM, Laszlo Ersek wrote:
>> On 03/13/19 10:43, Laszlo Ersek wrote:
>>> On 03/10/19 01:47, Philippe Mathieu-Daudé wrote:
>>>> The Edk2Crypto object is used to hold config
ime, just
keeping the full context.
Thanks
Laszlo
>
> Can anyone give any advice as to how to proceed? I have a functioning
> patch that adds multiple namespaces, but it uses the "namespaces" array
> method and I don't think that is the right approach.
>
> I
MAINTAINERS | 2 +
> hw/Makefile.objs| 1 +
> hw/firmware/Makefile.objs | 1 +
> hw/firmware/uefi_edk2_crypto_policies.c | 209
> include/hw/firmware/uefi_edk2.h | 30
> 5 files changed, 243
ms->fw_cfg) {
> pc_build_smbios(pcms);
> pc_build_feature_control_file(pcms);
> +pc_uefi_setup(pcms);
> /* update FW_CFG_NB_CPUS to account for -device added CPUs */
> fw_cfg_modify_i16(pcms->fw_cfg, FW_CFG_NB_CPUS, pcms->boot_cpus);
> }
>
Reviewed-by: Laszlo Ersek
>
> virt_acpi_setup(vms);
> virt_build_smbios(vms);
> +virt_uefi_setup(vms);
> }
>
> static uint64_t virt_cpu_mp_affinity(VirtMachineState *vms, int idx)
>
Reviewed-by: Laszlo Ersek
On 06/24/19 16:53, Laszlo Ersek wrote:
> (+Daniel)
>
> On 06/20/19 14:21, Philippe Mathieu-Daudé wrote:
>> $ qemu-system-x86_64 \
>> --object edk2_crypto,id=https,\
>> ciphers=/etc/crypto-policies/back-ends/openssl.config,\
>>
On 06/24/19 12:18, Kevin Wolf wrote:
> Am 24.06.2019 um 10:01 hat Klaus Birkelund geschrieben:
>> On Thu, Jun 20, 2019 at 05:37:24PM +0200, Laszlo Ersek wrote:
>>> On 06/17/19 10:12, Klaus Birkelund wrote:
>>>> Hi all,
>>>>
>>>> I'm th
On 06/28/19 09:23, Gerd Hoffmann wrote:
> We land here in case not everything we've asked for could be mapped.
> So unmap only the bytes which have actually been mapped.
>
> Also we didn't access anything, so acces_len can be 0.
s/acces_len/access_len/
With that:
Rev
Hi Peter,
can you please comment:
On 03/22/19 10:17, Laszlo Ersek wrote:
> On 03/22/19 08:02, Philippe Mathieu-Daudé wrote:
>> Le ven. 22 mars 2019 00:33, Laszlo Ersek a écrit :
>>
>>> On 03/21/19 23:32, Laszlo Ersek wrote:
>>>
>>>> Cool, so let
On 03/22/19 23:00, Paolo Bonzini wrote:
>
>
> - Original Message -
>> From: "Laszlo Ersek"
>> To: "Paolo Bonzini" , qemu-devel@nongnu.org
>> Cc: th...@redhat.com
>> Sent: Thursday, March 21, 2019 8:34:46 PM
>> Subject: Re: [PAT
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 large
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
us
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
_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);
>
gc, char *argv[])
> 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
> pc_system_firmware_init() maps and realizes 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 dri
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
>> ---
501 - 600 of 2115 matches
Mail list logo
