In QEMU, we set the firmware name of pc-i440fx to 'pci', and the
typename 'q35-pcihost' is set to the firmware name of q35 by default.
The seabios matches pci devices by "/pci/@i0cf8", so q35 device
could not be identified, seabios fails to adjust the boot priority
of q35 devices.
This patch sets
On Thu, May 30, 2013 at 09:09:05AM +0300, Michael S. Tsirkin wrote:
> On Thu, May 30, 2013 at 10:47:48AM +0800, Amos Kong wrote:
> > In QEMU, we set the firmware name of pc-i440fx is 'pci', and set the
> > firmware name of q35 is 'q35-pcihost'.
> >
> > The seabios pattern matching code isn't sophi
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 run seabios on real hardware and has
> DEBUG_I
On Thu, May 30, 2013 at 03:25:17PM +0800, Amos Kong wrote:
> In QEMU, we set the firmware name of pc-i440fx to 'pci', and the
> typename 'q35-pcihost' is set to the firmware name of q35 by default.
>
> The seabios matches pci devices by "/pci/@i0cf8", so q35 device
> could not be identified, seabi
On Thu, May 30, 2013 at 03:25:17PM +0800, Amos Kong wrote:
> In QEMU, we set the firmware name of pc-i440fx to 'pci', and the
> typename 'q35-pcihost' is set to the firmware name of q35 by default.
>
> The seabios matches pci devices by "/pci/@i0cf8", so q35 device
> could not be identified, seabi
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
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 ever plausibly use besides OVMF and SeaBIOS?
I li
Gerd Hoffmann wrote:
> Allow selecting DEBUG_IO for non-qemu configurations,
> which is useful when running coreboot+seabios on qemu.
>
> [ v2: QEMU_HARDWARE is even better as DEBUG_IO default value ]
> [ v3: make QEMU_HARDWARE usage consistent with other config
> options, fix spellings in c
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 Thu, May 30, 2013 at 01:19:18PM +0100, 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,
Hopefully this is not yet set in st
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
- Original Message -
> From: "Kevin O'Connor"
> To: "Dave Frodin"
> Cc: "seabios"
> Sent: Saturday, May 25, 2013 10:47:42 AM
> Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option
> ROMs to one
>
> On Fri, May 24, 2013 at 09:06:54AM -0500, Dave Frodin wrote:
>
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
> Where is CorebootPkg available from?
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
> > And it helps to dispel the stupid misconception in some quarters that
> > Coreboot *competes* with UEFI and thus cannot possibly be supported
> > bec
On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG wrote:
> Am 29.05.2013 09:56, schrieb Amos Kong:
> > Recent virtio refactoring in QEMU made virtio-bus become the parent bus
> > of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
> > typename will be added
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse wrote:
> On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
>> Where is CorebootPkg available from?
>
> https://github.com/pgeorgi/edk2/tree/coreboot-pkg
Is the license on this actually BSD as the License.txt indicates?
Is this planned to be u
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 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 that best
>> understands the actual hardware layout for the machine. In qemu, I
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 that best
>>> understands the actua
On Thu, May 30, 2013 at 09:20:42AM -0700, Jordan Justen wrote:
> On Thu, May 30, 2013 at 5:19 AM, David Woodhouse wrote:
> > On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
> >> Where is CorebootPkg available from?
> >
> > https://github.com/pgeorgi/edk2/tree/coreboot-pkg
>
> Is the licens
On Thu, May 30, 2013 at 09:57:10AM -0700, 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 that best
On Thu, May 30, 2013 at 10:30:21PM +0200, Stefan Priebe wrote:
> Am 30.05.2013 15:13, schrieb Amos Kong:
> >On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG wrote:
> >>Am 29.05.2013 09:56, schrieb Amos Kong:
> >>>Recent virtio refactoring in QEMU made virtio-bus become the par
Am 29.05.2013 09:56, schrieb Amos Kong:
> Recent virtio refactoring in QEMU made virtio-bus become the parent bus
> of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
> typename will be added to fw_dev_path by default, the new fw_dev_path
> could not be identified by seabios.
Am 30.05.2013 15:13, schrieb Amos Kong:
On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG wrote:
Am 29.05.2013 09:56, schrieb Amos Kong:
Recent virtio refactoring in QEMU made virtio-bus become the parent bus
of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implemen
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 when running coreboot+seabios on qemu.
> >
>
On Thu, May 30, 2013 at 07:49:36AM -0500, Dave Frodin wrote:
> > From: "Kevin O'Connor"
> > --- a/src/optionroms.c
> > +++ b/src/optionroms.c
> > @@ -178,10 +178,19 @@ deploy_romfile(struct romfile_s *file)
> > static struct rom_header *
> > lookup_hardcode(struct pci_device *pci)
> > {
> > -
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> There were discussions on potentially introducing a middle component
> to generate the tables. Coreboot was raised as a possibility, and
> David thought it would be okay to use coreboot for both OVMF and
> SeaBIOS. The possibility
Am 31.05.2013 00:51, schrieb Amos Kong:
> On Thu, May 30, 2013 at 10:30:21PM +0200, Stefan Priebe wrote:
>> Am 30.05.2013 15:13, schrieb Amos Kong:
>>> On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG
>>> wrote:
Am 29.05.2013 09:56, schrieb Amos Kong:
> Recent virtio
27 matches
Mail list logo
