On 02/18/14 22:08, Laszlo Ersek wrote:
> On 02/18/14 20:17, Gabriel L. Somlo wrote:
>> On Tue, Feb 18, 2014 at 11:21:33AM +0100, Gerd Hoffmann wrote:
>
>> Using Fedora 20 live, I collected the SMBIOS table from the guest
>> using "dmidecode --dump-bin
On 02/18/14 20:17, Gabriel L. Somlo wrote:
> On Tue, Feb 18, 2014 at 11:21:33AM +0100, Gerd Hoffmann wrote:
> Using Fedora 20 live, I collected the SMBIOS table from the guest
> using "dmidecode --dump-bin", with the unpatched SeaBIOS
> (dmidecode_pc.bin), SeaBIOS with my patch applied (dmidecode_
On 01/17/14 18:17, Kevin O'Connor wrote:
> On Wed, Jan 15, 2014 at 11:01:59AM +0100, Paolo Bonzini wrote:
>> Il 15/01/2014 02:48, Laszlo Ersek ha scritto:
>>> When init_virtio_scsi() finds no SCSI targets connected to the HBA, it
>>> frees the virtio ring. O
emory to be reused. Device reset causes the hypervisor to drop its
references.
This change is justified / underpinned by pure virtio-spec compliance as
well.
Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1013418
Signed-off-by: Laszlo Ersek
---
src/hw/virtio-scsi.c | 4 +++-
1 file ch
On 12/21/13 03:56, Kevin O'Connor wrote:
> FYI, I've added a few pages to the wiki with some high-level
> information on the internals of SeaBIOS:
> http://seabios.org/Developer_Documentation
>
> This is still a work in progress.
Very much appreciated.
Laszlo
__
On 12/19/13 23:16, Michael S. Tsirkin wrote:
> I suspect we need to init more devices, but I need to look some
> more into this. Basically whatever OS does not restore, we have to.
I don't think that implication is necessarily true. Just because neither
restores some device state currently doesn'
On 12/19/13 20:39, Kevin O'Connor wrote:
> On Thu, Dec 19, 2013 at 08:40:23PM +0200, Michael S. Tsirkin wrote:
>> On Thu, Dec 19, 2013 at 12:04:25PM -0500, Kevin O'Connor wrote:
>>> On Thu, Dec 19, 2013 at 01:49:02PM +0200, Michael S. Tsirkin wrote:
PIIX spec says that most its registers are r
On 12/18/13 23:10, Laszlo Ersek wrote:
> 1. SEC after cold boot
> 2. PEI after cold boot
> 2.5 DXE IPL PEIM loads DXE core
> 3. DXE after cold boot
> 4. BDS after cold boot
> 5. runtime (OSPM), normal entry
> 6. PEI after S3 resume
> 6.5 DXE IPL PEIM branches to S3 resume
On 12/18/13 17:34, Paolo Bonzini wrote:
>
>
> - Messaggio originale -
>> Da: "Michael S. Tsirkin"
>> A: "marcel a"
>> Cc: "Paolo Bonzini" , "Gal Hammer"
>> , seabios@seabios.org,
>> qemu-de...@nongnu.org
>> Inviato: Mercoledì, 18 dicembre 2013 17:33:06
>> Oggetto: Re: [Qemu-devel] [PAT
On 12/05/13 11:04, Gerd Hoffmann wrote:
> Hi,
>
> $subject says all.
>
> Linking out/rom32seg.o
> out/code32seg.o: In function `debug_putc':
> /home/kraxel/projects/seabios/src/output.c:42: undefined reference to
> `qemu_debug_putc'
> /home/kraxel/projects/seabios/src/output.c:45: undefined r
On 09/06/13 02:45, Kevin O'Connor wrote:
> On Wed, Sep 04, 2013 at 08:13:56AM +0200, Gerd Hoffmann wrote:
>> I'd like to do this as early as possible, because one of the things this
>> enables is logging via qemu debug port (CONFIG_DEBUG_IO).
>
> Good point.
>
>> Also note that preinit has a run
On 08/14/13 12:54, Fabio Fantoni wrote:
> Il 14/08/2013 11:56, Laszlo Ersek ha scritto:
>> On 08/14/13 11:19, Fabio Fantoni wrote:
>>
>>> Tried with qemu 1.4.2 and it works also with 4 gb of ram.
>>> This ram regression seems to be introduced with qemu 1.5, and the
On 08/14/13 11:19, Fabio Fantoni wrote:
> Tried with qemu 1.4.2 and it works also with 4 gb of ram.
> This ram regression seems to be introduced with qemu 1.5, and there is
> another regression more critical with qemu 1.6.
Can you save qemu's stderr for the 1.5->1.6 regression?
> Tried to add se
On 08/13/13 12:33, Fabio Fantoni wrote:
> Il 13/08/2013 12:04, Laszlo Ersek ha scritto:
>> CC'ing Gerd and the seabios list:
>>
>> On 08/13/13 11:16, Fabio Fantoni wrote:
>>> Il 12/08/2013 17:04, Fabio Fantoni ha scritto:
>>>> New issue:
>>>
CC'ing Gerd and the seabios list:
On 08/13/13 11:16, Fabio Fantoni wrote:
> Il 12/08/2013 17:04, Fabio Fantoni ha scritto:
>> Dom0:
>> Wheezy 64 bit with kernel from package linux-image-3.2.0-4-amd64
>> version 3.2.46-1 and all dependency packages for xen, spice and usb
>> redirection.
>> Seabios
On 08/09/13 17:49, Michael S. Tsirkin wrote:
> On Fri, Aug 09, 2013 at 12:13:06AM -0400, Kevin O'Connor wrote:
>> On Thu, Aug 08, 2013 at 04:56:55PM +0200, Gerd Hoffmann wrote:
>>> On 08/08/13 16:13, Michael S. Tsirkin wrote:
On Thu, Aug 08, 2013 at 12:21:32PM +0200, Gerd Hoffmann wrote:
>
On 08/09/13 12:05, Mario wrote:
> Yesterday I tried with Ubuntu 64 bit installed on the MAC MINI,today I
> tried with this : (but I've got the same error. And no,I haven't used
> the patch of gabriel :
>
> root@mario-ThinkCentre-:/home/marietto/Scrivania/seabios# uname -a
>
> Linux mario-Thin
On 07/30/13 12:45, Gerd Hoffmann wrote:
> Hi,
>
> We already have tools/vgafixup.py to workaround some x86emu issues.
> Looks like some more is needed, reportly[1] there are more xorg
> segfaults which look alot like x86emu isses. They trigger with stdvga
> and qxl (which are handled using the
On 07/09/13 09:57, Michael S. Tsirkin wrote:
> On Tue, Jul 09, 2013 at 09:53:50AM +0200, Laszlo Ersek wrote:
>> On 07/08/13 20:30, Michael S. Tsirkin wrote:
>>> This patchset moves all generation of ACPI tables
>>> from guest BIOS to the hypervisor.
>>
>
On 07/08/13 20:30, Michael S. Tsirkin wrote:
> This patchset moves all generation of ACPI tables
> from guest BIOS to the hypervisor.
Doesn't seem to apply on ab8bf290, can you pls rebase and repost?
Thanks
Laszlo
___
SeaBIOS mailing list
SeaBIOS@seab
On 06/16/13 17:30, Kevin O'Connor wrote:
> Unfortunately not. There was nothing special about the DSDT changes
> in that commit. Likely the AML interpretter in Solaris is quirky and
> one of the clauses in that commit (or some arrangement of clauses) is
> confusing Solaris. This is one of the u
On 06/14/13 02:26, Laszlo Ersek wrote:
> On 06/14/13 01:02, Paolo Bonzini wrote:
>> Il 10/06/2013 21:03, Anthony Liguori ha scritto:
>>>>> I'm not really convinced that
>>>>> QEMU<->firmware is a GPL boundary because of how tightly the two are
>
On 06/14/13 01:02, Paolo Bonzini wrote:
> Il 10/06/2013 21:03, Anthony Liguori ha scritto:
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
>>> actua
On 06/11/13 17:45, Michael S. Tsirkin wrote:
> To summarize, there's a concensus now that generating ACPI
> tables in QEMU is a good idea.
>
> Two issues that need to be addressed:
> - original patches break cross-version migration. Need to fix that.
>
> - Anthony requested that patchset is merg
On 06/03/13 08:06, Gerd Hoffmann wrote:
> ---
> src/coreboot.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/coreboot.c b/src/coreboot.c
> index 120bc2e..2c8bd2d 100644
> --- a/src/coreboot.c
> +++ b/src/coreboot.c
> @@ -14,6 +14,7 @@
> #include "config.h" // CONFIG_*
> #
On 06/01/13 05:35, Kevin O'Connor wrote:
> The plan on uefi was to use the smbios
> tables to detect qemu. Once detection is in place, the DEBUG_IO
> support could be made dependent on QEMU_HARDWARE and only activated
> after detection succeeds.
Understood.
I wasn't aware this was pending on me
On 05/31/13 18:33, David Woodhouse wrote:
> On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
>> It's even more fundamental. OVMF as a whole (at least in it's usable
>> form) is not Open Source.
>
> The FAT module is required to make EDK2 usable, and yes, that's not Open
> Source. So in
On 05/31/13 17:43, Anthony Liguori wrote:
> David Woodhouse writes:
>
>> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>>
>>>
>>>
>>> Fork OVMF, drop the fat module, and just add GPL code. It's an easily
>>> solvable problem.
>>
>> Heh. Actually it doesn't need to be a fork. It's m
On 05/31/13 16:38, Anthony Liguori wrote:
> It's either Open Source or it's not. It's currently not.
I disagree with this binary representation of Open Source or Not. If it
weren't (mostly) Open Source, how could we fork (most of) it as you're
suggesting (from the soapbox :))?
> I have a hard
>
On 05/31/13 16:08, David Woodhouse wrote:
> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>
>>
>>
>> Fork OVMF, drop the fat module, and just add GPL code. It's an easily
>> solvable problem.
>
> Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
> driver is just
On 05/31/13 15:04, Anthony Liguori wrote:
> Laszlo Ersek writes:
>
>> On 05/31/13 09:09, Jordan Justen wrote:
>>
>> Due to licensing differences I can't just port code from SeaBIOS to
>> OVMF
>
>
:)
> Fork OVMF, drop the fat module, and just add
On 05/31/13 03:09, Kevin O'Connor wrote:
> On Thu, May 30, 2013 at 09:30:33AM +0200, Gerd Hoffmann wrote:
>> On 05/30/13 03:34, Kevin O'Connor wrote:
>>> On Wed, May 29, 2013 at 04:25:59PM +0200, Gerd Hoffmann wrote:
Allow selecting DEBUG_IO for non-qemu configurations,
which is useful wh
On 05/31/13 10:13, Peter Stuge wrote:
> ACPI bytes are obviously a function of QEMU configuration.
Precisely!
When we evaluate that (mathematical-sense) function in boot firmware, we
need to retrieve the function's arguments. Those arguments are bits of
QEMU configuration, as you say, and fw_cfg
On 05/31/13 09:09, Jordan Justen wrote:
> Why is updating the ACPI tables in seabios viewed as such a burden?
> Either qemu does it, or seabios... (And, OVMF too, but I don't think
> you guys are concerned with that. :)
I am :)
> On the flip side, why is moving the ACPI tables to QEMU such an is
On 05/30/13 18:57, Jordan Justen wrote:
> On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek wrote:
>> On 05/30/13 18:20, Jordan Justen wrote:
>>> I think ACPI table generation lives in firmware on real products,
>>> because on real products the firmware is the point th
On 05/30/13 18:20, Jordan Justen wrote:
> I think ACPI table generation lives in firmware on real products,
> because on real products the firmware is the point that best
> understands the actual hardware layout for the machine. In qemu, I
> would say that qemu best knows the hardware layout, give
On 05/30/13 14:19, David Woodhouse wrote:
> Yeah, but if we're shoving a lot of hardware-specific ACPI table
> generation into the guest's firmware, instead of just doing it on the
> qemu side where a number of us seem to think it belongs, then there *is*
> a benefit to using Coreboot. When stuff
On 05/30/13 11:23, David Woodhouse wrote:
> On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
>>
>>> Certainly an option, but that is a long-term project.
>>
>> Out of curiousity, are there other benefits to using coreboot as a core
>> firmware in QEMU?
>>
>> Is there a payload we would eve
On 05/30/13 09:30, Gerd Hoffmann wrote:
> On 05/30/13 03:34, Kevin O'Connor wrote:
>> On Wed, May 29, 2013 at 04:25:59PM +0200, Gerd Hoffmann wrote:
>>> Allow selecting DEBUG_IO for non-qemu configurations, which is
>>> useful when running coreboot+seabios on qemu.
>>
>> Unfortunately, if one does
_LEVEL != 0
> bool "Special IO port debugging"
> default y
> help
>
QEMU selects QEMU_HARDWARE, so OK in that direction.
CSM and COREBOOT (!QEMU in general) make the QEMU_HARDWARE option
available, which when set to y opens up DEBUG_IO.
Revie
On 05/29/13 14:37, Laszlo Ersek wrote:
> On 05/29/13 14:03, Gerd Hoffmann wrote:
>> Allow selecting CONSOLE_IO for non-qemu configurations, which is useful
>> when running coreboot+seabios on coreboot.
>>
>> [ v2: QEMU_HARDWARE is even better as CONSOLE_IO default valu
n be deduced from my quoted words under the third link above (and
my next message in that thread), I'm all for making DEBUG_IO as flexible
as possible -- if I understand the current Kconfig right, the CONFIG_CSM
build target still conflicts with CONFIG_DEBUG_IO, and this pa
o_bus_get_dev_path;
> + bus_class->get_fw_dev_path = virtio_bus_get_fw_dev_path;
> }
>
> static const TypeInfo virtio_bus_info = {
>
Ah, the happiness of finally understanding what Paolo suggested. (Or at
least believing so.)
My R-b is superfluous after Paolo's, but I can't resist.
Reviewed-by: Laszlo Ersek
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
On 05/28/13 10:06, Paolo Bonzini wrote:
> Il 28/05/2013 09:40, Amos Kong ha scritto:
>> bootindex parameter of scsi device doesn't work, it causes
>> by wrong pattern in seabios.
>>
>> qemu passes the following firmware dev_path to seabios:
>> /pci@i0cf8/scsi@4/virtio-scsi-device/channel@0/disk@0,
On 05/15/13 18:25, Paolo Bonzini wrote:
> Il 15/05/2013 18:25, Laszlo Ersek ha scritto:
>> (Not sure why the CC list has grown this huge, but I'm adding Drew for
>> good mesaure.)
>>
>> On 05/15/13 09:27, Hu Tao wrote:
>>> On Wed, May 15, 2013 at 09:21:54AM
(Not sure why the CC list has grown this huge, but I'm adding Drew for
good mesaure.)
On 05/15/13 09:27, Hu Tao wrote:
> On Wed, May 15, 2013 at 09:21:54AM +0200, Laszlo Ersek wrote:
>> On 04/05/13 09:17, Hu Tao wrote:
>>
>>> +
On 05/15/13 09:27, Hu Tao wrote:
> On Wed, May 15, 2013 at 09:21:54AM +0200, Laszlo Ersek wrote:
>> On 04/05/13 09:17, Hu Tao wrote:
>>
>>> +Method(RDPT, 0, NotSerialized) {
>>> +Store(PEPT, Local0)
&g
On 04/05/13 09:17, Hu Tao wrote:
> +Method(RDPT, 0, NotSerialized) {
> +Store(PEPT, Local0)
> +Return (Local0)
> +}
> +
> +Method(WRPT, 1, NotSerialized) {
> +Store(Arg0, PEPT)
> +}
Please excuse my as
On 05/09/13 16:48, Michael Tokarev wrote:
> [Resending after being subscribed to the list]
>
> I'm not sure what happened yet, but I noticed that current seabios
> does not build with 20130214-32 version of iasl.
>
> Apparently, the listing file (-l) produced now does not contain
> any comments f
Not sure how much it counts, but I personally can agree with you on this
direction :)
One note below:
> @@ -603,8 +604,72 @@ acpi_setup(void)
> if (! CONFIG_ACPI)
> return;
>
> +int acpi_generate = 1;
> +
> dprintf(3, "init ACPI tables\n");
>
> +struct romfile_s *fi
On 04/22/13 17:37, Michael S. Tsirkin wrote:
> On Mon, Apr 22, 2013 at 10:03:01AM +0300, Michael S. Tsirkin wrote:
>> On Sun, Apr 21, 2013 at 08:39:41PM -0400, Kevin O'Connor wrote:
>>> On Sun, Apr 21, 2013 at 11:41:48PM +0300, Michael S. Tsirkin wrote:
Okay I'm pretty close to posting some pa
Signed-off-by: Laszlo Ersek
---
src/acpi.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index bc4d8ea..9e128b2 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -393,6 +393,33 @@ build_madt(void)
return madt
This enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek
---
hw/acpi.h |2 ++
hw/acpi.c | 39 ---
2 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index d69b6ef..e3e17e9 100644
isectable.
[1] http://thread.gmane.org/gmane.comp.emulators.qemu/202005/focus=202072
[2] http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5960/focus=6008
Laszlo Ersek (5):
refer to FWCfgState explicitly
hw/acpi: extract standard table headers as a standalone structure
hw/acpi:
2b],
- pc_memory_init() depends on pc_acpi_init() [2a]
This yields the total ordering visible in the patch.
Signed-off-by: Laszlo Ersek
---
hw/pc.h |1 +
hw/i386/pc.c | 142 +
hw/i386/pc_piix.c |2 +
hw/i386/pc_q35.c
Soon we'll declare a function in "hw/pc.h" that takes a
pointer-to-FWCfgState. That would be inconsistent with current usage --
some places use pointer-to-void now even though they mean
pointer-to-FWCfgState. Clean them up.
Signed-off-by: Laszlo Ersek
---
hw/loader.h
This enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek
---
hw/acpi.h | 11 +++
hw/acpi.c | 48 +---
2 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index e18ef28
Again, this enables reuse when preparing per-table fw_cfg blobs later.
Signed-off-by: Laszlo Ersek
---
hw/acpi.h |2 ++
hw/acpi.c |2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/acpi.h b/hw/acpi.h
index e3e17e9..2c89e59 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
On 03/24/13 20:14, Michael S. Tsirkin wrote:
> On Sun, Mar 24, 2013 at 01:17:38PM -0400, Kevin O'Connor wrote:
>> What do you think about using approach 2 as I outline at:
>> http://www.seabios.org/pipermail/seabios/2013-March/006020.html ?
>>
>> The existing fw_cfg acpi table passing mechanism is
I'm confused. What are the requirements?
(1) should unpatched qemu work with patched seabios?
(2) should patched qemu work with unpatched seabios?
Considering patched qemu + patched seabios,
(3) should qemu dynamically control table origin/contents per table?
(4) should qemu be able to suppress/d
On 03/22/13 01:04, Kevin O'Connor wrote:
> On Thu, Mar 21, 2013 at 03:26:26PM +0200, Michael S. Tsirkin wrote:
>> The advantage is that we can make progress
>> without keeping lots of patches out of tree.
>> Unless of course Kevin nacks this all ...
>
> I think we need to have a plan for what the
This config option, when set to N, allows any qemu-built MADT to take
precedence.
Signed-off-by: Laszlo Ersek
---
in v2:
- replaced primitive dynamic detection code with static config option
- 352 bytes saved in 32bit flat init when set to N (RHEL-6 gcc-4.4.7)
v2 depends on Michael's [PA
On 03/21/13 13:52, David Woodhouse wrote:
> On Thu, 2013-03-21 at 13:49 +0100, Gerd Hoffmann wrote:
> How about we don't bother to determine this at runtime at all?
Because it will be a PITA for testers + developers to figure the correct
.config switches of the day during the tra
On 03/21/13 13:23, David Woodhouse wrote:
> On Wed, 2013-03-20 at 20:22 -0400, Kevin O'Connor wrote:
>> On Wed, Mar 20, 2013 at 10:53:05PM +0100, Laszlo Ersek wrote:
>>>
>>> Signed-off-by: Laszlo Ersek
>>
>> I think we need to figure out what th
he qemu source directory, $SEABIOS_DIR points to the
> +seabios build directory); and then run make in the seabios main directory
> with
> +this configuration:
> +
> + make olddefconfig
> +
> +The resulting file "out/bios.bin" contains the process
On 03/21/13 13:03, Michael S. Tsirkin wrote:
> In the interim of moving ACPI tables out of
> seabios, developers should get the config from
> QEMU tree to keep things in sync.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> README | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/REA
licenses/>.
> +
>
> #include "acpi.h" // struct rsdp_descriptor
> #include "util.h" // memcpy
With reference to
<http://www.seabios.org/pipermail/seabios/2013-March/005960.html>:
Acked-by: Laszlo Ersek
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
On 03/21/13 00:52, Kevin O'Connor wrote:
> On Wed, Mar 20, 2013 at 10:53:04PM +0100, Laszlo Ersek wrote:
>> These fields are wider than a single byte; stick to cpu_to_leXX() for
>> consistency with other field settings in this function.
>
> Thanks. We can do thi
On 03/20/13 16:57, Michael S. Tsirkin wrote:
> You are getting this mail because you might have contributed code to one
> of the files in seabios that we want to reuse in QEMU,
> when this file was under GPLv3 or LGPLv3.
>
> QEMU is GPLv2 at the moment, so as a step in the process of moving acpi
>
ads=2
The table dumps / disassemblies are too big to include here, please find
them at <http://people.redhat.com/~lersek/acpi_move/madt_tests.tar.gz>.
Laszlo Ersek (2):
build_madt(): "fix" intsrcovr->{gsi,flags} and local_nmi->flags byte
order
accept MADT
These fields are wider than a single byte; stick to cpu_to_leXX() for
consistency with other field settings in this function.
Signed-off-by: Laszlo Ersek
---
src/acpi.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index 119d1c1
Signed-off-by: Laszlo Ersek
---
src/acpi.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index 8bbc92b..611553e 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -797,13 +797,13 @@ acpi_setup(void)
struct fadt_descriptor_rev1
@@ -826,7 +826,8 @@ acpi_setup(void)
> break;
> }
> }
> -if (fadt && !fadt->dsdt) {
> +
> +if (CONFIG_ACPI_DSDT && fadt && !fadt->dsdt) {
> /* default DSDT */
> void *dsdt = malloc_high
9dd3aa 100644
> --- a/src/acpi.c
> +++ b/src/acpi.c
> @@ -202,7 +202,11 @@ struct srat_memory_affinity
> u32reserved3[2];
> } PACKED;
>
> +#ifdef CONFIG_ACPI_DSDT
> #include "acpi-dsdt.hex"
> +#else
> +static u8 AmlCode[1];
> +#endif
On 03/18/13 11
comments in-line
On 03/18/13 11:12, Michael S. Tsirkin wrote:
> QEMU now loads its own copy of DSDT, so let's not build in PIIX.
> This leaves building in the DSDT an option, default to off.
> If no one complains for a while, we'll be able to
> remove this altogether.
>
> Signed-off-by: Michael S
On 03/18/13 09:24, Michael S. Tsirkin wrote:
> On Sun, Mar 17, 2013 at 10:19:45PM -0400, Kevin O'Connor wrote:
>> On Sun, Mar 17, 2013 at 08:27:36PM +0200, Michael S. Tsirkin wrote:
>>> With seabios built from source, and latest qemu, VMs hang during boot
>>> for me. Bisect points at this commit:
On 03/08/13 04:35, Kevin O'Connor wrote:
> On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
>> On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
>>> That change is definitely just build related - I don't see how it
>>> could impact the final SeaBIOS binary. How did you
On 03/07/13 09:43, Aurelien Jarno wrote:
> I did a git bisect to find the commit fixing the issue. Then, as I was
> not believing the result, I tried the following sequence a dozen of
> times (for some unknown reasons the FreeBSD install CD doesn't exhibit
> the issue, so I used the Debian GNU/kFr
erd Hoffmann
Date: Mon Jan 21 09:17:16 2013 +0100
seabios: update to 1.7.2 release
Not that many changes as we have a pretty recent git snapshot in
master already:
Hannes Reinecke (1):
megasas: Invert PCI device selection
Kevin O'C
On 03/05/13 20:25, Paolo Bonzini wrote:
> Il 05/03/2013 20:12, Laszlo Ersek ha scritto:
>> On 03/05/13 17:59, David Woodhouse wrote:> On Tue, 2013-03-05 at 17:03
>> +0100, Paolo Bonzini wrote:
>>>> Resuming from suspend-to-RAM should not reset all devices. Only t
On 03/05/13 17:59, David Woodhouse wrote:> On Tue, 2013-03-05 at 17:03 +0100,
Paolo Bonzini wrote:
>> Resuming from suspend-to-RAM should not reset all devices. Only the
>> CPU should get a reset signal.
>
> Hm... on reflection, I don't actually know if this is true.
>
> Perhaps we *should* reset
On 02/27/13 10:19, Gerd Hoffmann wrote:
> On 02/26/13 19:30, Laszlo Ersek wrote:
>> On 02/26/13 10:03, Gerd Hoffmann wrote:
>>
>>> Can tianocore grab acpi tables from coreboot?
>>
>> Not that I know of. (... It may have been a rhetorical question.)
>
&g
On 02/26/13 10:03, Gerd Hoffmann wrote:
> Can tianocore grab acpi tables from coreboot?
Not that I know of. (... It may have been a rhetorical question.)
When running on Xen, an area is searched for the RSDP, and linked tables
(prepared by Xen's hvmloader I think) are installed by OVMF.
When ru
On 02/24/13 19:00, Kevin O'Connor wrote:
> On Sat, Feb 23, 2013 at 04:47:26PM +, David Woodhouse wrote:
>> On Sat, 2013-02-23 at 11:38 -0500, Kevin O'Connor wrote:
>>> IMO, we need to move the ACPI table creation (and PIR/MPTABLE/SMBIOS)
>>> to QEMU and just have QEMU pass the tables to SeaBIOS
On 02/22/13 19:13, Laszlo Ersek wrote:
> On 02/22/13 15:55, David Woodhouse wrote:
>> On Fri, 2013-02-22 at 04:23 +0100, Laszlo Ersek wrote:
>>> Patches 1 to 6 upgrade the FADT to ACPI 2.0 and present the PIIX3
>>> Reset Control Register in it.
>>
>> Hm. I c
On 02/22/13 15:55, David Woodhouse wrote:
> On Fri, 2013-02-22 at 04:23 +0100, Laszlo Ersek wrote:
>> Patches 1 to 6 upgrade the FADT to ACPI 2.0 and present the PIIX3
>> Reset Control Register in it.
>
> Hm. I can still trigger the soft reset loop in SeaBIOS, but perhaps no
On 02/20/13 18:18, Ian Campbell wrote:
> On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
>> However in OVMF the RESERVED_MEMBASE range is not parsed from this
>> Xen-exported table, it is added manually in InitializeXen()
>> [OvmfPkg/PlatformPei/Xen.c]:
>>
&
Regarding the ACPI tables, OVMF takes them from Xen. It scans 0x000EA020
to 0x000F for the RSDP and goes from there. See
OvmfPkg/AcpiPlatformDxe/Xen.c.
I'm not sure about the e820 table. In hvmloader's build_e820_table()
[tools/firmware/hvmloader/e820.c], a range starting at RESERVED_MEMBASE
i
On 02/19/13 23:45, David Woodhouse wrote:
> I'm beginning to wish I'd just ignored the fact that
> we need a properly working "soft" reset to get back from 286 protected
> mode to real mode, and wired up the damn PAM reset unconditionally. I'm
> not convinced that the protected->real mode transiti
On 02/19/13 19:41, Gleb Natapov wrote:
> On Tue, Feb 19, 2013 at 06:35:03PM +, David Woodhouse wrote:
>> On Tue, 2013-02-19 at 20:13 +0200, Gleb Natapov wrote:
>>>
I take it you mean copy 0xfffe to 0xe? That would not be
>>> fun.
SeaBIOS would need to detect that it's in the
On 02/19/13 16:29, David Woodhouse wrote:
> On Mon, 2013-02-18 at 17:37 -0500, Kevin O'Connor wrote:
>> The ACPI v2 spec describes a "hard" reset register. SeaBIOS could
>> extract it from the FADT and then use it. Of course, we'd probably
>> want to update the QEMU ACPI tables to implement ACPI
On 02/18/13 22:25, David Woodhouse wrote:
> On Mon, 2013-02-18 at 21:27 +0100, Laszlo Ersek wrote:
>>
>> could someone please review this one-liner?
>
> Kevin already merged it.
Thanks. Sorry for the noise.
L.
___
SeaBIOS
Hi,
could someone please review this one-liner?
Thanks!
Laszlo
(PS: sorry for top posting)
On 02/14/13 05:43, Laszlo Ersek wrote:
> This patch does the same for Cirrus as David's following patch for bochs,
> originally posted under
> <http://www.seabios.org/pipermail/seab
On 02/18/13 20:09, Laszlo Ersek wrote:
> On 02/18/13 20:00, Kevin O'Connor wrote:
>> On Mon, Feb 18, 2013 at 08:31:01PM +0200, Gleb Natapov wrote:
>>> Laszlo explained to me that the problem is that after reset we end up
>>> in SeaBIOS reset code instead of OVMF
On 02/18/13 20:00, Kevin O'Connor wrote:
> On Mon, Feb 18, 2013 at 08:31:01PM +0200, Gleb Natapov wrote:
>> Laszlo explained to me that the problem is that after reset we end up
>> in SeaBIOS reset code instead of OVMF one. This is because kvm starts
>> to execute from 0 instead of fff0 aft
On 02/18/13 18:45, Gleb Natapov wrote:
> On Mon, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
>> CS =f000 000f f300
>> ^^^^
>> |base limitflags
>> selector
>>
> This is because real mode is
On 02/18/13 13:53, David Woodhouse wrote:
> Nevertheless, on my workstation as on yours, we do seem to end up
> executing from the CSM in RAM when we reset. But on my laptop, it
> executes the *ROM* as it should.
>
> This patch 'fixes' it, and I think it might even be correct in itself,
> but I do
On 02/15/13 21:57, David Woodhouse wrote:
> On Fri, 2013-02-15 at 19:54 +0100, Laszlo Ersek wrote:
>> Same infinite loop, alas...
>>
>> (i) What is your host kernel exactly?
>
> 3.7.5-201.fc18.x86_64 (booted from EFI on a MacBookPro 8,3).
- host CPU: Xeon W3550 (fam
On 02/14/13 23:24, David Woodhouse wrote:
> On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
>> I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
>> reset requested by the guest doesn't work as expected. The behavior is
>> an infinite loop
(removing edk2-devel, adding Jan)
On 02/15/13 08:19, Michael Tokarev wrote:
> 15.02.2013 07:43, Kevin O'Connor wrote:
>> On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote:
>>> On 02/15/13 02:22, Kevin O'Connor wrote:
>>>> On Thu, Feb 14, 2013 a
201 - 300 of 342 matches
Mail list logo
