SeaBIOS June 2013

seabios@seabios.org

22 participants
54 discussions

Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support

by Anthony Liguori

Hi Jordan, On Mon, Jun 10, 2013 at 7:28 PM, Jordan Justen <jljusten(a)gmail.com> wrote: > On Mon, Jun 10, 2013 at 2:45 PM, Anthony Liguori <anthony(a)codemonkey.ws> wrote: >> OVMF is proprietary. > > I don't agree that not-OSI means proprietary. I call it blue if that makes you all feel better :-) But no matter what the word we use it, the point still stands, we need a UEFI firmware that has a OSI-approved license. Forgetting everything else, the distros can't ship OVMF in its current form. > I agree that the FAT driver is not 'free software' and I agree that is > a problem for usage with free software projects, such as QEMU. This is > a big deal, but unfortunately, as an Intel employee, I think I've done > as much as I can to address this. > > It couldn't hurt if more people that actually care about this spoke up > on edk2-devel about the issue, or perhaps within a UEFI working group. > Because, I know that they've stopped listening to me about it. Is this useful? I can try to make noise. I assume since folks like you who have much more credibility and familiarity in this space have given up, it's a lost cause. >> It is not "supported" by QEMU. > > No, but I've always thought that QEMU was happy to have alternative > firmware projects. We are and we're happy to accept patches to enable things even if its proprietary. But that's all assuming we're improving hardware emulation. What we're talking about here is doing something that's very un-hardware like. >> I'm not really convinced that >> QEMU<->firmware is a GPL boundary because of how tightly the two are >> linked. > > Where has 'linked' in terms of the GPL ever been anything other than > actual executable linking? I should not have even brought this up as it's not worth debating. If you're curious, http://www.gnu.org/licenses/gpl-faq.html#MereAggregation >> Moving large chunks of firmware code into QEMU just to avoid solving >> licensing issues is a non-starter with me. > > Is this a licensing issue? I thought this was a "let's save time by > doing it in one place" thing. I'm pretty ambivalent about this > feature, really. I don't think it is even worth all this bickering. > > I'm certain OVMF has ACPI issues on QEMU, but I don't think it is a > huge deal to resolve them independently of this feature. Doing it one place could just mean share code. Code can't be shared today, that's why licensing has come up. Regards, Anthony Liguori > I was not a huge fan of supporting this type of thing for Xen in OVMF, > but it does seem to work fine. > > -Jordan

8 years, 3 months

Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support

by Anthony Liguori

Peter Maydell <peter.maydell(a)linaro.org> writes: > On 10 June 2013 19:58, Anthony Liguori <anthony(a)codemonkey.ws> wrote: >> We only care about supporting one version of SeaBIOS. SeaBIOS should >> only care about supporting one version of QEMU. We're not asking it to >> support multiple versions. > > I'm confused, how does this work in cross-version migration? > The BIOS is part of the guest, so I'd expect QEMU would > have to support whatever it happens to be. (Plus how do > you enforce the version-dependency?) The BIOS is migrated but reset upon reboot. Regards, Anthony Liguori > > thanks > -- PMM

8 years, 3 months

[PATCH 0/8] Introduce list.h abstraction

by Kevin O'Connor

This series implements a doubly linked list (hlist) abstraction and adds helper code for manipulating these lists. Common users of linked lists in the code are then converted to use these abstractions. -Kevin Kevin O'Connor (8): Minor - move "tracked memory alloc" code in pmm.c. Introduce and convert pmm code to use standard list helpers. Minor - relocate code in stacks.c to keep low-level thread code together. Introduce helper function have_threads() in stacks.c. Convert stacks.c to use standard list manipulation code. Convert boot.c to use standard list manipulation code. Convert pciinit.c to use standard list manipulation code. Convert PCIDevices list to use standard list manipultion code. src/ata.c | 2 +- src/boot.c | 37 ++++---- src/list.h | 76 +++++++++++++++++ src/mptable.c | 2 +- src/pci.c | 7 +- src/pci.h | 9 +- src/pciinit.c | 64 +++++++------- src/pmm.c | 265 ++++++++++++++++++++++++++------------------------------- src/stacks.c | 149 ++++++++++++++++---------------- src/types.h | 3 + src/usb-ehci.c | 2 +- src/usb.c | 8 +- 12 files changed, 341 insertions(+), 283 deletions(-) create mode 100644 src/list.h -- 1.7.11.7

8 years, 3 months

Re: [SeaBIOS] Running privilege code on hidden O.S.

by Fred .

Sounds like a rootkit. On Thu, Jun 6, 2013 at 9:35 PM, Jerry Backer <bataille16(a)gmail.com> wrote: > Hi, > > The idea is to run some security and packet inspection codes on the hidden > core. > There is a typo on the title, it should be 'Running privilege code on > hidden core'. > > Thanks, > > > On Thu, Jun 6, 2013 at 3:04 PM, Fred . <eldmannen(a)gmail.com> wrote: > >> I am curious as to why you would want to do such a thing... >> >> >> On Thu, Jun 6, 2013 at 6:52 PM, Jerry Backer <bataille16(a)gmail.com>wrote: >> >>> Hello, >>> >>> I am using seaBIOS with QEMU and am attempting to hide a processor core >>> (on an smp system) from the O.S. and then load a dedicated code on that >>> core before boot. I have managed to hide one of the cores by decreasing >>> CountCPUs (within smp.c) after running the ap core code, hence the BIOS >>> load info for 1 less core on the mp table. >>> >>> However, I have not been able to figure out how to load the privileged >>> code. My intuition was to load it when the hidden core enters protected >>> mode before running kernel code. But I don't see where in the code the >>> cores go into protected mode during boot. >>> >>> Can anyone give me some insight on how to proceed? >>> >>> Thanks, >>> >>> -- >>> Jerry >>> >>> _______________________________________________ >>> SeaBIOS mailing list >>> SeaBIOS(a)seabios.org >>> http://www.seabios.org/mailman/listinfo/seabios >>> >>> >> > > > -- > Jerry Backer >

8 years, 3 months

Re: [SeaBIOS] Running privilege code on hidden O.S.

by Jerry Backer

Hi, The idea is to run some security and packet inspection codes on the hidden core. There is a typo on the title, it should be 'Running privilege code on hidden core'. Thanks, On Thu, Jun 6, 2013 at 3:04 PM, Fred . <eldmannen(a)gmail.com> wrote: > I am curious as to why you would want to do such a thing... > > > On Thu, Jun 6, 2013 at 6:52 PM, Jerry Backer <bataille16(a)gmail.com> wrote: > >> Hello, >> >> I am using seaBIOS with QEMU and am attempting to hide a processor core >> (on an smp system) from the O.S. and then load a dedicated code on that >> core before boot. I have managed to hide one of the cores by decreasing >> CountCPUs (within smp.c) after running the ap core code, hence the BIOS >> load info for 1 less core on the mp table. >> >> However, I have not been able to figure out how to load the privileged >> code. My intuition was to load it when the hidden core enters protected >> mode before running kernel code. But I don't see where in the code the >> cores go into protected mode during boot. >> >> Can anyone give me some insight on how to proceed? >> >> Thanks, >> >> -- >> Jerry >> >> _______________________________________________ >> SeaBIOS mailing list >> SeaBIOS(a)seabios.org >> http://www.seabios.org/mailman/listinfo/seabios >> >> > -- Jerry Backer

8 years, 3 months

Re: [SeaBIOS] Running privilege code on hidden O.S.

by Fred .

I am curious as to why you would want to do such a thing... On Thu, Jun 6, 2013 at 6:52 PM, Jerry Backer <bataille16(a)gmail.com> wrote: > Hello, > > I am using seaBIOS with QEMU and am attempting to hide a processor core > (on an smp system) from the O.S. and then load a dedicated code on that > core before boot. I have managed to hide one of the cores by decreasing > CountCPUs (within smp.c) after running the ap core code, hence the BIOS > load info for 1 less core on the mp table. > > However, I have not been able to figure out how to load the privileged > code. My intuition was to load it when the hidden core enters protected > mode before running kernel code. But I don't see where in the code the > cores go into protected mode during boot. > > Can anyone give me some insight on how to proceed? > > Thanks, > > -- > Jerry > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > >

8 years, 3 months

Running privilege code on hidden O.S.

by Jerry Backer

Hello, I am using seaBIOS with QEMU and am attempting to hide a processor core (on an smp system) from the O.S. and then load a dedicated code on that core before boot. I have managed to hide one of the cores by decreasing CountCPUs (within smp.c) after running the ap core code, hence the BIOS load info for 1 less core on the mp table. However, I have not been able to figure out how to load the privileged code. My intuition was to load it when the hidden core enters protected mode before running kernel code. But I don't see where in the code the cores go into protected mode during boot. Can anyone give me some insight on how to proceed? Thanks, -- Jerry

8 years, 3 months

[PATCH RFC v2 1/2] ec: add ASL for ACPI Embedded Controller

by liguang

Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com> --- src/acpi-dsdt-isa.dsl | 26 ++++++++++++++++++++++++++ 1 files changed, 26 insertions(+), 0 deletions(-) diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl index 23761db..2b9c3a0 100644 --- a/src/acpi-dsdt-isa.dsl +++ b/src/acpi-dsdt-isa.dsl @@ -99,4 +99,30 @@ Scope(\_SB.PCI0.ISA) { IRQNoFlags() { 3 } }) } + + Device (EC0) { + Name(_HID, EISAID ("PNP0C09")) + Name(_UID, 1) + + Method(_CRS, 0) { + Name(BFFR, ResourceTemplate() { + IO(Decode16, 0x62, 0x62, 0, 1) // ACPI DATA IN/OUT + IO(Decode16, 0x66, 0x66, 0, 1) // CMD/STS + }) + Return(BFFR) + } + + OperationRegion(ECFD, EmbeddedControl, 0, 0xFF) + Field(ECFD, ByteAcc, Lock, Preserve) { + Offset(1), + CPUS, 8, // 1, CPU plug/unplug status map + CPUN, 8, // 2, CPU index + } + + Name(_GPE, 3) + + Method(_Q01) { + } + } + } -- 1.7.2.5

8 years, 3 months

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

by Dave Frodin

Kevin, Attached is the new option rom mapping patch. I was hunting around for an existing SeaBIOS ftn that would convert ascii strings to a binary value (i.e. sscanf) but couldn't find one. If there's already one in the code I can replace the text_to_binary() with it. I tested this on a AMD family14 platform. The vendev-map file I added to CBFS looks like this... 10029803-10029802 10029804-10029802 10029805-10029802 10029806-10029802 10029807-10029802 10029808-10029802 10029809-10029802 Each line ends with a NEWLINE character (0x0A). On my test platform the actual graphics ID of the part is 10029804. The vgabios gets added to CBFS with the name "pci1002,9802.rom". Thanks, Dave

8 years, 3 months

[PATCH v3] config: allow DEBUG_IO for !QEMU

by Gerd Hoffmann

Allow selecting DEBUG_IO for non-qemu configurations, which is useful when running coreboot+seabios on qemu. [ v2: QEMU_HARDWARE is even better as DEBUG_IO default value ] [ v3: make QEMU_HARDWARE usage consistent with other config options, fix spellings in commit message ] Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Kconfig b/src/Kconfig index 3c80132..5882d11 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -425,7 +425,7 @@ menu "Debugging" Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8. config DEBUG_IO - depends on QEMU && DEBUG_LEVEL != 0 + depends on QEMU_HARDWARE && DEBUG_LEVEL != 0 bool "Special IO port debugging" default y help -- 1.7.9.7

8 years, 3 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS June 2013