On Tue, May 07, 2013 at 07:33:13PM +0300, Michael S. Tsirkin wrote:
> > If you really feel QEMU should direct the pointer and checksum
> > updates, you might want to consider something like:
> >
> > struct tabledeploy_s {
> > u32 command;
> > union {
> > // COMMAND_ALLOC - allocate
On Tue, May 07, 2013 at 10:49:14PM +0300, Michael S. Tsirkin wrote:
> On Tue, May 07, 2013 at 10:37:28PM +0300, Gleb Natapov wrote:
> > On Tue, May 07, 2013 at 10:33:17PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, May 07, 2013 at 10:26:34PM +0300, Gleb Natapov wrote:
> > > > On Tue, May 07, 201
On Tue, May 07, 2013 at 10:37:28PM +0300, Gleb Natapov wrote:
> On Tue, May 07, 2013 at 10:33:17PM +0300, Michael S. Tsirkin wrote:
> > On Tue, May 07, 2013 at 10:26:34PM +0300, Gleb Natapov wrote:
> > > On Tue, May 07, 2013 at 09:54:33PM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, May 07, 201
On Tue, May 07, 2013 at 10:33:17PM +0300, Michael S. Tsirkin wrote:
> On Tue, May 07, 2013 at 10:26:34PM +0300, Gleb Natapov wrote:
> > On Tue, May 07, 2013 at 09:54:33PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, May 07, 2013 at 09:07:04PM +0300, Gleb Natapov wrote:
> > > > On Wed, Apr 24, 201
On Tue, May 07, 2013 at 10:26:34PM +0300, Gleb Natapov wrote:
> On Tue, May 07, 2013 at 09:54:33PM +0300, Michael S. Tsirkin wrote:
> > On Tue, May 07, 2013 at 09:07:04PM +0300, Gleb Natapov wrote:
> > > On Wed, Apr 24, 2013 at 11:09:16AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Apr 23, 201
On Tue, May 07, 2013 at 09:54:33PM +0300, Michael S. Tsirkin wrote:
> On Tue, May 07, 2013 at 09:07:04PM +0300, Gleb Natapov wrote:
> > On Wed, Apr 24, 2013 at 11:09:16AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Apr 23, 2013 at 08:23:44PM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Apr 2
On Tue, May 07, 2013 at 09:07:04PM +0300, Gleb Natapov wrote:
> On Wed, Apr 24, 2013 at 11:09:16AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Apr 23, 2013 at 08:23:44PM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Apr 22, 2013 at 08:38:58PM -0400, Kevin O'Connor wrote:
> > > > On Mon, Apr 22, 2
On Wed, Apr 24, 2013 at 11:09:16AM +0300, Michael S. Tsirkin wrote:
> On Tue, Apr 23, 2013 at 08:23:44PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Apr 22, 2013 at 08:38:58PM -0400, Kevin O'Connor wrote:
> > > On Mon, Apr 22, 2013 at 10:03:01AM +0300, Michael S. Tsirkin wrote:
> > > > On Sun, Apr
On Tue, Apr 23, 2013 at 08:54:17PM -0400, Kevin O'Connor wrote:
> On Tue, Apr 23, 2013 at 06:22:12PM +0300, Michael S. Tsirkin wrote:
> > So here's the version with shift, that should do it
> > correctly. Add mere 8 lines of code.
> > I'll look into alignment and fseg now.
> [...]
> > --- /dev/null
On Tue, Apr 23, 2013 at 08:23:44PM +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 22, 2013 at 08:38:58PM -0400, Kevin O'Connor 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,
On Tue, Apr 23, 2013 at 06:22:12PM +0300, Michael S. Tsirkin wrote:
> So here's the version with shift, that should do it
> correctly. Add mere 8 lines of code.
> I'll look into alignment and fseg now.
[...]
> --- /dev/null
> +++ b/src/linker.h
> @@ -0,0 +1,29 @@
> +#include "types.h" // u8
> +#inc
On Tue, Apr 23, 2013 at 11:49:57AM +0300, Michael S. Tsirkin wrote:
> > I know of the following quirks that would have to be handled:
> >
> > 1 - the RSDP must be in the f-segment (where as all other tables can
> > go into "high" memory).
> >
> > 2 - the RSDP has a checksum in a different locatio
On Mon, Apr 22, 2013 at 08:38:58PM -0400, Kevin O'Connor 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
On Mon, Apr 22, 2013 at 08:42:18PM -0400, Kevin O'Connor wrote:
> On Mon, Apr 22, 2013 at 08:23:39PM +0300, Michael S. Tsirkin wrote:
> > > @@ -0,0 +1,28 @@
> > > +#include "types.h" // u8
> > > +#include "util.h" // romfile_s
> > > +
> > > +/* ROM file linker interface. Linker uses little endian f
On Mon, Apr 22, 2013 at 08:42:18PM -0400, Kevin O'Connor wrote:
> On Mon, Apr 22, 2013 at 08:23:39PM +0300, Michael S. Tsirkin wrote:
> > > @@ -0,0 +1,28 @@
> > > +#include "types.h" // u8
> > > +#include "util.h" // romfile_s
> > > +
> > > +/* ROM file linker interface. Linker uses little endian f
On Mon, Apr 22, 2013 at 08:38:58PM -0400, Kevin O'Connor 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
On Mon, Apr 22, 2013 at 08:23:39PM +0300, Michael S. Tsirkin wrote:
> > @@ -0,0 +1,28 @@
> > +#include "types.h" // u8
> > +#include "util.h" // romfile_s
> > +
> > +/* ROM file linker interface. Linker uses little endian format */
> > +struct linker_entry_s {
> > +u8 size; /* size in bytes inc
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 patches
> > > that advance this project further,
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
On Mon, Apr 22, 2013 at 06:37:32PM +0300, 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 pr
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 patches
> > > that advance this project further,
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 patches
> > that advance this project further, but wanted to
> > check something beforehand: there are several tables
> > t
On Sun, Apr 21, 2013 at 11:41:48PM +0300, Michael S. Tsirkin wrote:
> Okay I'm pretty close to posting some patches
> that advance this project further, but wanted to
> check something beforehand: there are several tables
> that point to other tables (for example: FADT points
> to DSDT). What I did
On Sun, Mar 24, 2013 at 05:55:22PM -0400, Kevin O'Connor wrote:
> On Sun, Mar 24, 2013 at 09:45:54PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Mar 24, 2013 at 03:21:08PM -0400, Kevin O'Connor wrote:
> > > On Sun, Mar 24, 2013 at 09:14:47PM +0200, Michael S. Tsirkin wrote:
> > > > I don't exactly
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
On Sun, Mar 24, 2013 at 09:45:54PM +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 24, 2013 at 03:21:08PM -0400, Kevin O'Connor wrote:
> > On Sun, Mar 24, 2013 at 09:14:47PM +0200, Michael S. Tsirkin wrote:
> > > I don't exactly understand what do you mean by "file".
> >
> > A fw_cfg entry added us
On Sun, Mar 24, 2013 at 03:21:08PM -0400, Kevin O'Connor wrote:
> On Sun, Mar 24, 2013 at 09:14:47PM +0200, Michael S. Tsirkin wrote:
> > I don't exactly understand what do you mean by "file".
>
> A fw_cfg entry added using QEMU's fw_cfg_add_file() instead of
> fw_cfg_add_bytes().
>
> -Kevin
Loo
On Sun, Mar 24, 2013 at 09:14:47PM +0200, Michael S. Tsirkin wrote:
> I don't exactly understand what do you mean by "file".
A fw_cfg entry added using QEMU's fw_cfg_add_file() instead of
fw_cfg_add_bytes().
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seab
On Sun, Mar 24, 2013 at 01:17:38PM -0400, Kevin O'Connor wrote:
> On Sun, Mar 24, 2013 at 03:07:40PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 21, 2013 at 08:04:38PM -0400, Kevin O'Connor wrote:
> > > So, I see two ways to do this:
> > >
> > > 1 - update SeaBIOS with a patch series that mak
On Sun, Mar 24, 2013 at 03:07:40PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 21, 2013 at 08:04:38PM -0400, Kevin O'Connor wrote:
> > So, I see two ways to do this:
> >
> > 1 - update SeaBIOS with a patch series that makes it capable of
> > handling all tables via existing and new fw_cfg entri
On Thu, Mar 21, 2013 at 08:04:38PM -0400, Kevin O'Connor wrote:
> On Thu, Mar 21, 2013 at 03:26:26PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 21, 2013 at 01:14:38PM +, David Woodhouse wrote:
> > > On Thu, 2013-03-21 at 15:12 +0200, Michael S. Tsirkin wrote:
> > > > Anyway, I am not agai
On Fri, Mar 22, 2013 at 08:02:21PM +0100, Paolo Bonzini wrote:
> Il 21/03/2013 14:12, Michael S. Tsirkin ha scritto:
> > On Thu, Mar 21, 2013 at 01:04:35PM +, David Woodhouse wrote:
> >> On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
> >>> - for an earlier qemu, the option must be set,
Il 21/03/2013 14:12, Michael S. Tsirkin ha scritto:
> On Thu, Mar 21, 2013 at 01:04:35PM +, David Woodhouse wrote:
>> On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
>>> - for an earlier qemu, the option must be set,
>>> - for a later qemu the option must be clear &&
>>> (no -acpitable
Il 22/03/2013 00:22, Kevin O'Connor ha scritto:
This also needs
> >> to be resolved for SSDT tables, which can have zero, one, or more
> >> instances.
>> >
>> > Same argument as for the MADT.
> The issue with the SSDT is that there can be many of them. QEMU may
> wish to pass in 2
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
>> As this is quite a bunch of work I would tend to avoid a flag day like
>> this so we can switch over tables one by one without building up big
>> patch queues.
>
> True. I'm certainly open to ideas.
>
> In practice, one never wants to mix QEMU generated ACPI tables with
> SeaBIOS generated AC
On Thu, Mar 21, 2013 at 03:26:26PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 21, 2013 at 01:14:38PM +, David Woodhouse wrote:
> > On Thu, 2013-03-21 at 15:12 +0200, Michael S. Tsirkin wrote:
> > > Anyway, I am not against such runtime flags.
> > >
> > > If we add to this an option to buil
On Thu, Mar 21, 2013 at 09:18:50AM +0100, Gerd Hoffmann wrote:
> On 03/21/13 07:23, Michael S. Tsirkin wrote:
> > On Wed, Mar 20, 2013 at 08:22:30PM -0400, Kevin O'Connor wrote:
> >> On Wed, Mar 20, 2013 at 10:53:05PM +0100, Laszlo Ersek wrote:
> >>>
> >>> Signed-off-by: Laszlo Ersek
> >>
> >> I t
On Thu, Mar 21, 2013 at 03:04:37PM +0100, Gerd Hoffmann wrote:
> Today you can clone upstream seabios, build it, and the resulting image
> will work on pretty much any qemu version since 0.12 or so. You don't
> have to pick the correct config switches for your particular qemu
> version, it just wo
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 the final fw_cfg interface for
> ACPI, SMBIOS, mptable, and PIR will be.
Once we have consensus, we
Hi,
> But I'm not sure I see any point in doing it table-by-table. Surely it
> can be all or nothing?
It allows to merge changes piecewise and avoids piling up long patch
queues. It makes bisecting regressions easier. Also the logic "if
table $foo is provided by qemu, just use it, otherwise g
On 03/21/13 14:01, Michael S. Tsirkin wrote:
> On Thu, Mar 21, 2013 at 01:49:36PM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
> 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
On Thu, Mar 21, 2013 at 01:14:38PM +, David Woodhouse wrote:
> On Thu, 2013-03-21 at 15:12 +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 21, 2013 at 01:04:35PM +, David Woodhouse wrote:
> > > On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
> > > > - for an earlier qemu, the option
On Thu, 2013-03-21 at 15:12 +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 21, 2013 at 01:04:35PM +, David Woodhouse wrote:
> > On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
> > > - for an earlier qemu, the option must be set,
> > > - for a later qemu the option must be clear &&
> > >
On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
> - for an earlier qemu, the option must be set,
> - for a later qemu the option must be clear &&
> (no -acpitable switch must be specified on the qemu cmldine ||
>one -acpitable switch must load a MADT)
Hm, that sounds like it won't be
On Thu, Mar 21, 2013 at 01:04:35PM +, David Woodhouse wrote:
> On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
> > - for an earlier qemu, the option must be set,
> > - for a later qemu the option must be clear &&
> > (no -acpitable switch must be specified on the qemu cmldine ||
> >
On Thu, Mar 21, 2013 at 12:52:17PM +, 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 swi
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 Thu, Mar 21, 2013 at 01:49:36PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> >>> 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 transition phase?
> >
> > Wh
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 the final fw_cfg interface for
>> ACPI, SMBIOS, mptable
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 transition phase?
> >
> > Why is it a PITA? A
Hi,
>>> 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 transition phase?
>
> Why is it a PITA? Are you developing QEMU? Just use the makefile from
> roms/co
On Thu, Mar 21, 2013 at 12:23:45PM +, 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 the final fw_cfg interf
On Wed, Mar 20, 2013 at 10:53:05PM +0100, Laszlo Ersek wrote:
>
> Signed-off-by: Laszlo Ersek
I think this is a bit too aggressive.
Let's do what I did for DSDT, add a config
option and default to yes.
In QEMU, override it to remove MADT from bios.
> ---
> src/acpi.c | 19 ---
On Thu, Mar 21, 2013 at 09:18:50AM +0100, Gerd Hoffmann wrote:
> On 03/21/13 07:23, Michael S. Tsirkin wrote:
> > On Wed, Mar 20, 2013 at 08:22:30PM -0400, Kevin O'Connor wrote:
> >> On Wed, Mar 20, 2013 at 10:53:05PM +0100, Laszlo Ersek wrote:
> >>>
> >>> Signed-off-by: Laszlo Ersek
> >>
> >> I t
On 03/21/13 07:23, Michael S. Tsirkin wrote:
> On Wed, Mar 20, 2013 at 08:22:30PM -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 the final fw_cfg interface for
>> ACPI, SMBIO
On Wed, Mar 20, 2013 at 08:22:30PM -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 the final fw_cfg interface for
> ACPI, SMBIOS, mptable, and PIR will be.
>
> We can use the
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 the final fw_cfg interface for
ACPI, SMBIOS, mptable, and PIR will be.
We can use the current fw_cfg ACPI table passing mechanism for ACPI,
but there are a couple of
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 *
59 matches
Mail list logo
