KVM call agenda for 2013-06-11

KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:

Agenda for the meeting Tue, June 11:
 
- Generating acpi tables, redux

Please, send any topic that you are interested in covering.

Thanks, MST

-- 
MST

[Qemu-devel] KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:

Agenda for the meeting Tue, June 11:
 
- Generating acpi tables, redux

Please, send any topic that you are interested in covering.

Thanks, MST

-- 
MST

Re: KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
> Juan is not available now, and Anthony asked for
> agenda to be sent early.
> So here comes:
> 
> Agenda for the meeting Tue, June 11:
>  
> - Generating acpi tables, redux

I've just posted a proof of concept patch on list,
as promised.

Since Anthony (apparently, alone?) is objecting to
this on principle I don't think there's need to spend
time testing it at this stage:

I'd like to use the meeting to discuss the requirements
coming from ACPI spec and how this patch
addresses them, and how generating the SSDT table
in qemu makes life easier, and would be awkward in
the bios.

Also, to address comments raised on the previous
conf call.

I hope that at the end of the meeting we'll be
able to arrive at concensus opinion
re the usefulness of supplying ACPI tables to
guests (on PC only).

> Please, send any topic that you are interested in covering.
> 
> Thanks, MST
> 
> -- 
> MST

Re: [Qemu-devel] KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
> Juan is not available now, and Anthony asked for
> agenda to be sent early.
> So here comes:
> 
> Agenda for the meeting Tue, June 11:
>  
> - Generating acpi tables, redux

I've just posted a proof of concept patch on list,
as promised.

Since Anthony (apparently, alone?) is objecting to
this on principle I don't think there's need to spend
time testing it at this stage:

I'd like to use the meeting to discuss the requirements
coming from ACPI spec and how this patch
addresses them, and how generating the SSDT table
in qemu makes life easier, and would be awkward in
the bios.

Also, to address comments raised on the previous
conf call.

I hope that at the end of the meeting we'll be
able to arrive at concensus opinion
re the usefulness of supplying ACPI tables to
guests (on PC only).

> Please, send any topic that you are interested in covering.
> 
> Thanks, MST
> 
> -- 
> MST

Re: KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
> Juan is not available now, and Anthony asked for
> agenda to be sent early.
> So here comes:
> 
> Agenda for the meeting Tue, June 11:
>  
> - Generating acpi tables, redux

Not so much notes as a quick summary of the call:

There are the following reasons to generate ACPI tables in QEMU:

- sharing code with e.g. ovmf
	Anthony thinks this is not a valid argument

- so we can make tables more dynamic and move away from iasl
	Anthony thinks this is not a valid reason too,
	since qemu and seabios have access to same info
	MST noted several info not accessible to bios.
	Anthony said they can be added, e.g. by exposing
	QOM to the bios.

- even though most tables are static, hardcoded
  they are likely to change over time
	Anthony sees this as justified

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 merged together with
  some new feature. I'm not sure the reasoning is clear:
  current a version intentionally generates tables
  that are bug for bug compatible with seabios,
  to simplify testing.

  It seems clear we have users for this such as
  hotplug of devices behind pci bridges, so
  why keep the infrastructure out of tree?

  Looking for something additional, smaller as the hotplug patch
  is a bit big, so might delay merging.


Going forward - would we want to move
smbios as well? Everyone seems to think it's a
good idea.

-- 
MST

Re: [Qemu-devel] KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
> Juan is not available now, and Anthony asked for
> agenda to be sent early.
> So here comes:
> 
> Agenda for the meeting Tue, June 11:
>  
> - Generating acpi tables, redux

Not so much notes as a quick summary of the call:

There are the following reasons to generate ACPI tables in QEMU:

- sharing code with e.g. ovmf
	Anthony thinks this is not a valid argument

- so we can make tables more dynamic and move away from iasl
	Anthony thinks this is not a valid reason too,
	since qemu and seabios have access to same info
	MST noted several info not accessible to bios.
	Anthony said they can be added, e.g. by exposing
	QOM to the bios.

- even though most tables are static, hardcoded
  they are likely to change over time
	Anthony sees this as justified

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 merged together with
  some new feature. I'm not sure the reasoning is clear:
  current a version intentionally generates tables
  that are bug for bug compatible with seabios,
  to simplify testing.

  It seems clear we have users for this such as
  hotplug of devices behind pci bridges, so
  why keep the infrastructure out of tree?

  Looking for something additional, smaller as the hotplug patch
  is a bit big, so might delay merging.


Going forward - would we want to move
smbios as well? Everyone seems to think it's a
good idea.

-- 
MST

Re: KVM call agenda for 2013-06-11

[Laszlo Ersek]

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 merged together with
>   some new feature. I'm not sure the reasoning is clear:
>   current a version intentionally generates tables
>   that are bug for bug compatible with seabios,
>   to simplify testing.

Sorry about not following the series more closely -- is there now a qemu
interface available that allows any firmware just take the tables, maybe
to fix them up blindly / algorithmically, and to install them?

IOW, is the interface at such a point that in OVMF we could start
looking throwing out specific code, in favor of implementing the generic
fw-side algorithm?

>   It seems clear we have users for this such as
>   hotplug of devices behind pci bridges, so
>   why keep the infrastructure out of tree?
> 
>   Looking for something additional, smaller as the hotplug patch
>   is a bit big, so might delay merging.
> 
> 
> Going forward - would we want to move
> smbios as well? Everyone seems to think it's a
> good idea.

I think the current fw_cfg interface for SMBIOS tables is already good
enough to save a lot of work in OVMF. Namely, if all required tables
were generated (table template + field-wise patching) in qemu, and then
all exported over fw_cfg as verbatim tables, my SMBIOS series currently
pending for OVMF should be able to install them.

This would save OVMF the coding of templates (and any necessary
patching) for types 3, 4 (especially nasty), 9, 16, 17, 19, and 32.
(Basically "all except type 0 and type 1", which are already implemented
(but verbatim tables from qemu would take priority even for type 0 and
type 1). Type 7 can be left out apparently; IIRC dmidecode doesn't
report it even under SeaBIOS.)

I'm not implying anyone should start working on this (myself included
:)), but yeah, moving SMBIOS would save work in OVMF. (Provided there
was any reason to support said SMBIOS tables in OVMF :))

Thanks,
Laszlo

Re: [Qemu-devel] KVM call agenda for 2013-06-11

[Laszlo Ersek]

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 merged together with
>   some new feature. I'm not sure the reasoning is clear:
>   current a version intentionally generates tables
>   that are bug for bug compatible with seabios,
>   to simplify testing.

Sorry about not following the series more closely -- is there now a qemu
interface available that allows any firmware just take the tables, maybe
to fix them up blindly / algorithmically, and to install them?

IOW, is the interface at such a point that in OVMF we could start
looking throwing out specific code, in favor of implementing the generic
fw-side algorithm?

>   It seems clear we have users for this such as
>   hotplug of devices behind pci bridges, so
>   why keep the infrastructure out of tree?
> 
>   Looking for something additional, smaller as the hotplug patch
>   is a bit big, so might delay merging.
> 
> 
> Going forward - would we want to move
> smbios as well? Everyone seems to think it's a
> good idea.

I think the current fw_cfg interface for SMBIOS tables is already good
enough to save a lot of work in OVMF. Namely, if all required tables
were generated (table template + field-wise patching) in qemu, and then
all exported over fw_cfg as verbatim tables, my SMBIOS series currently
pending for OVMF should be able to install them.

This would save OVMF the coding of templates (and any necessary
patching) for types 3, 4 (especially nasty), 9, 16, 17, 19, and 32.
(Basically "all except type 0 and type 1", which are already implemented
(but verbatim tables from qemu would take priority even for type 0 and
type 1). Type 7 can be left out apparently; IIRC dmidecode doesn't
report it even under SeaBIOS.)

I'm not implying anyone should start working on this (myself included
:)), but yeah, moving SMBIOS would save work in OVMF. (Provided there
was any reason to support said SMBIOS tables in OVMF :))

Thanks,
Laszlo

Re: KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

On Tue, Jun 11, 2013 at 08:06:15PM +0200, Laszlo Ersek wrote:
> 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 merged together with
> >   some new feature. I'm not sure the reasoning is clear:
> >   current a version intentionally generates tables
> >   that are bug for bug compatible with seabios,
> >   to simplify testing.
> 
> Sorry about not following the series more closely -- is there now a qemu
> interface available that allows any firmware just take the tables, maybe
> to fix them up blindly / algorithmically, and to install them?

Yes.

> IOW, is the interface at such a point that in OVMF we could start
> looking throwing out specific code, in favor of implementing the generic
> fw-side algorithm?
> 
> >   It seems clear we have users for this such as
> >   hotplug of devices behind pci bridges, so
> >   why keep the infrastructure out of tree?
> > 
> >   Looking for something additional, smaller as the hotplug patch
> >   is a bit big, so might delay merging.
> > 
> > 
> > Going forward - would we want to move
> > smbios as well? Everyone seems to think it's a
> > good idea.
> 
> I think the current fw_cfg interface for SMBIOS tables is already good
> enough to save a lot of work in OVMF. Namely, if all required tables
> were generated (table template + field-wise patching) in qemu, and then
> all exported over fw_cfg as verbatim tables, my SMBIOS series currently
> pending for OVMF should be able to install them.
> 
> This would save OVMF the coding of templates (and any necessary
> patching) for types 3, 4 (especially nasty), 9, 16, 17, 19, and 32.
> (Basically "all except type 0 and type 1", which are already implemented
> (but verbatim tables from qemu would take priority even for type 0 and
> type 1). Type 7 can be left out apparently; IIRC dmidecode doesn't
> report it even under SeaBIOS.)
> 
> I'm not implying anyone should start working on this (myself included
> :)), but yeah, moving SMBIOS would save work in OVMF. (Provided there
> was any reason to support said SMBIOS tables in OVMF :))
> 
> Thanks,
> Laszlo

Re: [Qemu-devel] KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

On Tue, Jun 11, 2013 at 08:06:15PM +0200, Laszlo Ersek wrote:
> 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 merged together with
> >   some new feature. I'm not sure the reasoning is clear:
> >   current a version intentionally generates tables
> >   that are bug for bug compatible with seabios,
> >   to simplify testing.
> 
> Sorry about not following the series more closely -- is there now a qemu
> interface available that allows any firmware just take the tables, maybe
> to fix them up blindly / algorithmically, and to install them?

Yes.

> IOW, is the interface at such a point that in OVMF we could start
> looking throwing out specific code, in favor of implementing the generic
> fw-side algorithm?
> 
> >   It seems clear we have users for this such as
> >   hotplug of devices behind pci bridges, so
> >   why keep the infrastructure out of tree?
> > 
> >   Looking for something additional, smaller as the hotplug patch
> >   is a bit big, so might delay merging.
> > 
> > 
> > Going forward - would we want to move
> > smbios as well? Everyone seems to think it's a
> > good idea.
> 
> I think the current fw_cfg interface for SMBIOS tables is already good
> enough to save a lot of work in OVMF. Namely, if all required tables
> were generated (table template + field-wise patching) in qemu, and then
> all exported over fw_cfg as verbatim tables, my SMBIOS series currently
> pending for OVMF should be able to install them.
> 
> This would save OVMF the coding of templates (and any necessary
> patching) for types 3, 4 (especially nasty), 9, 16, 17, 19, and 32.
> (Basically "all except type 0 and type 1", which are already implemented
> (but verbatim tables from qemu would take priority even for type 0 and
> type 1). Type 7 can be left out apparently; IIRC dmidecode doesn't
> report it even under SeaBIOS.)
> 
> I'm not implying anyone should start working on this (myself included
> :)), but yeah, moving SMBIOS would save work in OVMF. (Provided there
> was any reason to support said SMBIOS tables in OVMF :))
> 
> Thanks,
> Laszlo

Re: KVM call agenda for 2013-06-11

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
>> Juan is not available now, and Anthony asked for
>> agenda to be sent early.
>> So here comes:
>> 
>> Agenda for the meeting Tue, June 11:
>>  
>> - Generating acpi tables, redux
>
> Not so much notes as a quick summary of the call:
>
> There are the following reasons to generate ACPI tables in QEMU:
>
> - sharing code with e.g. ovmf
> 	Anthony thinks this is not a valid argument
>
> - so we can make tables more dynamic and move away from iasl
> 	Anthony thinks this is not a valid reason too,
> 	since qemu and seabios have access to same info
> 	MST noted several info not accessible to bios.
> 	Anthony said they can be added, e.g. by exposing
> 	QOM to the bios.
>
> - even though most tables are static, hardcoded
>   they are likely to change over time
> 	Anthony sees this as justified
>
> To summarize, there's a concensus now that generating ACPI
> tables in QEMU is a good idea.

I would say best worst idea ;-)

I am deeply concerned about the complexity it introduces but I don't see
many other options.

>
> Two issues that need to be addressed:
> - original patches break cross-version migration. Need to fix that.
>
> - Anthony requested that patchset is merged together with
>   some new feature. I'm not sure the reasoning is clear:
>   current a version intentionally generates tables
>   that are bug for bug compatible with seabios,
>   to simplify testing.

I expect that there will be additional issues that need to be worked out
and want to see a feature that actually uses the infrastructure before
we add it.

>   It seems clear we have users for this such as
>   hotplug of devices behind pci bridges, so
>   why keep the infrastructure out of tree?

It's hard to evaluate the infrastructure without a user.

>   Looking for something additional, smaller as the hotplug patch
>   is a bit big, so might delay merging.
>
>
> Going forward - would we want to move
> smbios as well? Everyone seems to think it's a
> good idea.

Yes, independent of ACPI, I think QEMU should be generating the SMBIOS
tables.

Regards,

Anthony Liguori

> -- 
> MST

Re: [Qemu-devel] KVM call agenda for 2013-06-11

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
>> Juan is not available now, and Anthony asked for
>> agenda to be sent early.
>> So here comes:
>> 
>> Agenda for the meeting Tue, June 11:
>>  
>> - Generating acpi tables, redux
>
> Not so much notes as a quick summary of the call:
>
> There are the following reasons to generate ACPI tables in QEMU:
>
> - sharing code with e.g. ovmf
> 	Anthony thinks this is not a valid argument
>
> - so we can make tables more dynamic and move away from iasl
> 	Anthony thinks this is not a valid reason too,
> 	since qemu and seabios have access to same info
> 	MST noted several info not accessible to bios.
> 	Anthony said they can be added, e.g. by exposing
> 	QOM to the bios.
>
> - even though most tables are static, hardcoded
>   they are likely to change over time
> 	Anthony sees this as justified
>
> To summarize, there's a concensus now that generating ACPI
> tables in QEMU is a good idea.

I would say best worst idea ;-)

I am deeply concerned about the complexity it introduces but I don't see
many other options.

>
> Two issues that need to be addressed:
> - original patches break cross-version migration. Need to fix that.
>
> - Anthony requested that patchset is merged together with
>   some new feature. I'm not sure the reasoning is clear:
>   current a version intentionally generates tables
>   that are bug for bug compatible with seabios,
>   to simplify testing.

I expect that there will be additional issues that need to be worked out
and want to see a feature that actually uses the infrastructure before
we add it.

>   It seems clear we have users for this such as
>   hotplug of devices behind pci bridges, so
>   why keep the infrastructure out of tree?

It's hard to evaluate the infrastructure without a user.

>   Looking for something additional, smaller as the hotplug patch
>   is a bit big, so might delay merging.
>
>
> Going forward - would we want to move
> smbios as well? Everyone seems to think it's a
> good idea.

Yes, independent of ACPI, I think QEMU should be generating the SMBIOS
tables.

Regards,

Anthony Liguori

> -- 
> MST

Re: KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

On Tue, Jun 11, 2013 at 01:38:11PM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
> >> Juan is not available now, and Anthony asked for
> >> agenda to be sent early.
> >> So here comes:
> >> 
> >> Agenda for the meeting Tue, June 11:
> >>  
> >> - Generating acpi tables, redux
> >
> > Not so much notes as a quick summary of the call:
> >
> > There are the following reasons to generate ACPI tables in QEMU:
> >
> > - sharing code with e.g. ovmf
> > 	Anthony thinks this is not a valid argument
> >
> > - so we can make tables more dynamic and move away from iasl
> > 	Anthony thinks this is not a valid reason too,
> > 	since qemu and seabios have access to same info
> > 	MST noted several info not accessible to bios.
> > 	Anthony said they can be added, e.g. by exposing
> > 	QOM to the bios.
> >
> > - even though most tables are static, hardcoded
> >   they are likely to change over time
> > 	Anthony sees this as justified
> >
> > To summarize, there's a concensus now that generating ACPI
> > tables in QEMU is a good idea.
> 
> I would say best worst idea ;-)
> 
> I am deeply concerned about the complexity it introduces but I don't see
> many other options.
> 
> >
> > Two issues that need to be addressed:
> > - original patches break cross-version migration. Need to fix that.
> >
> > - Anthony requested that patchset is merged together with
> >   some new feature. I'm not sure the reasoning is clear:
> >   current a version intentionally generates tables
> >   that are bug for bug compatible with seabios,
> >   to simplify testing.
> 
> I expect that there will be additional issues that need to be worked out
> and want to see a feature that actually uses the infrastructure before
> we add it.

So please look at it, that code has been posted.
See:
	[PATCH] qemu: piix: PCI bridge ACPI hotplug support

it does not seem to show any major issues to work out
besides the cross-version migration issue that we
know about.

> >   It seems clear we have users for this such as
> >   hotplug of devices behind pci bridges, so
> >   why keep the infrastructure out of tree?
> 
> It's hard to evaluate the infrastructure without a user.

But the user has been posted, even if there are still issues to work out
with it,  that should be enough to evaluate the infrastructure - the
user itself does not need to be merged for this.

So please evaluate and give feedback.

> >   Looking for something additional, smaller as the hotplug patch
> >   is a bit big, so might delay merging.
> >
> >
> > Going forward - would we want to move
> > smbios as well? Everyone seems to think it's a
> > good idea.
> 
> Yes, independent of ACPI, I think QEMU should be generating the SMBIOS
> tables.
> 
> Regards,
> 
> Anthony Liguori
> 
> > -- 
> > MST

Re: [Qemu-devel] KVM call agenda for 2013-06-11

[Michael S. Tsirkin]

On Tue, Jun 11, 2013 at 01:38:11PM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
> >> Juan is not available now, and Anthony asked for
> >> agenda to be sent early.
> >> So here comes:
> >> 
> >> Agenda for the meeting Tue, June 11:
> >>  
> >> - Generating acpi tables, redux
> >
> > Not so much notes as a quick summary of the call:
> >
> > There are the following reasons to generate ACPI tables in QEMU:
> >
> > - sharing code with e.g. ovmf
> > 	Anthony thinks this is not a valid argument
> >
> > - so we can make tables more dynamic and move away from iasl
> > 	Anthony thinks this is not a valid reason too,
> > 	since qemu and seabios have access to same info
> > 	MST noted several info not accessible to bios.
> > 	Anthony said they can be added, e.g. by exposing
> > 	QOM to the bios.
> >
> > - even though most tables are static, hardcoded
> >   they are likely to change over time
> > 	Anthony sees this as justified
> >
> > To summarize, there's a concensus now that generating ACPI
> > tables in QEMU is a good idea.
> 
> I would say best worst idea ;-)
> 
> I am deeply concerned about the complexity it introduces but I don't see
> many other options.
> 
> >
> > Two issues that need to be addressed:
> > - original patches break cross-version migration. Need to fix that.
> >
> > - Anthony requested that patchset is merged together with
> >   some new feature. I'm not sure the reasoning is clear:
> >   current a version intentionally generates tables
> >   that are bug for bug compatible with seabios,
> >   to simplify testing.
> 
> I expect that there will be additional issues that need to be worked out
> and want to see a feature that actually uses the infrastructure before
> we add it.

So please look at it, that code has been posted.
See:
	[PATCH] qemu: piix: PCI bridge ACPI hotplug support

it does not seem to show any major issues to work out
besides the cross-version migration issue that we
know about.

> >   It seems clear we have users for this such as
> >   hotplug of devices behind pci bridges, so
> >   why keep the infrastructure out of tree?
> 
> It's hard to evaluate the infrastructure without a user.

But the user has been posted, even if there are still issues to work out
with it,  that should be enough to evaluate the infrastructure - the
user itself does not need to be merged for this.

So please evaluate and give feedback.

> >   Looking for something additional, smaller as the hotplug patch
> >   is a bit big, so might delay merging.
> >
> >
> > Going forward - would we want to move
> > smbios as well? Everyone seems to think it's a
> > good idea.
> 
> Yes, independent of ACPI, I think QEMU should be generating the SMBIOS
> tables.
> 
> Regards,
> 
> Anthony Liguori
> 
> > -- 
> > MST