Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
under QEMU as it enforces protection, keep them in spare vectors of the
interrupt table, namely INT 0x80 and 0x81.
Signed-off-by: Jan Kiszka
---
Don't forget to update extboot.bin after merging both patches.
pc-bios/option
On 02/18/2010 10:13 AM, Jan Kiszka wrote:
Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
under QEMU as it enforces protection, keep them in spare vectors of the
interrupt table, namely INT 0x80 and 0x81.
Signed-off-by: Jan Kiszka
commit a4492b03932ea3c9762372f3e15e
On 02/18/2010 12:27 PM, Anthony Liguori wrote:
> On 02/18/2010 10:13 AM, Jan Kiszka wrote:
>> Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
>> under QEMU as it enforces protection, keep them in spare vectors of the
>> interrupt table, namely INT 0x80 and 0x81.
>>
>> Signed
H. Peter Anvin wrote:
> On 02/18/2010 12:27 PM, Anthony Liguori wrote:
>> On 02/18/2010 10:13 AM, Jan Kiszka wrote:
>>> Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
>>> under QEMU as it enforces protection, keep them in spare vectors of the
>>> interrupt table, namely INT
Jan Kiszka wrote:
Shall the protection start _before_ INT 19 or somewhere _while_ it is
processed? I'm asking as extboot redirect the handler and writes to some
variable in its own handler. If the protection is already active at this
point, we must move at least one of the variables out of the s
H. Peter Anvin wrote:
> Jan Kiszka wrote:
>> Shall the protection start _before_ INT 19 or somewhere _while_ it is
>> processed? I'm asking as extboot redirect the handler and writes to some
>> variable in its own handler. If the protection is already active at this
>> point, we must move at least
Jan Kiszka wrote:
Actually, I'm still in favor of proper (Sea)BIOS support for virtio and
scsi, either via the paravirt port 0x405 and its qemu backend or via
minimalistic support of the hardware directly in the BIOS. That would
free us from all those hooking and unhooking dances at least.
Th
H. Peter Anvin wrote:
> Jan Kiszka wrote:
>> Actually, I'm still in favor of proper (Sea)BIOS support for virtio and
>> scsi, either via the paravirt port 0x405 and its qemu backend or via
>> minimalistic support of the hardware directly in the BIOS. That would
>> free us from all those hooking and
On 02/19/2010 11:03 AM, Jan Kiszka wrote:
Actually, I'm still in favor of proper (Sea)BIOS support for virtio and
scsi, either via the paravirt port 0x405 and its qemu backend or via
minimalistic support of the hardware directly in the BIOS. That would
free us from all those hooking and unhooking
Anthony Liguori wrote:
> On 02/19/2010 11:03 AM, Jan Kiszka wrote:
>> Actually, I'm still in favor of proper (Sea)BIOS support for virtio and
>> scsi, either via the paravirt port 0x405 and its qemu backend or via
>> minimalistic support of the hardware directly in the BIOS. That would
>> free us f
On 02/19/2010 10:17 AM, Jan Kiszka wrote:
>>
>> Stefan posted a virtio-blk driver for gPXE. I like this approach
>> because it's generally useful (gPXE can be used with any BIOS).
>
> Does it allow a unified boot device selection, one menu for them all, no
> more "boot=on" workarounds?
>
Well,
On Fri, Feb 19, 2010 at 11:37:04AM -0800, H. Peter Anvin wrote:
> On 02/19/2010 10:17 AM, Jan Kiszka wrote:
> >>
> >> Stefan posted a virtio-blk driver for gPXE. I like this approach
> >> because it's generally useful (gPXE can be used with any BIOS).
> >
> > Does it allow a unified boot device
Kevin O'Connor wrote:
SeaBIOS does support BBS (both BEVs and BCVs). Also, under qemu,
SeaBIOS will run option roms with memory writable and then lock the
memory after the POST phase (as is required by the spec).
SeaBIOS also support PMM (both temporary allocations and the PCIv3
extensions for
On 02/18/2010 06:13 PM, Jan Kiszka wrote:
Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
under QEMU as it enforces protection, keep them in spare vectors of the
interrupt table, namely INT 0x80 and 0x81.
Applied both, thanks.
Don't forget to update extboot.bin af
Avi Kivity wrote:
> On 02/18/2010 06:13 PM, Jan Kiszka wrote:
>> Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
>> under QEMU as it enforces protection, keep them in spare vectors of the
>> interrupt table, namely INT 0x80 and 0x81.
>>
>>
>
> Applied both, thanks.
>
>
Current status of gPXE virtio support:
Virtio-net support has been in mainline gPXE since August 2008.
Virtio-blk patches exist and I'd like to get them merged so both types
of devices are supported.
These are PCI option ROMs and they have a BEV entry point to hook into
the boot menu. With SeaBI
Jan Kiszka wrote:
> Avi Kivity wrote:
>> On 02/18/2010 06:13 PM, Jan Kiszka wrote:
>>> Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
>>> under QEMU as it enforces protection, keep them in spare vectors of the
>>> interrupt table, namely INT 0x80 and 0x81.
>>>
>>>
>> Ap
On 02/22/2010 11:59 AM, Jan Kiszka wrote:
We don't carry a precompiled binary (well, we have
qemu/pc-bios/extboot.bin, but that's bogus and I've removed it).
You do:
qemu-kvm/qemu/pc-bios/extboot.bin (what is that for?)
Artifact, removed.
And as I had to copy the built extboot.bin
On 02/22/2010 02:03 AM, Stefan Hajnoczi wrote:
>
> These are PCI option ROMs and they have a BEV entry point to hook into
> the boot menu. With SeaBIOS BBS and PMM support the gPXE ROMs can
> provide your virtio support.
>
Typically a disk device would use a BCV, not a BEV.
-hpa
--
To
On Mon, Feb 22, 2010 at 7:42 PM, H. Peter Anvin wrote:
> Typically a disk device would use a BCV, not a BEV.
Laurent Vivier's virtio-blk patchset has BCV support. It is not yet
merged into gPXE:
http://markmail.org/message/oq2et3t3kzjzts7i
Stefan
--
To unsubscribe from this list: send the line
Avi Kivity wrote:
> On 02/18/2010 06:13 PM, Jan Kiszka wrote:
>> Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
>> under QEMU as it enforces protection, keep them in spare vectors of the
>> interrupt table, namely INT 0x80 and 0x81.
>>
>>
>
> Applied both, thanks.
For
21 matches
Mail list logo
