[SeaBIOS] Re: [EXTERNAL] Re: How to change Seabios configuration to disable Legacy Bios and enable UEFI bios

On 03/24/21 18:24, Fatemi (US), Afsheen K wrote: > Thanks for your response, Keith. > > What do I need to do to switch to OVMF BIOS? There is *zero support* for the below, first because the RH-provided "ovmf" SRPM in RHEL7 is Tech Preview in all minor releases of RHEL7 [1], second because in

[SeaBIOS] Re: How to boot from DVD/CD automatically, instead of pressing a key by hand?

On 03/01/21 10:31, Gerd Hoffmann wrote: > On Sun, Feb 28, 2021 at 02:22:53PM -, Yiguang Chen wrote: >> Most time, When a vm with seabios start. The bios will display such info: >> - >> Seabios (version rel-1.13-0 ..) >> Machine UUID ... >> >> IPXE .. >> >> IPXE.. >> >> Booting from

[SeaBIOS] Re: [PATCH 1/3] boot: cache HALT priority

On 01/14/20 10:25, Gerd Hoffmann wrote: > Call find_prio("HALT") only once, on first is_bootprio_strict() call. > Store the result in a variable and reuse it on subsequent calls. > > Signed-off-by: Gerd Hoffmann > --- > src/boot.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) >

[SeaBIOS] Re: strange behavior (regression?) with SeaBIOS + iPXE + WDSNBP.COM

Hi All, On 11/18/19 18:58, Laszlo Ersek wrote: > On 11/16/19 01:59, Michael Brown wrote: >> On 15/11/2019 21:49, Laszlo Ersek wrote: >>> (Right now, my own env is a minimal "mock" setup, with a semi-random >>> WDSNBP.COM binary extracted from a long-term Windo

[SeaBIOS] Re: strange behavior (regression?) with SeaBIOS + iPXE + WDSNBP.COM

On 11/16/19 01:59, Michael Brown wrote: > On 15/11/2019 21:49, Laszlo Ersek wrote: >> (Right now, my own env is a minimal "mock" setup, with a semi-random >> WDSNBP.COM binary extracted from a long-term Windows Server 2012 R2 >> virtual machine of mine. Nothin

[SeaBIOS] Re: strange behavior (regression?) with SeaBIOS + iPXE + WDSNBP.COM

Hello Michael, On 11/15/19 18:03, Michael Brown wrote: > On 15/11/2019 08:45, Laszlo Ersek wrote: >> (1) There is a functional iPXE + WDS setup, with iPXE built as a >> traditional BIOS PCI option ROM, using CONFIG=qemu. Accordingly the >> platform is qemu, with SeaBIOS, and

[SeaBIOS] strange behavior (regression?) with SeaBIOS + iPXE + WDSNBP.COM

Hi Michael & Lists, I'd like to ask for ideas with the following problem we have. (1) There is a functional iPXE + WDS setup, with iPXE built as a traditional BIOS PCI option ROM, using CONFIG=qemu. Accordingly the platform is qemu, with SeaBIOS, and the NIC is virtio-net-pci. I don't know

[SeaBIOS] Re: [PATCH] ahci: zero-initialize port struct

_port_alloc(struct ahci_ctrl_s *ctrl, u32 pnr) > warn_noalloc(); > return NULL; > } > +memset(port, 0, sizeof(*port)); > port->pnr = pnr; > port->ctrl = ctrl; > port->list = memalign_tmp(1024, 1024); > Reviewed-by: Laszlo Ersek _

[SeaBIOS] Re: [PATCH] docs: Add developer-certificate-of-origin

On 10/21/19 17:31, Kevin O'Connor wrote: > Update the documentation to be explicit about the signed-off-by > convention. > > Signed-off-by: Kevin O'Connor > --- > docs/Contributing.md | 5 > docs/developer-certificate-of-origin | 37 > 2 files

[SeaBIOS] Re: [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values

Hi Sam, On 10/16/19 13:02, Sam Eiderman wrote: > Gentle Ping, > > Philippe, John? > > Just wondering if the series is okay, as Gerd pointed out this series > is a blocker for the corresponding changes in SeaBIOS for v 1.13 The QEMU series is still not merged, due to a bug in the last patch

[SeaBIOS] Re: [Qemu-block] [QEMU] [PATCH v5 0/8] Add Qemu to SeaBIOS LCHS interface

hd” and “virtio-pci-blk” so this somehow has something to >>> do with >>> block. >>> >>> This patch also adds fw_cfg interface to send these parameters to SeaBIOS. >>> >>> "scripts/get_maintainer.pl -f hw/nvram/fw_cfg.c” gives >

[SeaBIOS] Re: [Qemu-devel] [QEMU] [PATCH 7/8] bootdevice: FW_CFG interface for LCHS values

On 06/12/19 11:42, Sam Eiderman wrote: > Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS. > > Non-standard logical geometries break under QEMU. > > A virtual disk which contains an operating system which depends on > logical geometries (consistent values being reported

[SeaBIOS] Re: Mailing list update

On 01/21/19 19:19, Kevin O'Connor wrote: > On Mon, Jan 21, 2019 at 07:03:57PM +0100, Laszlo Ersek wrote: >> On 01/20/19 18:07, Kevin O'Connor wrote: >>> On Thu, Jan 10, 2019 at 07:14:14PM +0100, Laszlo Ersek wrote: >>>> https://www.mail-archive.com/seabios@seabio

[SeaBIOS] Re: Mailing list update

On 01/20/19 18:07, Kevin O'Connor wrote: > On Thu, Jan 10, 2019 at 07:14:14PM +0100, Laszlo Ersek wrote: >> https://www.mail-archive.com/seabios@seabios.org/ >> https://www.mail-archive.com/seabios@seabios.org/info.html >> >> So, I'd suggest incorporating these links

[SeaBIOS] Re: Mailing list update

On 01/10/19 12:10, Patrick Georgi wrote: > Hi Kevin, Laszlo, > > 9. Januar 2019 19:38, "Kevin O'Connor" schrieb: >> Patrick, can you confirm that we need to update the above links? > Yes, the links changed because the entire architecture changed. > > I kept pipermail as a read-only copy so old

[SeaBIOS] Re: Mailing list update

On 01/08/19 23:52, Kevin O'Connor wrote: > FYI, the SeaBIOS mailing list backend was recently updated (upgrade to > Mailman3). Service should not be impacted, but if anyone does > experience an issue then please let me know. Indeed, I ran into a problem with this recently. I wanted to reference

Re: [SeaBIOS] [PATCH] optionrom: disallow int19 redirect for pnp roms.

On 11/28/18 19:33, Kevin O'Connor wrote: > On Wed, Nov 28, 2018 at 06:50:50PM +0100, Laszlo Ersek wrote: >> On 11/28/18 16:51, Kevin O'Connor wrote: >>> If we could do it safely that would be fine. My fear is that it >>> introduces a regression. A new

Re: [SeaBIOS] [PATCH] SMBIOS: Add SMBIOS Type 6 Memory Module Information

On 11/28/18 16:54, Liran Alon wrote: > From: Arbel Moshe > > Add support for obsolete SMBIOS Type 6 which describes the speed, type, > size and error status of each system memory module. > > This is required by some guests to boot successfully. > > Such an example is Cisco NGFW appliance which

Re: [SeaBIOS] [PATCH] optionrom: disallow int19 redirect for pnp roms.

On 11/28/18 16:51, Kevin O'Connor wrote: > On Wed, Nov 28, 2018 at 12:14:07PM +0100, Laszlo Ersek wrote: >> Right. Before I raised my short question about *not* short-circuiting >> get_pnp_rom() with "isvga" set, I had read through the BZ, and I was >> *very* tempt

Re: [SeaBIOS] [PATCH] optionrom: disallow int19 redirect for pnp roms.

On 11/28/18 07:24, Gerd Hoffmann wrote: > On Tue, Nov 27, 2018 at 09:19:09PM -0500, Kevin O'Connor wrote: >> On Tue, Nov 27, 2018 at 01:10:38PM +0100, Gerd Hoffmann wrote: >>> Check whenever pnp roms attempt to redirect int19, and in case it does >>> log a message and undo the redirect. >>> >>> A

Re: [SeaBIOS] [PATCH] optionrom: disallow int19 redirect for pnp roms.

On 11/27/18 13:10, Gerd Hoffmann wrote: > Check whenever pnp roms attempt to redirect int19, and in case it does > log a message and undo the redirect. > > A pnp rom should not need this, we have BEVs and BCVs for that. > Nevertheless there are roms in the wild which are redirecting int19. > At

Re: [SeaBIOS] [PATCH] virtio-blk/scsi: enable multi-queues support when starting device

On 09/26/18 10:16, Liu, Changpeng wrote: > I posted the patch again, because I didn't get any response since several > months ago... :). Indeed, you didn't receive any comments under that (July) posting, regrettably:

Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains

On 09/26/18 06:44, Gerd Hoffmann wrote: > Hi, > >> Second, the v5 RFC doesn't actually address the alleged bus number >> shortage. IIUC, it supports a low number of ECAM ranges under 4GB, but >> those are (individually) limited in the bus number ranges they can >> accommodate (due to 32-bit

Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains

On 09/25/18 17:38, Kevin O'Connor wrote: > On Mon, Sep 17, 2018 at 11:02:59PM +0800, Zihan Yang wrote: >> To support multiple pci domains of pxb-pcie device in qemu, we need to setup >> mcfg range in seabios. We use [0x8000, 0xb000) to hold new domain >> mcfg >> table for now, and we need

Re: [SeaBIOS] [PATCH v3 3/3] pci: recognize RH PCI legacy bridge resource reservation capability

!= PCI_VENDOR_ID_REDHAT) { > +dprintf(3, "PCI: This is non-QEMU bridge.\n"); I think I liked the previous language slightly more ("PCI: QEMU resource reserve cap vendor ID doesn't match."), but that shouldn't be a problem. Series Reviewed-by: Laszlo Ersek Thanks

Re: [SeaBIOS] [PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource reservation capability

On 08/24/18 09:48, Liu, Jing2 wrote: > > > On 8/24/2018 3:12 PM, Laszlo Ersek wrote: >> On 08/24/18 04:23, Liu, Jing2 wrote: >>> Hi Laszlo, >>> >>> On 8/22/2018 5:13 PM, Laszlo Ersek wrote: >>>> On 08/16/18 12:43, Liu, Jing2 wrote: >&

Re: [SeaBIOS] [PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource reservation capability

On 08/24/18 04:23, Liu, Jing2 wrote: > Hi Laszlo, > > On 8/22/2018 5:13 PM, Laszlo Ersek wrote: >> On 08/16/18 12:43, Liu, Jing2 wrote: >>> >>> >>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote: >>>>     Hi, >>>> >>>>

Re: [SeaBIOS] [PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource reservation capability

On 08/16/18 12:43, Liu, Jing2 wrote: > > > On 8/16/2018 3:18 PM, Gerd Hoffmann wrote: >>    Hi, >> >>> +    if (pci_config_readw(bdf, PCI_VENDOR_ID) != PCI_VENDOR_ID_REDHAT) { >>> +    dprintf(1, "PCI: QEMU resource reserve cap vendor ID doesn't >>> match.\n"); >> >> I'd suggest to use a

Re: [SeaBIOS] [Qemu-devel] [PATCH v2 0/3] hw/pci: PCI resource reserve capability

Hi, On 08/16/18 11:28, Jing Liu wrote: > This patch serial is about PCI resource reserve capability. > > First patch refactors the resource reserve fields in GenPCIERoorPort > structure out to another new structure, called "PCIResReserve". Modify > the parameter list of

Re: [SeaBIOS] [PATCH v2 0/3] pci: resource reserve capability found

On 08/13/18 09:49, Jing Liu wrote: > This patch serial is about QEMU resource reserve capability finding > in firmware. > > Firstly, this fixes a logic bug. When the capability is truncated, > return zero instead of the truncated offset. Secondly, this modified > the debug messages when the

Re: [SeaBIOS] Marvell 88SE9230 passthrough in KVM takes long time to boot

+Andrea; comments below On 08/08/18 23:11, Alex Williamson wrote: > On Wed, 8 Aug 2018 14:11:16 +0200 > Gerd Hoffmann wrote: > >> On Sun, Jul 29, 2018 at 01:49:10PM +0200, Konrad Eisele wrote: >>> I'm passing through a Marvell 88SE9230 card to a KVM guest under >>> Ubuntu 18.04. The card is a

Re: [SeaBIOS] [PATCH] pci: add RedHat PCI BRIDGE capability

On 08/08/18 05:24, Liu, Jing2 wrote: > On 8/7/2018 7:43 PM, Laszlo Ersek wrote: >> On 08/07/18 09:20, Jing Liu wrote: [snip] >>> -    if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT && >>> -   

Re: [SeaBIOS] [PATCH] pci: add RedHat PCI BRIDGE capability

adding Marcel; comments at the bottom On 08/07/18 09:20, Jing Liu wrote: > Add a device-specific capability for the RedHat PCI BRIDGE > to enable reserving additional resources. > > Signed-off-by: Jing Liu > --- > src/fw/pciinit.c | 9 ++--- > src/hw/pci_ids.h | 1 + > 2 files changed, 7

Re: [SeaBIOS] Marvell 88SE9230 passthrough in KVM takes long time to boot

side comment: On 07/29/18 21:43, Konrad Eisele wrote: > changed /usr/bin/kvm (which > libvirtd is calling at boot) > qemu-system-x86_64 -enable-kvm -bios /usr/lib/qemu/bios.bin "$@" This should not be necessary. Libvirt lets you specify the desired firmware in the domain XML:

Re: [SeaBIOS] hotplug failure issue on pci-bridge

On 07/16/18 11:45, Liu, Jing2 wrote: > Hi Laszlo, > > On 7/12/2018 3:29 PM, Laszlo Ersek wrote: >> On 07/12/18 07:43, Liu, Jing2 wrote: >>> Yep, thanks for the advice. >>> But hotplugging on pci-bridge is the actual use case >>> request so we would better

Re: [SeaBIOS] hotplug failure issue on pci-bridge

ot-plugged into the root port, for which bus number reservation is necessary too, at the root port level.) If you want more than that, e.g. do something similar on i440fx, that will take QEMU work as well, not just SeaBIOS. Laszlo > > On 7/11/2018 6:38 PM, Laszlo Ersek wrote: >> On

Re: [SeaBIOS] hotplug failure issue on pci-bridge

On 07/11/18 05:12, Liu, Jing2 wrote: > Hi, > > Recently, we tried some hotplug issues. The case is: when hotplug a > device (e.g. iGPU) onto pci-bridge after guest booting up, guest reports > "BAR 2: no space for [mem size 0x4000 64bit pref]" etc. > > Seabios checks all the devices under the

Re: [SeaBIOS] 1TB Guest changes to receive phys bits >=40

On 06/11/18 15:52, Gerd Hoffmann wrote: > Hi, > >> The change [2] itself is rather old, so I wondered if I'm missing >> that this was implemented in a totally different way. Do I have to >> switch/set options these days instead of using that patch? > > It should just work. qemu passes ram

Re: [SeaBIOS] Confirm the status about BZ#1377575

Hello Shouta-san, On 02/14/18 05:48, shouta.ueh...@jp.yokogawa.com wrote: > Dear SeaBIOS development members, > > I'm Shota Uehara work for Yokogawa Electric Corporation. > I would like to confirm the status about a bug fixing of BZ#1377575. > > I use Windows Server 2016 virtual machine on

Re: [SeaBIOS] Saving a few bytes across a reboot

On 02/07/18 17:44, Stefan Berger wrote: > On 02/07/2018 10:50 AM, Laszlo Ersek wrote: >> OK, but if the OS is allowed to modify this set of "queued operations", >> then what protection is expected of SMM? Whether you can modify the TPM >> directly, or queue r

Re: [SeaBIOS] Saving a few bytes across a reboot

On 02/07/18 15:57, Stefan Berger wrote: > On 02/07/2018 09:18 AM, Laszlo Ersek wrote: >> On 02/07/18 14:51, Stefan Berger wrote: >>> To support SeaBIOS as well, we would have to be >>> able to distinguish a BIOS from the UEFI on the QEMU level so that we >>>

Re: [SeaBIOS] [PATCH v2 2/3] tcgbios: Add TPM Physical Presence interface support

On 01/16/18 19:36, Kevin O'Connor wrote: > On Tue, Jan 16, 2018 at 11:41:02AM -0500, Stefan Berger wrote: >> Add support for TPM 1.2 and TPM 2 Physical Presence interface (PPI). >> A shared memory structure is located at 0xfffe f000 - 0xfffe f3ff >> that SeaBIOS initializes (unless it has already

Re: [SeaBIOS] Saving a few bytes across a reboot

On 01/11/18 18:16, Stefan Berger wrote: > I can only point to the standard for the address. If QEMU has an API > where we can first try to allocate fed4 and if that fails ask for > another address, then we can use that. But does driver initialization > work that way that we can first let all

Re: [SeaBIOS] Saving a few bytes across a reboot

(I'm not trying to further argue for the idea below, just to clarify it:) On 01/11/18 15:29, Stefan Berger wrote: > On 01/11/2018 09:02 AM, Laszlo Ersek wrote: >> On 01/11/18 13:40, Igor Mammedov wrote: >>> On Wed, 10 Jan 2018 17:45:52 +0100 >>> Laszlo Ersek <ler.

Re: [SeaBIOS] Saving a few bytes across a reboot

On 01/11/18 13:40, Igor Mammedov wrote: > On Wed, 10 Jan 2018 17:45:52 +0100 > Laszlo Ersek <ler...@redhat.com> wrote: >> (My understanding is that the guest has to populate the CRB, and then >> kick the hypervisor, so at least the register used for kicking must be

Re: [SeaBIOS] Saving a few bytes across a reboot

On 01/10/18 19:45, Stefan Berger wrote: > On 01/10/2018 11:45 AM, Laszlo Ersek wrote: >> On 01/10/18 16:19, Marc-André Lureau wrote: >>> Hi >>> >>> - Original Message - >>>> BTW, from the "TCG PC Client Platform TPM Profile (PTP) >&g

Re: [SeaBIOS] Saving a few bytes across a reboot

On 01/10/18 16:19, Marc-André Lureau wrote: > Hi > > - Original Message - >> >> BTW, from the "TCG PC Client Platform TPM Profile (PTP) >> Specification", it seems like the FIFO (TIS) interface is hard-coded >> *in the spec* at FED4_h  FED4_4FFFh. So we don't even have >> to make that

Re: [SeaBIOS] Saving a few bytes across a reboot

Stefan, On 01/09/18 20:02, Stefan Berger wrote: > Another twist is that Intel's EDK2 also implements this but the data > structure layout is different and they use SMM + SMIs etc. > > https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl#L81 As I described in my

Re: [SeaBIOS] [PATCH RFC] x86: use volatile asm for read/write{b, w, l} implementations

On 01/04/18 15:29, Vitaly Kuznetsov wrote: > Laszlo Ersek <ler...@redhat.com> writes: > In fact, the only writew() needs patching is in vp_notify(), when I > replace it with 'asm volatile' everything works. > >> * Does it make a difference if you disable EPT in the L1 KV

Re: [SeaBIOS] [PATCH RFC] x86: use volatile asm for read/write{b, w, l} implementations

On 01/04/18 11:24, Vitaly Kuznetsov wrote: > Laszlo Ersek <ler...@redhat.com> writes: > >> Is it possible that the current barrier() is not sufficient for the >> intended purpose in an L2 guest? >> >> What happens if you drop your current patch, but

Re: [SeaBIOS] [PATCH RFC] x86: use volatile asm for read/write{b, w, l} implementations

On 01/03/18 14:41, Vitaly Kuznetsov wrote: > QEMU/KVM guests running nested on top of Hyper-V fail to boot with > virtio-blk-pci disks, the debug log ends with > > Booting from Hard Disk... > call32_smm 0x000edd01 e97a0 > handle_smi cmd=b5 smbase=0x000a > vp notify fe007000 (2) -- 0x0 > vp

Re: [SeaBIOS] [Qemu-devel] [PATCH v5 4/4] docs: update documentation considering PCIE-PCI bridge

t -- in the critical section being protected by the mutex, there can be Thread 1, Thread 2, or none of them.) So, beyond dropping the last sentence, I suggest to replace the one marked with [*] with the following, for clarity: At most one of the following tw

Re: [SeaBIOS] [Qemu-devel] [PATCH v4 5/5] docs: update documentation considering PCIE-PCI bridge

On 08/09/17 18:52, Aleksandr Bezzubikov wrote: > 2017-08-09 13:18 GMT+03:00 Laszlo Ersek <ler...@redhat.com>: >> On 08/08/17 21:21, Aleksandr Bezzubikov wrote: >>> 2017-08-08 18:11 GMT+03:00 Laszlo Ersek <ler...@redhat.com>: >>>> one comment below >>

Re: [SeaBIOS] [Qemu-devel] [PATCH v4 5/5] docs: update documentation considering PCIE-PCI bridge

On 08/08/17 21:21, Aleksandr Bezzubikov wrote: > 2017-08-08 18:11 GMT+03:00 Laszlo Ersek <ler...@redhat.com>: >> one comment below >> >> On 08/05/17 22:27, Aleksandr Bezzubikov wrote: >> >>> +Capability layout (defined in include/hw/pci/pci_bridge.h): &

Re: [SeaBIOS] [Qemu-devel] [PATCH v4 5/5] docs: update documentation considering PCIE-PCI bridge

one comment below On 08/05/17 22:27, Aleksandr Bezzubikov wrote: > +Capability layout (defined in include/hw/pci/pci_bridge.h): > + > +uint8_t id; Standard PCI capability header field > +uint8_t next; Standard PCI capability header field > +uint8_t len;Standard PCI

Re: [SeaBIOS] [PATCH v3 2/3] pci: add QEMU-specific PCI capability structure

On 08/04/17 20:59, Alexander Bezzubikov wrote: > 2017-08-01 20:28 GMT+03:00 Alexander Bezzubikov : >> 2017-08-01 16:38 GMT+03:00 Marcel Apfelbaum : >>> On 31/07/2017 22:01, Alexander Bezzubikov wrote: 2017-07-31 21:57 GMT+03:00 Michael S. Tsirkin

Re: [SeaBIOS] [Qemu-devel] [PATCH v3 5/5] docs: update documentation considering PCIE-PCI bridge

On 08/02/17 15:47, Michael S. Tsirkin wrote: > On Wed, Aug 02, 2017 at 12:23:46AM +0200, Laszlo Ersek wrote: >> On 08/01/17 23:39, Michael S. Tsirkin wrote: >>> On Wed, Aug 02, 2017 at 12:33:12AM +0300, Alexander Bezzubikov wrote: >>>> 2017-08-01 23:31 GMT+03:00 L

Re: [SeaBIOS] [Qemu-devel] [PATCH v3 5/5] docs: update documentation considering PCIE-PCI bridge

On 08/01/17 23:39, Michael S. Tsirkin wrote: > On Wed, Aug 02, 2017 at 12:33:12AM +0300, Alexander Bezzubikov wrote: >> 2017-08-01 23:31 GMT+03:00 Laszlo Ersek <ler...@redhat.com>: >>> (Whenever my comments conflict with Michael's or Marcel's, I defer to them.) >>>

Re: [SeaBIOS] [Qemu-devel] [PATCH v3 5/5] docs: update documentation considering PCIE-PCI bridge

(Whenever my comments conflict with Michael's or Marcel's, I defer to them.) On 07/29/17 01:37, Aleksandr Bezzubikov wrote: > Signed-off-by: Aleksandr Bezzubikov > --- > docs/pcie.txt| 46 ++ > docs/pcie_pci_bridge.txt | 121 >

Re: [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware

On 07/31/17 20:55, Michael S. Tsirkin wrote: > On Mon, Jul 31, 2017 at 08:16:49PM +0200, Laszlo Ersek wrote: >> OK. If the proposed solution with the r/o mem base/limit registers is >> rooted in the spec (and I think it indeed must be; apparently this would >> be the same

Re: [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware

On 07/29/17 01:15, Michael S. Tsirkin wrote: > On Thu, Jul 27, 2017 at 03:58:58PM +0200, Laszlo Ersek wrote: >> On 07/27/17 11:39, Marcel Apfelbaum wrote: >>> On 27/07/2017 2:28, Michael S. Tsirkin wrote: >>>> On Thu, Jul 27, 2017 at 12:54:07AM +0300, Alexander Bezz

Re: [SeaBIOS] [qemu PATCH for 2.10] i386: acpi: provide an XSDT instead of an RSDT

On 07/27/17 22:40, Kevin O'Connor wrote: > On Wed, Jul 26, 2017 at 11:31:36AM +0200, Paolo Bonzini wrote: >> The tables that QEMU provides are not ACPI 1.0 compatible since commit >> 77af8a2b95 ("hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve >> guest OS support.", 2017-05-03). This

Re: [SeaBIOS] [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support

On 07/27/17 16:59, Kevin O'Connor wrote: > On Wed, Jul 26, 2017 at 04:21:23PM -0400, Paolo Bonzini wrote: >>> C - We'd be introducing "shared ownership" of the acpi tables. Some >>> of the tables would be produced by QEMU and some of them by >>> SeaBIOS. Explaining when and why to

Re: [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware

On 07/27/17 11:39, Marcel Apfelbaum wrote: > On 27/07/2017 2:28, Michael S. Tsirkin wrote: >> On Thu, Jul 27, 2017 at 12:54:07AM +0300, Alexander Bezzubikov wrote: >>> 2017-07-26 22:43 GMT+03:00 Michael S. Tsirkin : On Sun, Jul 23, 2017 at 01:15:41AM +0300, Aleksandr

Re: [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware

On 07/26/17 23:54, Alexander Bezzubikov wrote: > 2017-07-26 22:43 GMT+03:00 Michael S. Tsirkin : >> On Sun, Jul 23, 2017 at 01:15:41AM +0300, Aleksandr Bezzubikov wrote: >>> +PCIBridgeQemuCap cap; >> >> This leaks info to guest. You want to init all fields here: >> >> cap = {

Re: [SeaBIOS] [RFC PATCH v2 0/4] Allow RedHat PCI bridges reserve more buses than necessary during init

On 07/26/17 18:22, Marcel Apfelbaum wrote: > On 26/07/2017 18:20, Laszlo Ersek wrote: [snip] >> However, what does the hot-pluggability of the PCIe-PCI bridge buy us? >> In other words, what does it buy us when we do not add the PCIe-PCI >> bridge immediately at guest star

Re: [SeaBIOS] [RFC PATCH v2 0/4] Allow RedHat PCI bridges reserve more buses than necessary during init

On 07/26/17 08:48, Marcel Apfelbaum wrote: > On 25/07/2017 18:46, Laszlo Ersek wrote: [snip] >> (2) Bus range reservation, and hotplugging bridges. What's the >> motivation? Our recommendations in "docs/pcie.txt" suggest flat >> hierarchies. >> > > It

Re: [SeaBIOS] [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support

Digressing: On 07/26/17 10:53, Paolo Bonzini wrote: > On 25/07/2017 23:25, Phil Dennis-Jordan wrote: >> Thanks for this, Paolo. Very interesting idea. >> >> I couldn't get things working initially, but with a few fixups on the >> SeaBIOS side I can boot both legacy and modern OSes. See comments

Re: [SeaBIOS] [RFC PATCH v2 0/4] Allow RedHat PCI bridges reserve more buses than necessary during init

On 07/23/17 00:11, Aleksandr Bezzubikov wrote: > Now PCI bridges get a bus range number on a system init, basing on > currently plugged devices. That's why when one wants to hotplug > another bridge, it needs his child bus, which the parent is unable to > provide (speaking about virtual device).

Re: [SeaBIOS] allocation zone extensions for the firmware linker/loader

On 06/05/17 18:02, Michael S. Tsirkin wrote: > On Sat, Jun 03, 2017 at 09:36:23AM +0200, Laszlo Ersek wrote: >> On 06/02/17 17:45, Laszlo Ersek wrote: >> >>> The patches can cause linker/loader breakage when old firmware is booted >>> on new QEMU. However, th

Re: [SeaBIOS] allocation zone extensions for the firmware linker/loader

On 06/02/17 17:45, Laszlo Ersek wrote: > The patches can cause linker/loader breakage when old firmware is booted > on new QEMU. However, that's no problem (it's nothing new), the next > release of QEMU should bundle the new firmware binaries as always. Dave made a good point (which

Re: [SeaBIOS] allocation zone extensions for the firmware linker/loader

On 06/02/17 18:30, Michael S. Tsirkin wrote: > On Fri, Jun 02, 2017 at 05:45:21PM +0200, Laszlo Ersek wrote: >> Hi, >> >> this message is cross-posted to three lists (qemu, seabios, edk2). I'll >> follow up with three patch series, one series for each project. I'll >&

[SeaBIOS] [edk2 PATCH 2/3] OvmfPkg/AcpiPlatformDxe: support NOACPI content hint in ALLOCATE command

nnon Zhao <zhaoshengl...@huawei.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- OvmfPkg/AcpiPlatformDxe/QemuLoader.h| 9 +- OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 29 +++- 2 files changed, 36 ins

[SeaBIOS] [edk2 PATCH 0/3] OvmfPkg/AcpiPlatformDxe: NOACPI hint and 64-bit zone in fw_cfg blob alloc

lindh...@linaro.org> Cc: Shannon Zhao <zhaoshengl...@huawei.com> Thanks Laszlo Laszlo Ersek (3): OvmfPkg/AcpiPlatformDxe: rename BLOB.HostsOnlyTableData to BLOB.Releasable OvmfPkg/AcpiPlatformDxe: support NOACPI content hint in ALLOCATE command OvmfPkg/AcpiPlatformDxe: suppor

[SeaBIOS] [edk2 PATCH 3/3] OvmfPkg/AcpiPlatformDxe: support 64-bit zone in ALLOCATE command

;zhaoshengl...@huawei.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- OvmfPkg/AcpiPlatformDxe/QemuLoader.h| 3 ++- OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a

[SeaBIOS] [edk2 PATCH 1/3] OvmfPkg/AcpiPlatformDxe: rename BLOB.HostsOnlyTableData to BLOB.Releasable

c: Ben Warren <b...@skyportsystems.com> Cc: Dongjiu Geng <gengdong...@huawei.com> Cc: Igor Mammedov <imamm...@redhat.com> Cc: Jordan Justen <jordan.l.jus...@intel.com> Cc: Leif Lindholm <leif.lindh...@linaro.org> Cc: Shannon Zhao <zhaoshengl...@huawei.com> Contributed-un

[SeaBIOS] [seabios PATCH 2/2] romfile_loader: alloc: cope with the UEFI-oriented 64BIT zone hint

Zhao <zhaoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangrong <guangrong.x...@linux.intel.com> Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- src/fw/romfile_loader.h | 7 --- src/fw/romfile_loader.c | 1 + 2 files changed

[SeaBIOS] [seabios PATCH 0/2] romfile_loader: cope with the UEFI-oriented allocation extensions

net.ibm.com> Cc: Xiao Guangrong <guangrong.x...@linux.intel.com> Thanks Laszlo Laszlo Ersek (2): romfile_loader: alloc: cope with the UEFI-oriented NOACPI content hint romfile_loader: alloc: cope with the UEFI-oriented 64BIT zone hint src/fw/romfile_loader.h | 14 +++

[SeaBIOS] [seabios PATCH 1/2] romfile_loader: alloc: cope with the UEFI-oriented NOACPI content hint

<imamm...@redhat.com> Cc: Shannon Zhao <zhaoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangrong <guangrong.x...@linux.intel.com> Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- src/fw/romfile_loader.h | 7 +++ src/fw/rom

[SeaBIOS] [qemu PATCH 5/7] hw/acpi/vmgenid: ask the fw to alloc VMGENID_GUID_FW_CFG_FILE as NOACPI

..@huawei.com> Cc: Igor Mammedov <imamm...@redhat.com> Cc: Shannon Zhao <zhaoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangrong <guangrong.x...@linux.intel.com> Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- Notes: I tested

[SeaBIOS] [qemu PATCH 6/7] hw/i386/acpi-build: ask the fw to alloc ACPI_BUILD_TPMLOG_FILE with 64bit/NOACPI

aoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangrong <guangrong.x...@linux.intel.com> Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- Notes: I don't know how to test this device, so I didn't. Help from the device's maintainer woul

[SeaBIOS] [qemu PATCH 4/7] hw/acpi/nvdimm: ask the firmware to allocate NVDIMM_DSM_MEM_FILE as NOACPI

<ard.biesheu...@linaro.org> Cc: Ben Warren <b...@skyportsystems.com> Cc: Dongjiu Geng <gengdong...@huawei.com> Cc: Igor Mammedov <imamm...@redhat.com> Cc: Shannon Zhao <zhaoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangro

[SeaBIOS] [qemu PATCH 0/7] bios-linker-loader: introduce the NOACPI hint and the 64-bit zone for ALLOCATE

...@linaro.org> Cc: Ben Warren <b...@skyportsystems.com> Cc: Dongjiu Geng <gengdong...@huawei.com> Cc: Igor Mammedov <imamm...@redhat.com> Cc: Shannon Zhao <zhaoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangrong <guangrong.x...@lin

[SeaBIOS] [qemu PATCH 1/7] hw/acpi/bios-linker-loader: expose allocation zone as an enum

dhat.com> Cc: Shannon Zhao <zhaoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangrong <guangrong.x...@linux.intel.com> Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- include/hw/acpi/bios-linker-loader.h | 10 +- hw/acpi/bios-linke

[SeaBIOS] [qemu PATCH 2/7] hw/acpi/bios-linker-loader: introduce "no ACPI tables" content hint for ALLOC

hao <zhaoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangrong <guangrong.x...@linux.intel.com> Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- include/hw/acpi/bios-linker-loader.h | 11 ++- hw/acpi/bios-linker-loader.c

[SeaBIOS] [qemu PATCH 7/7] hw/arm/virt-acpi-build: make the fw alloc blobs with ACPI tables as 64bit

Igor Mammedov <imamm...@redhat.com> Cc: Shannon Zhao <zhaoshengl...@huawei.com> Cc: Stefan Berger <stef...@linux.vnet.ibm.com> Cc: Xiao Guangrong <guangrong.x...@linux.intel.com> Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- Notes: I verified this change wit

[SeaBIOS] allocation zone extensions for the firmware linker/loader

Hi, this message is cross-posted to three lists (qemu, seabios, edk2). I'll follow up with three patch series, one series for each project. I'll cross-post all of the patches as well, but I'll add the project name in the "bag of tags" in the subject lines. The QEMU series introduces two

Re: [SeaBIOS] [PATCH v3] config: Add function to check if fw_cfg exists

virt.h > index 16f3d9a..a14d83e 100644 > --- a/src/fw/paravirt.h > +++ b/src/fw/paravirt.h > @@ -49,6 +49,7 @@ static inline int runningOnKVM(void) { > // QEMU_CFG_DMA ID bit > #define QEMU_CFG_VERSION_DMA2 > > +int qemu_cfg_enabled(void); > int qemu_cfg_dma_ena

Re: [SeaBIOS] [PATCH v2] config: Add function to check if fw_cfg exists

@ void qemu_cfg_init(void) > if (inb(PORT_QEMU_CFG_DATA) != sig[i]) > return; > > +cfg_enabled = 1; > dprintf(1, "Found QEMU fw_cfg\n"); > > // Detect DMA interface. If we wanted to parallel the DMA check 100%, we'd set th

Re: [SeaBIOS] [PATCH] config: Add function to check if fw_cfg exists

On 03/14/17 21:33, petr.be...@email.cz wrote: > From 405de6e571a2bf332452a17ae98f7b3a0613365e Mon Sep 17 00:00:00 2001 > From: Petr Berky > Date: Tue, 14 Mar 2017 20:30:52 +0100 > Subject: [PATCH] config: Add function to check if fw_cfg exists > > It was found

Re: [SeaBIOS] [PATCH 0/9] add support for generic lun enumeration

On 03/02/17 20:48, Roman Kagan wrote: > On Thu, Mar 02, 2017 at 06:20:29PM +0100, Laszlo Ersek wrote: >> On 03/01/17 11:45, Roman Kagan wrote: >>> A number of SCSI drivers currently only see luns #0 in their targets. >>> >>> This may be a problem when d

Re: [SeaBIOS] [PATCH 0/9] add support for generic lun enumeration

On 03/01/17 11:45, Roman Kagan wrote: > A number of SCSI drivers currently only see luns #0 in their targets. > > This may be a problem when drives have to be assigned bigger lun > numbers, e.g. because the storage controllers don't provide enough > target numbers to accomodate all drives. > (In

Re: [SeaBIOS] [PATCH v7 4/5] QEMU fw_cfg: Add functions for accessing files by key

le using the key as a reference. > > Signed-off-by: Ben Warren <b...@skyportsystems.com> > Reviewed-by: Igor Mammedov <imamm...@redhat.com> > Reviewed-by: Laszlo Ersek <ler...@redhat.com> > --- > src/fw/paravirt.c | 41 ++--- &g

Re: [SeaBIOS] [PATCH v6 5/5] QEMU fw_cfg: Write fw_cfg back on S3 resume

t_romfile_key(), i.e., to verify file->copy, that function can still fail. ... But, by the time we get here, we've already used the selector key implicitly in the call to qemu_cfg_write_file(). And, qemu_cfg_write_file() does the file->copy check, returns errors appropriately, and we do check its ret

Re: [SeaBIOS] [PATCH v6 4/5] QEMU fw_cfg: Add functions for accessing files by key

I mentioned here was to move not just the second branch of the "if" to qemu_cfg_write_file_simple(), but the entire "if" -- both branches. Because, qemu_cfg_write_entry() looks suitable for S3 too, and if that kind of optimization makes sense for normal boot, then it makes sense for S3 resu

Re: [SeaBIOS] [PATCH v5 5/5] QEMU fw_cfg: Write fw_cfg back on S3 resume

On 02/18/17 07:21, b...@skyportsystems.com wrote: > From: Ben Warren > > Any pointers to BIOS-allocated memory that were written back to QEMU > fw_cfg files are replayed when resuming from S3 sleep. > > Signed-off-by: Ben Warren > --- >

Re: [SeaBIOS] [PATCH v5 4/5] QEMU fw_cfg: Add functions for accessing files by key

On 02/18/17 07:21, b...@skyportsystems.com wrote: > From: Ben Warren > > When resuming from S3, only fw_cfg file keys are known. > > Signed-off-by: Ben Warren > --- > src/fw/paravirt.c | 23 +++ > src/fw/paravirt.h | 2 ++

Re: [SeaBIOS] [PATCH v5 3/5] QEMU fw_cfg: Add command to write back address of file

<b...@skyportsystems.com> > --- > src/fw/romfile_loader.c | 45 + > src/fw/romfile_loader.h | 23 --- > 2 files changed, 65 insertions(+), 3 deletions(-) Reviewed-by: Laszlo Ersek <ler...@redhat.com> Thanks Laszlo

Re: [SeaBIOS] [PATCH v5 1/5] QEMU DMA: Add DMA write capability

<b...@skyportsystems.com> > --- > src/fw/paravirt.c | 49 + > src/fw/paravirt.h | 3 +++ > 2 files changed, 52 insertions(+) Reviewed-by: Laszlo Ersek <ler...@redhat.com> Thanks Laszlo > diff --git a/src/fw/paravirt.c

Re: [SeaBIOS] varlow/extrastack vs code

On 02/17/17 14:10, Paolo Bonzini wrote: > > > On 15/02/2017 16:52, Kevin O'Connor wrote: >> On Wed, Feb 15, 2017 at 11:01:03AM +0100, Laszlo Ersek wrote: >>> On 02/14/17 20:14, Kevin O'Connor wrote: >>>> On Tue, Feb 14, 2017 at 07:52:01PM +0100, Laszlo Ers

  1   2   3   >