SeaBIOS May 2013

seabios@seabios.org

29 participants
56 discussions

[PATCH v17] Add pvpanic device driver
by Hu Tao 15 May '13

15 May '13

pvpanic device is used to notify host(qemu) when guest panic happens. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Hu Tao <hutao(a)cn.fujitsu.com> --- No change from v16. qemu patches at: http://lists.nongnu.org/archive/html/qemu-devel/2013-04/msg01028.html src/acpi.c | 3 +++ src/ssdt-misc.dsl | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+) diff --git a/src/acpi.c b/src/acpi.c index bc4d8ea..fe504f0 100644 --- a/src/acpi.c +++ b/src/acpi.c @@ -534,6 +534,9 @@ build_ssdt(void) ssdt_ptr[acpi_pci64_valid[0]] = 0; } + int pvpanic_port = romfile_loadint("etc/pvpanic-port", 0x0); + *(u16 *)(ssdt_ptr + *ssdt_isa_pest) = pvpanic_port; + ssdt_ptr += sizeof(ssdp_misc_aml); // build Scope(_SB_) header diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl index 679422b..acc850e 100644 --- a/src/ssdt-misc.dsl +++ b/src/ssdt-misc.dsl @@ -55,4 +55,50 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1) Zero /* reserved */ }) } + + External(\_SB.PCI0, DeviceObj) + External(\_SB.PCI0.ISA, DeviceObj) + + Scope(\_SB.PCI0.ISA) { + Device(PEVT) { + Name(_HID, "QEMU0001") + /* PEST will be patched to be Zero if no such device */ + ACPI_EXTRACT_NAME_WORD_CONST ssdt_isa_pest + Name(PEST, 0xFFFF) + OperationRegion(PEOR, SystemIO, PEST, 0x01) + Field(PEOR, ByteAcc, NoLock, Preserve) { + PEPT, 8, + } + + Method(_STA, 0, NotSerialized) { + Store(PEST, Local0) + If (LEqual(Local0, Zero)) { + Return (0x00) + } Else { + Return (0x0F) + } + } + + Method(RDPT, 0, NotSerialized) { + Store(PEPT, Local0) + Return (Local0) + } + + Method(WRPT, 1, NotSerialized) { + Store(Arg0, PEPT) + } + + Name(_CRS, ResourceTemplate() { + IO(Decode16, 0x00, 0x00, 0x01, 0x01, IO) + }) + + CreateWordField(_CRS, IO._MIN, IOMN) + CreateWordField(_CRS, IO._MAX, IOMX) + + Method(_INI, 0, NotSerialized) { + Store(PEST, IOMN) + Store(PEST, IOMX) + } + } + } } -- 1.8.1.4

5 11

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
by David Woodhouse 14 May '13

14 May '13

On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote: > > It depends. For ARM we insist that the user provides the > device tree that corresponds to the kernel they're going to > run, and then we just tweak it a bit. Um... device trees describe hardware, and should not be at all kernel-specific. Did you mean to say "the device tree that corresponds to the machine they're going to emulate"? And I suppose you do have a kernel that corresponds to the machine it's going to run on, so what you say isn't *entirely* bogus. But it's just written in a way which makes it scary :) -- dwmw2

2 1

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 10/13] i386: generate pc guest info
by Michael S. Tsirkin 14 May '13

14 May '13

On Mon, May 13, 2013 at 09:23:54PM +0100, Peter Maydell wrote: > On 13 May 2013 21:01, Michael S. Tsirkin <mst(a)redhat.com> wrote: > > This fills in guest info table with misc > > information of interest to the guest. > > Will be used by ACPI table generation code. > > Bunch of coding style violations in this patch which will > need fixing at some point in the RFC->patch process. > > thanks > -- PMM I went over it again and found one: + if (ram_size <= 0x80000000) + guest_info->pci_info.w32.begin = 0x80000000; + else if (ram_size <= 0xc0000000) + guest_info->pci_info.w32.begin = 0xc0000000; + else + guest_info->pci_info.w32.begin = 0xe0000000; should use {}. One is not a bunch so I obviously missed some - it might be helpful if you pointed them out. Thanks, -- MST

2 1

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 08/13] range: add Range structure
by Michael S. Tsirkin 14 May '13

14 May '13

On Mon, May 13, 2013 at 09:20:08PM +0100, Peter Maydell wrote: > On 13 May 2013 21:01, Michael S. Tsirkin <mst(a)redhat.com> wrote: > > Sometimes we need to pass ranges around, add a > > handy structure for this purpose. > > > > Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> > > --- > > include/qemu/range.h | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/include/qemu/range.h b/include/qemu/range.h > > index 3502372..4bcd346 100644 > > --- a/include/qemu/range.h > > +++ b/include/qemu/range.h > > @@ -1,6 +1,28 @@ > > #ifndef QEMU_RANGE_H > > #define QEMU_RANGE_H > > > > +#include <inttypes.h> > > + > > +/* > > + * Operations on 64 address ranges. > > missing "bit" ? > > > + * Notes: > > + * - ranges must not wrap around 0, but can include the last byte ~0x0LL. > > + * - this can not represent a full 0 to ~0x0LL range. > > + */ > > + > > +/* A structure representing a range of addresses. */ > > +struct Range { > > + uint64_t begin; /* First byte of the range, or 0 if empty. */ > > + uint64_t end; /* 1 + the last byte. 0 if range empty or ends at ~0x0LL. */ > > +}; > > +typedef struct Range Range; > > + > > +/* verify that range is not empty and does not overlap */ > > Doesn't overlap what? I meant wrap around there. > Why isn't an empty range valid? > The struct definition above says it's OK. Yes it's a bad name. Should be range_non_empty or something. > > +{ > > + return range->begin + 1 <= range->end; > > +} > > I note that memory.c defines its own concept of an AddrRange. > > thanks > -- PMM Good point, maybe I'll reuse that or just use two 64 bit fields explicitly. -- MST

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 01/13] apic: rename apic specific bitopts
by Michael S. Tsirkin 13 May '13

13 May '13

On Mon, May 13, 2013 at 09:22:20PM +0100, Peter Maydell wrote: > On 13 May 2013 21:00, Michael S. Tsirkin <mst(a)redhat.com> wrote: > > apic has its own version of bitops, with the > > difference that it works on u32 and not long. > > Add apic_ prefix to avoid namespace clashes. > > Wouldn't it be better to consolidate so we only have > one set of bitops rather than a local set in this file? > > thanks > -- PMM Yes but I'd like this patchset to focus on acpi. ATM including bitops in pc.h gives build errors. Thus this trivial patch, can be tested by comparing binary. Consolidation is better done in a separate patchset, and would need more testing. Any chance you can do this on top of this? -- MST

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 12/13] i386: ACPI table generation code from seabios
by Peter Maydell 13 May '13

13 May '13

On 13 May 2013 21:01, Michael S. Tsirkin <mst(a)redhat.com> wrote: > hw/i386/acpi-build.c | 685 +++++++++++++++++++++++++++++++++++++++++++ I'm sitting here hoping nobody ever asks me to add ACPI support for ARM QEMU :-) [not totally impossible one day in the future...] -- PMM

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 10/13] i386: generate pc guest info
by Peter Maydell 13 May '13

13 May '13

On 13 May 2013 21:01, Michael S. Tsirkin <mst(a)redhat.com> wrote: > This fills in guest info table with misc > information of interest to the guest. > Will be used by ACPI table generation code. Bunch of coding style violations in this patch which will need fixing at some point in the RFC->patch process. thanks -- PMM

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 01/13] apic: rename apic specific bitopts
by Peter Maydell 13 May '13

13 May '13

On 13 May 2013 21:00, Michael S. Tsirkin <mst(a)redhat.com> wrote: > apic has its own version of bitops, with the > difference that it works on u32 and not long. > Add apic_ prefix to avoid namespace clashes. Wouldn't it be better to consolidate so we only have one set of bitops rather than a local set in this file? thanks -- PMM

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 08/13] range: add Range structure
by Peter Maydell 13 May '13

13 May '13

On 13 May 2013 21:01, Michael S. Tsirkin <mst(a)redhat.com> wrote: > Sometimes we need to pass ranges around, add a > handy structure for this purpose. > > Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> > --- > include/qemu/range.h | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/include/qemu/range.h b/include/qemu/range.h > index 3502372..4bcd346 100644 > --- a/include/qemu/range.h > +++ b/include/qemu/range.h > @@ -1,6 +1,28 @@ > #ifndef QEMU_RANGE_H > #define QEMU_RANGE_H > > +#include <inttypes.h> > + > +/* > + * Operations on 64 address ranges. missing "bit" ? > + * Notes: > + * - ranges must not wrap around 0, but can include the last byte ~0x0LL. > + * - this can not represent a full 0 to ~0x0LL range. > + */ > + > +/* A structure representing a range of addresses. */ > +struct Range { > + uint64_t begin; /* First byte of the range, or 0 if empty. */ > + uint64_t end; /* 1 + the last byte. 0 if range empty or ends at ~0x0LL. */ > +}; > +typedef struct Range Range; > + > +/* verify that range is not empty and does not overlap */ Doesn't overlap what? Why isn't an empty range valid? The struct definition above says it's OK. > +static inline bool range_valid(struct Range *range) > +{ > + return range->begin + 1 <= range->end; > +} I note that memory.c defines its own concept of an AddrRange. thanks -- PMM

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 02/13] hw/i386/pc.c: move IO_APIC_DEFAULT_ADDRESS to include/hw/i386/apic.h
by Eric Blake 13 May '13

13 May '13

On 05/13/2013 02:00 PM, Michael S. Tsirkin wrote: > Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> > Signed-off-by: Laszlo Ersek <lersek(a)redhat.com> > Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Looks odd to see your sign-off twice :) -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS May 2013