Anthony Liguori wrote:
Sebastian Herbszt wrote:
What about isapc? Or (pci)pc with isa card?
I'm not sure how the bios enumerates isa option roms on bare metal.
Let's give this a shot:
A typical isa expansion card seems to have a jumper to select a I/O port, IRQ
and
boot rom location, e.g
Gerd Hoffmann wrote:
On 12/15/09 23:51, Sebastian Herbszt wrote:
Qemu will map rom1.bin to PC_ROM_MIN_OPTION (0xc8000) and map rom2.bin
to 0xd.
No.
rom1.bin will be loaded to max(0xc8000, 0xc + cirrus-bios-size)
aligned to 2k, which (with cirrus) is 0xc9.
My bad - for some reaso
struct fw_files {
u32 filecount;
struct fw_file {
u32 type;/* vga, option, other? */
u32 size;/* file size */
u32 select; /* write this to 0x510 to read it */
u32 reserved;/* you never know ;) */
char name[16];/* maybe: filenam
On Thu, Dec 17, 2009 at 10:45:45AM +0100, Gerd Hoffmann wrote:
> On 12/17/09 02:24, Kevin O'Connor wrote:
>> On Wed, Dec 16, 2009 at 05:22:41PM +0100, Gerd Hoffmann wrote:
>> The current "CBFS" mechanism looks for named "files" of the following
>> form:
>>
>> - pci,.rom - a rom associated w
On 12/17/09 02:24, Kevin O'Connor wrote:
On Wed, Dec 16, 2009 at 05:22:41PM +0100, Gerd Hoffmann wrote:
The current "CBFS" mechanism looks for named "files" of the following
form:
- pci,.rom - a rom associated with a PCI device with the given
vendor and device id.
Might be useful fo
On Wed, Dec 16, 2009 at 05:22:41PM +0100, Gerd Hoffmann wrote:
>> Right now, qemu cfg uses two ports - a file select port (0x510) and a
>> data port (0x511). Perhaps two new ports could be added - a file name
>> port (0x0512) and a file length port (0x513).
>>
>> Basically, if there is some way fo
Right now, qemu cfg uses two ports - a file select port (0x510) and a
data port (0x511). Perhaps two new ports could be added - a file name
port (0x0512) and a file length port (0x513).
Basically, if there is some way for SeaBIOS to walk a list of "files"
in the "qemu cfg" space, then it should
On Wed, Dec 16, 2009 at 04:41:33PM +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 16, 2009 at 03:41:22PM +0100, Gerd Hoffmann wrote:
> > On 12/15/09 22:41, Anthony Liguori wrote:
> >> BTW, I'm pretty sure this style of option rom loading (from a PCI
> >> device) is going to be required for device p
On 12/15/09 23:51, Sebastian Herbszt wrote:
Qemu will map rom1.bin to PC_ROM_MIN_OPTION (0xc8000) and map rom2.bin
to 0xd.
No.
rom1.bin will be loaded to max(0xc8000, 0xc + cirrus-bios-size)
aligned to 2k, which (with cirrus) is 0xc9.
rom2.bin will be loaded after rom1.bin (also 2
On Wed, Dec 16, 2009 at 03:41:22PM +0100, Gerd Hoffmann wrote:
> On 12/15/09 22:41, Anthony Liguori wrote:
>> BTW, I'm pretty sure this style of option rom loading (from a PCI
>> device) is going to be required for device passthrough if we want to
>> support running those roms in the guests.
>
> We
On 12/15/09 22:41, Anthony Liguori wrote:
BTW, I'm pretty sure this style of option rom loading (from a PCI
device) is going to be required for device passthrough if we want to
support running those roms in the guests.
Well, qemu-kvm has quite some code to poke the rom out of /proc/bus/pci
and
On Wed, Dec 16, 2009 at 04:28:49PM +0200, Gleb Natapov wrote:
> On Wed, Dec 16, 2009 at 04:24:59PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Dec 16, 2009 at 04:18:49PM +0200, Gleb Natapov wrote:
> > > On Wed, Dec 16, 2009 at 04:15:16PM +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Dec 16, 200
On Wed, Dec 16, 2009 at 04:24:59PM +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 16, 2009 at 04:18:49PM +0200, Gleb Natapov wrote:
> > On Wed, Dec 16, 2009 at 04:15:16PM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Dec 16, 2009 at 04:17:11PM +0200, Gleb Natapov wrote:
> > > > On Wed, Dec 16, 200
On Wed, Dec 16, 2009 at 04:18:49PM +0200, Gleb Natapov wrote:
> On Wed, Dec 16, 2009 at 04:15:16PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Dec 16, 2009 at 04:17:11PM +0200, Gleb Natapov wrote:
> > > On Wed, Dec 16, 2009 at 09:12:21AM -0500, Kevin O'Connor wrote:
> > > > On Wed, Dec 16, 2009 at
On Wed, Dec 16, 2009 at 04:15:16PM +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 16, 2009 at 04:17:11PM +0200, Gleb Natapov wrote:
> > On Wed, Dec 16, 2009 at 09:12:21AM -0500, Kevin O'Connor wrote:
> > > On Wed, Dec 16, 2009 at 03:52:34PM +0200, Michael S. Tsirkin wrote:
> > > > I am mostly conce
On Wed, Dec 16, 2009 at 04:17:11PM +0200, Gleb Natapov wrote:
> On Wed, Dec 16, 2009 at 09:12:21AM -0500, Kevin O'Connor wrote:
> > On Wed, Dec 16, 2009 at 03:52:34PM +0200, Michael S. Tsirkin wrote:
> > > I am mostly concerned with migrating between qemu versions with
> > > different roms, while g
On Wed, Dec 16, 2009 at 09:12:21AM -0500, Kevin O'Connor wrote:
> On Wed, Dec 16, 2009 at 03:52:34PM +0200, Michael S. Tsirkin wrote:
> > I am mostly concerned with migrating between qemu versions with
> > different roms, while guest was in the middle of running ROM.
> > This might be solved if we
On Wed, Dec 16, 2009 at 09:12:21AM -0500, Kevin O'Connor wrote:
> On Wed, Dec 16, 2009 at 03:52:34PM +0200, Michael S. Tsirkin wrote:
> > I am mostly concerned with migrating between qemu versions with
> > different roms, while guest was in the middle of running ROM.
> > This might be solved if we
On Wed, Dec 16, 2009 at 03:52:34PM +0200, Michael S. Tsirkin wrote:
> I am mostly concerned with migrating between qemu versions with
> different roms, while guest was in the middle of running ROM.
> This might be solved if we migrated ROM content together with
> the device and put some padding in
On Wed, Dec 16, 2009 at 02:42:51PM +0100, Gerd Hoffmann wrote:
> Hi,
>
>> What will happen when we find a bug in one of ROMs
>> I wonder? I think we will need to keep the old ROM
>> around, and put it in as part of compat machine type?
>
> What do you want?
> Old way to load the rom?
> Old rom bi
Hi,
What will happen when we find a bug in one of ROMs
I wonder? I think we will need to keep the old ROM
around, and put it in as part of compat machine type?
What do you want?
Old way to load the rom?
Old rom binaries (i.e. etherboot)?
Both?
The new way to load the roms is a guest-visible
Hi,
Basically, if there is some way for SeaBIOS to walk a list of "files"
in the "qemu cfg" space, then it should be straight forward to enhance
the existing code in seabios to extract and deploy roms in addition to
those found in the PCI bar.
I think using fw_config is the only sane way to
On 12/16/09 05:29, Kevin O'Connor wrote:
On Tue, Dec 15, 2009 at 10:24:29PM +0100, Sebastian Herbszt wrote:
Keep loading custom roms (e.g. from -option-rom) with rom_add_file
starting at 0xc8000. Modify SeaBIOS to scan the memory range for
pre-deployed option roms before deploying PCI roms. Sea
On Tue, Dec 15, 2009 at 03:41:02PM -0600, Anthony Liguori wrote:
> SeaBIOS can also load roms from up to two fixed physical addresses (when
> !CONFIG_OPTIONROMS_DEPLOYED) or from a CBFS payload.
The support for loading of two static option roms wont work well for
qemu - it requires compiling in
On Tue, Dec 15, 2009 at 10:24:29PM +0100, Sebastian Herbszt wrote:
> Keep loading custom roms (e.g. from -option-rom) with rom_add_file
> starting at 0xc8000. Modify SeaBIOS to scan the memory range for
> pre-deployed option roms before deploying PCI roms. SeaBIOS will
> find the last pre-deployed
On Tue, Dec 15, 2009 at 06:41:33PM -0600, Anthony Liguori wrote:
> Kevin OConnor wrote:
>> SeaBIOS is currently using over 64K of space. So, it is extending
>> into the e-segment and thus needs to have the e-segment copied
>> properly (I missed that in my earlier email).
>
> Okay. So I assume thi
Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
BTW, I'm pretty sure this style of option rom loading (from a PCI
device) is going to be required for device passthrough if we want to
support running those roms in the guests.
I think so too.
In fact, it should
Kevin OConnor wrote:
On Tue, Dec 15, 2009 at 12:35 PM, Anthony Liguori
mailto:anth...@codemonkey.ws>> wrote:
Avi Kivity wrote:
bochs bios required all 128kB, so this is probably a leftover.
This is apparently well defined in the PIIX spec. There is a bit
of a difference
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> BTW, I'm pretty sure this style of option rom loading (from a PCI
> device) is going to be required for device passthrough if we want to
> support running those roms in the guests.
I think so too.
> In fact, it should Just
> Work with my patches
On Tue, Dec 15, 2009 at 12:35 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> bochs bios required all 128kB, so this is probably a leftover.
>>
>
> This is apparently well defined in the PIIX spec. There is a bit of a
> difference between the lower half and upper half of the BIOS region thoug
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
I think it's stable-0.12 material because it's badly broken right now
I thought the rule was no guest visible changes in stable series?
Yeah, good point, so we need to figure out something for 0.12.0.
Sebastian's suggestion of loadin
Michael S. Tsirkin wrote:
I think it's stable-0.12 material because it's badly broken right now
I thought the rule was no guest visible changes in stable series?
Yeah, good point, so we need to figure out something for 0.12.0.
Sebastian's suggestion of loading roms from 0xc firs
On Tue, Dec 15, 2009 at 03:57:30PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>>> Heh, this is going to be really broken with my patches :-)
>>>
>>> We're during qemu_ram_alloc() and we currently don't have a means to
>>> associate ram with anything meaningful. This means that if
Sebastian Herbszt wrote:
What about isapc? Or (pci)pc with isa card?
I'm not sure how the bios enumerates isa option roms on bare metal.
That said, I don't know that it's all that important to support
-option-rom, -kernel, or extboot on isapc.
The isa version of cirrus-vga will still load
Michael S. Tsirkin wrote:
Heh, this is going to be really broken with my patches :-)
We're during qemu_ram_alloc() and we currently don't have a means to
associate ram with anything meaningful. This means that if you hot plug
on two ends in different orders (even with fixed slots), the retu
On Tue, Dec 15, 2009 at 03:45:24PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Tue, Dec 15, 2009 at 01:21:38PM -0600, Anthony Liguori wrote:
>>
>>> Gerd Hoffmann wrote:
>>>
On 12/15/09 03:37, Anthony Liguori wrote:
> Okay, I think I've figured out ho
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 01:21:38PM -0600, Anthony Liguori wrote:
Gerd Hoffmann wrote:
On 12/15/09 03:37, Anthony Liguori wrote:
Okay, I think I've figured out how this is supposed to work. With these
two patches to SeaBIOS and the patch to qemu, I can r
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 01:35:52PM -0600, Anthony Liguori wrote:
Gerd Hoffmann wrote:
-kernel didn't work on a quick test.
Thinking about how to fix this, we have two options.
Hmm, can you pls explain why it stops working?
Sure. SeaBIOS loa
Anthony Liguori wrote:
Sebastian Herbszt wrote:
Anthony Liguori wrote:
Gerd Hoffmann wrote:
I'm more worried about the CONFIG_OPTIONROMS_DEPLOYED patches for
seabios, although I don't fully understand what they are doing.
There are non-pci option roms (linuxboot, multiboot, extboot) which
q
Sebastian Herbszt wrote:
Anthony Liguori wrote:
Gerd Hoffmann wrote:
I'm more worried about the CONFIG_OPTIONROMS_DEPLOYED patches for
seabios, although I don't fully understand what they are doing.
There are non-pci option roms (linuxboot, multiboot, extboot) which
qemu will continue to dep
Anthony Liguori wrote:
Gerd Hoffmann wrote:
I'm more worried about the CONFIG_OPTIONROMS_DEPLOYED patches for
seabios, although I don't fully understand what they are doing. There
are non-pci option roms (linuxboot, multiboot, extboot) which qemu
will continue to deploy the way roms are deplo
On Tue, Dec 15, 2009 at 01:21:38PM -0600, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> On 12/15/09 03:37, Anthony Liguori wrote:
>>> Okay, I think I've figured out how this is supposed to work. With these
>>> two patches to SeaBIOS and the patch to qemu, I can run:
>>>
>>> qemu -net nic,model=r
On Tue, Dec 15, 2009 at 01:35:52PM -0600, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> -kernel didn't work on a quick test.
>
> Thinking about how to fix this, we have two options.
Hmm, can you pls explain why it stops working?
> The first would be
> to use the support in SeaBIOS for static
Gerd Hoffmann wrote:
-kernel didn't work on a quick test.
Thinking about how to fix this, we have two options. The first would be
to use the support in SeaBIOS for static roms but that would limit us to
two user supplied option roms (including kernel/multiboot/extboot). We
could extend thi
Gerd Hoffmann wrote:
On 12/15/09 03:37, Anthony Liguori wrote:
Okay, I think I've figured out how this is supposed to work. With these
two patches to SeaBIOS and the patch to qemu, I can run:
qemu -net nic,model=rtl8139 -net nic,model=virtio -net nic,model=e1000
-boot menu=on
And all three opt
Gerd Hoffmann wrote:
Hi,
We could also add a "romfile" property to the pci bus and do everything
(except setting the default filename) in generic pci code.
Patch attached (incremental to yours).
Sounds great, but no patch is attached.
Regards,
Anthony Liguori
Anthony Liguori wrote:
Michael S. Tsirkin wrote:
From a quick overview, I see register memory but no unregister?
There's no cpu_unregister_physical_memory() in qemu. Devices can
unregister an io memory type but this is not io memory, this is ram.
We should qemu_ram_free() though.
Exce
Michael S. Tsirkin wrote:
From a quick overview, I see register memory but no unregister?
There's no cpu_unregister_physical_memory() in qemu. Devices can
unregister an io memory type but this is not io memory, this is ram.
We should qemu_ram_free() though.
Regards,
Anthony Liguori
Avi Kivity wrote:
On 12/15/2009 04:20 PM, Anthony Liguori wrote:
Anthony Liguori wrote:
The bios gets mapped in 0xe .. 0x10 so if SeaBIOS fills the
0xc-0xf space it will write over half of the bios.
I'm a little confused by this. SeaBIOS seems to assume that it only
has to
On 12/15/2009 04:20 PM, Anthony Liguori wrote:
Anthony Liguori wrote:
The bios gets mapped in 0xe .. 0x10 so if SeaBIOS fills the
0xc-0xf space it will write over half of the bios.
I'm a little confused by this. SeaBIOS seems to assume that it only
has to deal with the 0xf0
Anthony Liguori wrote:
The bios gets mapped in 0xe .. 0x10 so if SeaBIOS fills the
0xc-0xf space it will write over half of the bios.
I'm a little confused by this. SeaBIOS seems to assume that it only has
to deal with the 0xf .. 0x10 space as the bios which is
cert
Gerd Hoffmann wrote:
On 12/15/09 03:37, Anthony Liguori wrote:
Okay, I think I've figured out how this is supposed to work. With these
two patches to SeaBIOS and the patch to qemu, I can run:
qemu -net nic,model=rtl8139 -net nic,model=virtio -net nic,model=e1000
-boot menu=on
And all three opt
Kevin O'Connor wrote:
On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
Okay, I think I've figured out how this is supposed to work. With these
two patches to SeaBIOS and the patch to qemu, I can run:
I'm not sure why "Do not guard qemu shadow ram work around in
CONFIG
On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 02:44:34PM -0600, Anthony Liguori wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
Or, we could have a very small ROM, that loads
more actual code from card or from q
Hi,
We could also add a "romfile" property to the pci bus and do everything
(except setting the default filename) in generic pci code.
Patch attached (incremental to yours).
I'm more worried about the CONFIG_OPTIONROMS_DEPLOYED patches for
seabios, although I don't fully understand what th
On 12/15/09 03:37, Anthony Liguori wrote:
Okay, I think I've figured out how this is supposed to work. With these
two patches to SeaBIOS and the patch to qemu, I can run:
qemu -net nic,model=rtl8139 -net nic,model=virtio -net nic,model=e1000
-boot menu=on
And all three option roms load. I can a
On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
> Okay, I think I've figured out how this is supposed to work. With these
> two patches to SeaBIOS and the patch to qemu, I can run:
I'm not sure why "Do not guard qemu shadow ram work around in
CONFIG_OPTIONROMS_DEPLOYED" patch i
On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
> Okay, I think I've figured out how this is supposed to work. With these
> two patches to SeaBIOS and the patch to qemu, I can run:
Yes - I think this is the best way to fix this. Space optimizations
can be most easily done by a
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:44:34PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Or, we could have a very small ROM, that loads
more actual code from card or from qemu directly
when it is run.
It's not as simple as it sounds but it's possib
59 matches
Mail list logo
