qemu-kvm: Inconsistent vgabios reference

Hi all,

the vgabios hash qemu-kvm points to does not exist in the referenced repository. I was trying to find out the status of qemu-kvm's bios binaries and relevance of what is in the kvm/ folder. Looks like this is "a bit" messy...

Quoted 6 lines · Jan Kiszka

Hi all,

the vgabios hash qemu-kvm points to does not exist in the referenced repository. I was trying to find out the status of qemu-kvm's bios binaries and relevance of what is in the kvm/ folder. Looks like this is "a bit" messy...

I have 19ea12c230ded95 for that hash, and pushing it tells me everything is up to date. What hash do you see?

Quoted 8 lines · Avi Kivity

Quoted 6 lines · Jan Kiszka

Hi all,

the vgabios hash qemu-kvm points to does not exist in the referenced repository. I was trying to find out the status of qemu-kvm's bios binaries and relevance of what is in the kvm/ folder. Looks like this is "a bit" messy...

Quoted 2 lines

I have 19ea12c230ded95 for that hash, and pushing it tells me everything is up to date. What hash do you see?

qemu-kvm master points to ca056d8e77a534f4f90548bc8cee166a378c1454, after f6f8864b9b3ae1ea151c2b781792a5e72baaa178 I think.

Quoted 12 lines · Jan Kiszka

Quoted 10 lines · Avi Kivity

Quoted 6 lines · Jan Kiszka

Hi all,

the vgabios hash qemu-kvm points to does not exist in the referenced repository. I was trying to find out the status of qemu-kvm's bios binaries and relevance of what is in the kvm/ folder. Looks like this is "a bit" messy...

I have 19ea12c230ded95 for that hash, and pushing it tells me everything is up to date. What hash do you see?

Quoted 3 lines

qemu-kvm master points to ca056d8e77a534f4f90548bc8cee166a378c1454, after f6f8864b9b3ae1ea151c2b781792a5e72baaa178 I think.

Ah, yes, I was behind. Somehow 'git submodule update' found the new commit from me, and it's pushed now. Please try again after waiting for git.kernel.org to catch up.

OK, thanks.

As that repos is now the vgabios reference, nothing valuable can be lost when we drop the kvm/ folder, right?

Quoted 5 lines · Jan Kiszka

OK, thanks.

As that repos is now the vgabios reference, nothing valuable can be lost when we drop the kvm/ folder, right?

I guess so.

What about extboot w/ -M pc-0.foo? I guess we'll boot with a newer seabios in any case, but we probably will have boot order issues. Maybe we should make boot=on talk to the boot order code.

Quoted 7 lines · Avi Kivity

Quoted 5 lines · Jan Kiszka

OK, thanks.

As that repos is now the vgabios reference, nothing valuable can be lost when we drop the kvm/ folder, right?

Quoted 5 lines

I guess so.

What about extboot w/ -M pc-0.foo? I guess we'll boot with a newer seabios in any case, but we probably will have boot order issues. Maybe we should make boot=on talk to the boot order code.

extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad

Quoted 14 lines · Jan Kiszka

Quoted 12 lines · Avi Kivity

Quoted 5 lines · Jan Kiszka

OK, thanks.

As that repos is now the vgabios reference, nothing valuable can be lost when we drop the kvm/ folder, right?

I guess so.

What about extboot w/ -M pc-0.foo? I guess we'll boot with a newer seabios in any case, but we probably will have boot order issues. Maybe we should make boot=on talk to the boot order code.

Quoted 2 lines

extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad

Yeah, but it isn't history for people running older qemu-kvm's. We don't need extboot itself, but we do need to keep the boot option (as 2a06 does). The question is do we need to preserve its meaning too (with the seabios implementation instead of extboot's).

Quoted 4 lines

Yeah, but it isn't history for people running older qemu-kvm's. We don't need extboot itself, but we do need to keep the boot option (as 2a06 does). The question is do we need to preserve its meaning too (with the seabios implementation instead of extboot's).

Possibly. But that is unrelated to any of the historic bits in kvm/.

On 01/15/2012 02:50 PM, Jan Kiszka wrote:

Quoted 1 line

extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad

Yeah, but it isn't history for people running older qemu-kvm's. We don't need extboot itself, but we do need to keep the boot option (as 2a06 does). The question is do we need to preserve its meaning too (with the seabios implementation instead of extboot's).

Quoted 1 line · Avi Kivity

On 01/15/2012 02:50 PM, Jan Kiszka wrote:

[]

Quoted 6 lines

Quoted 1 line

extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad

Yeah, but it isn't history for people running older qemu-kvm's. We don't need extboot itself, but we do need to keep the boot option (as 2a06 does). The question is do we need to preserve its meaning too (with the seabios implementation instead of extboot's).

FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff.

Now, I've a question: what seabios implementation of extboot we're talking about? -option-rom which is impossible to select as a first boot device?

On 01/15/2012 03:10 PM, Michael Tokarev wrote:

Quoted 5 lines

FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff.

It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will feature virtio-scsi, though of course that doesn't help already installed guests or non Windows/Linux guests. Do you know what the use cases requiring scsi boot are?

Quoted 3 lines

Now, I've a question: what seabios implementation of extboot we're talking about? -option-rom which is impossible to select as a first boot device?

seabios has native support for booting from virtio-blk, and will natively support virtio-scsi as well.

Quoted 1 line · Avi Kivity

On 01/15/2012 03:10 PM, Michael Tokarev wrote:

[]

Quoted 10 lines

Quoted 5 lines

FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff.

It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will feature virtio-scsi, though of course that doesn't help already installed guests or non Windows/Linux guests. Do you know what the use cases requiring scsi boot are?

I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447
and a few private messages asking me for ways to restore booting from scsi, all talking about older/custom systems which worked for years in kvm. As you can see in the bugreport mentioned, I know that scsi is broken and should not be used and so on, and suggested switching from it on every chance.

Quoted 4 lines

Quoted 3 lines

Now, I've a question: what seabios implementation of extboot we're talking about? -option-rom which is impossible to select as a first boot device?

Quoted 2 lines

seabios has native support for booting from virtio-blk, and will natively support virtio-scsi as well.

Ah. Well, I thought especially about lsi emulated scsi. I wasn't able to boot from it even with their bios -- once there's at least one other bootable device present (including the NIC) it refuses to boot from lsi emulated scsi drive.

Quoted 1 line · Avi Kivity

On 01/15/2012 03:10 PM, Michael Tokarev wrote:

[]

Quoted 10 lines

Quoted 5 lines

FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff.

It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will feature virtio-scsi, though of course that doesn't help already installed guests or non Windows/Linux guests. Do you know what the use cases requiring scsi boot are?

I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447
and a few private messages asking me for ways to restore booting from scsi, all talking about older/custom systems which worked for years in kvm. As you can see in the bugreport mentioned, I know that scsi is broken and should not be used and so on, and suggested switching from it on every chance.

Quoted 14 lines · Michael Tokarev

Quoted 1 line · Avi Kivity

On 01/15/2012 03:10 PM, Michael Tokarev wrote:

[]

Quoted 10 lines

Quoted 5 lines

FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff.

It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will feature virtio-scsi, though of course that doesn't help already installed guests or non Windows/Linux guests. Do you know what the use cases requiring scsi boot are?

Quoted 6 lines

I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447
and a few private messages asking me for ways to restore booting from scsi, all talking about older/custom systems which worked for years in kvm. As you can see in the bugreport mentioned, I know that scsi is broken and should not be used and so on, and suggested switching from it on every chance.

Well we don't want to break people's guests. If the fix Gleb alluded to doesn't work, we'll have to restore extboot or something similar. Let us know.

Quoted 22 lines · Avi Kivity

Quoted 20 lines · Michael Tokarev

Quoted 1 line · Avi Kivity

On 01/15/2012 03:10 PM, Michael Tokarev wrote:

[]

Quoted 10 lines

Quoted 5 lines

FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff.

It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will feature virtio-scsi, though of course that doesn't help already installed guests or non Windows/Linux guests. Do you know what the use cases requiring scsi boot are?

I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447
and a few private messages asking me for ways to restore booting from scsi, all talking about older/custom systems which worked for years in kvm. As you can see in the bugreport mentioned, I know that scsi is broken and should not be used and so on, and suggested switching from it on every chance.

Quoted 3 lines

Well we don't want to break people's guests. If the fix Gleb alluded to doesn't work, we'll have to restore extboot or something similar. Let us know.

I would vote for proper seabios support or a free option rom. That would allow us to make progress with obsoleting qemu-kvm instead of making a step back again.

Quoted 27 lines · Jan Kiszka

Quoted 25 lines · Avi Kivity

Quoted 14 lines · Michael Tokarev

Quoted 1 line · Avi Kivity

On 01/15/2012 03:10 PM, Michael Tokarev wrote:

[]

Quoted 10 lines

Quoted 5 lines

FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff.

It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will feature virtio-scsi, though of course that doesn't help already installed guests or non Windows/Linux guests. Do you know what the use cases requiring scsi boot are?

Quoted 6 lines

I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447
and a few private messages asking me for ways to restore booting from scsi, all talking about older/custom systems which worked for years in kvm. As you can see in the bugreport mentioned, I know that scsi is broken and should not be used and so on, and suggested switching from it on every chance.

Well we don't want to break people's guests. If the fix Gleb alluded to doesn't work, we'll have to restore extboot or something similar. Let us know.

Quoted 4 lines

I would vote for proper seabios support or a free option rom. That would allow us to make progress with obsoleting qemu-kvm instead of making a step back again.

It is not enough to vote, somebody has to send patches :) And it seams there are two kind of people: those who can make such a patch, but don't because they know enough to avoid qemu lsi emulation and those who can't make it and use lsi qemu emulation.

Now, I've a question: what seabios implementation of extboot we're talking about?

-option-rom which is impossible to select as a first
boot device?