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
> linked.
Where has 'linked' in terms of
Paolo Bonzini writes:
> Il 11/06/2013 03:35, Michael S. Tsirkin ha scritto:
>> Two points
>> 1. You never explained what you mean by un-hardware like.
>>
>>Currently bios is in a ROM device, and it has a
>>template for ACPI tables together with it.
>>This simply moves the tables to a
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
Il 11/06/2013 03:35, Michael S. Tsirkin ha scritto:
> Two points
> 1. You never explained what you mean by un-hardware like.
>
>Currently bios is in a ROM device, and it has a
>template for ACPI tables together with it.
>This simply moves the tables to a separate ROM
>device (FW CF
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
>> actual executable linking?
>
> I should not have eve
On Mon, 2013-06-10 at 19:11 -0500, Anthony Liguori wrote:
> If we did this right in QEMU, we'd have to introduce a QOM property
> anyway
... and then we'd have to update each firmware implementation to know
about this new property, and the how it translates to the RESET_REG
field in the DSDT, etc
On Tue, Jun 11, 2013 at 11:18:13AM +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 11, 2013 at 10:00:36AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > Yes and not just because of windows guests.
> > > ACPI spec is also very explicit that native hotplug is an optional
> > > feature. Test suites s
On Tue, Jun 11, 2013 at 10:00:36AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Yes and not just because of windows guests.
> > ACPI spec is also very explicit that native hotplug is an optional
> > feature. Test suites such as WHQL are known to test spec compliance.
>
> /me looks a bit surprised.
>
Hi,
> Yes and not just because of windows guests.
> ACPI spec is also very explicit that native hotplug is an optional
> feature. Test suites such as WHQL are known to test spec compliance.
/me looks a bit surprised.
This pretty much implies that any shpc bridge needs a second interface
to the
On Tue, Jun 11, 2013 at 09:42:29AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >>> Portability:
> >>> - Non x86 (or any Linux) platforms don't need any of this code.
> >>> They can keep happily using SHPC the way
> >>> they always did.
> >>
> >> Hmm. Is is possible to write a SHPC dri
Hi,
>>> Portability:
>>> - Non x86 (or any Linux) platforms don't need any of this code.
>>> They can keep happily using SHPC the way
>>> they always did.
>>
>> Hmm. Is is possible to write a SHPC driver in AML? I think it would be
>> alot better to have one guest/host interfac
On Mon, Jun 10, 2013 at 08:03:46PM -0500, Anthony Liguori wrote:
> >> 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
On Tue, Jun 11, 2013 at 07:33:02AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >* Use of glib's GArray makes it much easier to build
> > up tables in code without need for iasl and code patching
>
> Nice.
>
> > Design:
> > - each bus gets assigned a number 0-255
> > - genera
On Mon, Jun 10, 2013 at 08:25:15PM -0500, Anthony Liguori wrote:
> > I do understand your desire to pass this stuff as parameters, but I
> > really don't see it as feasible. I'm hoping that if you can write up
> > some examples with specifics you'll either enlighten me or you'll see
> > the diffic
Hi,
>* Use of glib's GArray makes it much easier to build
> up tables in code without need for iasl and code patching
Nice.
> Design:
> - each bus gets assigned a number 0-255
> - generated ACPI code writes this number
> to a new BSEL register, then uses existing
On Mon, Jun 10, 2013 at 01:58:41PM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
> > This adds support for device hotplug behind
> > pci bridges. Bridge devices themselves need
> > to be pre-configured on qemu command line.
> >
> > One of the goals of this project was to
> > demo
On Mon, Jun 10, 2013 at 08:25:15PM -0500, Anthony Liguori wrote:
> On Mon, Jun 10, 2013 at 8:19 PM, Kevin O'Connor wrote:
> > I do understand your desire to pass this stuff as parameters, but I
> > really don't see it as feasible. I'm hoping that if you can write up
> > some examples with specifi
On Mon, Jun 10, 2013 at 6:03 PM, Anthony Liguori wrote:
> On Mon, Jun 10, 2013 at 7:28 PM, Jordan Justen wrote:
>> 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 stopp
Hi Kevin,
On Mon, Jun 10, 2013 at 8:19 PM, Kevin O'Connor wrote:
> On Mon, Jun 10, 2013 at 07:51:55PM -0500, Anthony Liguori wrote:
>> I think that we can pretty much touch a table once pulling all of the
>> info from QOM and then from a SeaBIOS point of view, never have to
>> touch it again.
>
>
On Mon, Jun 10, 2013 at 07:51:55PM -0500, Anthony Liguori wrote:
> I think that we can pretty much touch a table once pulling all of the
> info from QOM and then from a SeaBIOS point of view, never have to
> touch it again.
Thanks. I do think it would help if you could go through the details
of a
Hi Jordan,
On Mon, Jun 10, 2013 at 7:28 PM, Jordan Justen wrote:
> On Mon, Jun 10, 2013 at 2:45 PM, Anthony Liguori
> 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, th
Hi Kevin,
On Mon, Jun 10, 2013 at 7:23 PM, Kevin O'Connor wrote:
> On Mon, Jun 10, 2013 at 06:34:29PM -0500, Anthony Liguori wrote:
>> Kevin O'Connor writes:
>>
>> For the MADT table, right now SeaBIOS needs the CPU count. That can be
>> found by counting the number of CPU nodes. Today cpus ar
On Mon, Jun 10, 2013 at 2:45 PM, Anthony Liguori wrote:
> OVMF is proprietary.
I don't agree that not-OSI means proprietary.
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
On Mon, Jun 10, 2013 at 06:34:29PM -0500, Anthony Liguori wrote:
> Kevin O'Connor writes:
>
> > On Mon, Jun 10, 2013 at 04:45:53PM -0500, Anthony Liguori wrote:
> >> This discussion comes down to two things I think: (a) our existing
> >> firmware interface is pretty poor (b) we are duplicating wo
David Woodhouse writes:
> On Mon, 2013-06-10 at 18:34 -0500, Anthony Liguori wrote:
>> Internally within QEMU, this initial discussion started by saying that
>> any ACPI generation within QEMU should happen strictly with QOM
>> methods. This was the crux of my argument, if QOM is the only
>> int
On Mon, 2013-06-10 at 18:34 -0500, Anthony Liguori wrote:
> Internally within QEMU, this initial discussion started by saying that
> any ACPI generation within QEMU should happen strictly with QOM
> methods. This was the crux of my argument, if QOM is the only
> interface we need, everything is th
Kevin O'Connor writes:
> On Mon, Jun 10, 2013 at 04:45:53PM -0500, Anthony Liguori wrote:
>> This discussion comes down to two things I think: (a) our existing
>> firmware interface is pretty poor (b) we are duplicating work because of
>> firmware licensing.
>>
>> We can fix (a) and there's lots
On Mon, Jun 10, 2013 at 04:45:53PM -0500, Anthony Liguori wrote:
> This discussion comes down to two things I think: (a) our existing
> firmware interface is pretty poor (b) we are duplicating work because of
> firmware licensing.
>
> We can fix (a) and there's lots of value in doing that in terms
Laszlo Ersek writes:
> On 06/10/13 21:57, Anthony Liguori wrote:
>> Laszlo Ersek writes:
>
>>
>> I don't understand this piece.
>>
>> Other than TianoCore being a weird environment, what made this more
>> difficult than it is to generate the tables in QEMU?
>
> QEMU can pass down two kinds of
Sorry about replying to myself...
On 06/10/13 22:43, Laszlo Ersek wrote:
> It's not a design purity argument, just what's cheaper.
You probably consider SMBIOS/ACPI table generation "guest code" that has
no place in the machine emulator. You're likely willing to expose the
needed bits on a case-
On 06/10/13 21:57, Anthony Liguori wrote:
> Laszlo Ersek writes:
>> Please take a look at my series for OVMF that adds basic support for
>> SMBIOS tables. It took me three days of basically uninterrupted coding
>> and two approaches to throw away until I got something submittable (with
>> default
Laszlo Ersek writes:
> On 06/10/13 20:58, Anthony Liguori wrote:
>> "Michael S. Tsirkin" writes:
>>
>>> This adds support for device hotplug behind
>>> pci bridges. Bridge devices themselves need
>>> to be pre-configured on qemu command line.
>>>
>>> One of the goals of this project was to
>>>
Peter Maydell writes:
> On 10 June 2013 19:58, Anthony Liguori 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-ve
On 06/10/13 20:58, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
>> This adds support for device hotplug behind
>> pci bridges. Bridge devices themselves need
>> to be pre-configured on qemu command line.
>>
>> One of the goals of this project was to
>> demonstrate the advantages of gen
On 10 June 2013 19:58, Anthony Liguori 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 par
"Michael S. Tsirkin" writes:
> This adds support for device hotplug behind
> pci bridges. Bridge devices themselves need
> to be pre-configured on qemu command line.
>
> One of the goals of this project was to
> demonstrate the advantages of generating
> ACPI tables in QEMU.
> In my opinion, it d
This adds support for device hotplug behind
pci bridges. Bridge devices themselves need
to be pre-configured on qemu command line.
One of the goals of this project was to
demonstrate the advantages of generating
ACPI tables in QEMU.
In my opinion, it does this successfully.
* This saves th
37 matches
Mail list logo
