Re: [SeaBIOS] KVM call agenda for 2013-06-11
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-06-11
"Michael S. Tsirkin" 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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-06-11
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-06-11
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
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. So we *still* end up having to update firmwares to keep up with qemu, much more than we would if we'd generated the tables on the qemu side. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
On Mon, 2013-06-10 at 20:03 -0500, Anthony Liguori wrote: > > > 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, as an Intel employee, I think I've done > > as much as I can to address this. > > > > 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 stopped listening to me about it. > > Is this useful? I can try to make noise. I assume since folks like > you who have much more credibility and familiarity in this space have > given up, it's a lost cause. I don't think it's a lost cause. It's not technically hard to implement a FAT driver. And the *bureaucracy* shouldn't be hard either. Distributions ship *lots* of FAT implementations already. The alleged patents on it, if there even *are* any left, are fraudulent. And don't apply in the Free World where I live either, to my knowledge. If we can ship FAT support in the Linux kernel, in mtools, and in various other things including BSD kernels, then we can damn well ship a UEFI module which implements FAT support. Saying that we can't do the latter, while simultaneously continuing to do the former, makes absolutely no sense. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] [wip] add xhci support
Release early, release often. Push to git head! On Tue, Jun 11, 2013 at 7:54 AM, Gerd Hoffmann wrote: > On 06/09/13 04:31, Kevin O'Connor wrote: > > On Fri, Jun 07, 2013 at 02:16:10PM +0200, Gerd Hoffmann wrote: > >> Very first revision doing something useful. Initializes xhci host > >> controller, detects devices, can handle control and bulk transfers. > >> Good enougth to boot from usb storage devices. > >> > >> To be done: > >> * Add support for interrupt transfers (needed for kbd+mouse). > >> * Add support for streams (needed for uas devices on usb3 ports). > >> * Add support for usb hubs. > >> > >> Tested on qemu only. > > > > Very nice! > > > > Did you wish to target the next release for this feature? > > Depends on how long it takes to finish it off, it's not ready for merge > yet. Posted this for (a) early code reviews and (b) to make people > aware I'm working on this. > > > If so, I > > think it would need to default to disabled. > > Sure. > > cheers, > Gerd > > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
