On 10/13/2010 01:00 PM, H. Peter Anvin wrote:
> On 10/13/2010 12:17 PM, H. Peter Anvin wrote:
>>
>> The ACPI specification recognizes three interfaces as standard: PC/AT
>> (64 bytes, even though 128 bytes is available on a lot of platforms),
>> PIIX4 (256 bytes), and Dallas Semiconductor ("256 byt
On 10/13/2010 12:17 PM, H. Peter Anvin wrote:
>
> The ACPI specification recognizes three interfaces as standard: PC/AT
> (64 bytes, even though 128 bytes is available on a lot of platforms),
> PIIX4 (256 bytes), and Dallas Semiconductor ("256 bytes or more"). The
> interface for the latter isn't
On 10/12/2010 12:06 PM, Gleb Natapov wrote:
>>
>> This is true to some extent -- there is some standard content, and some
>> further can be described via ACPI tables. However, my point was mostly
>> that it is an existing model for nonvolatile storage which also works on
>> hardware (and is vastly
On Tue, Oct 12, 2010 at 10:45:58AM -0700, H. Peter Anvin wrote:
> On 10/12/2010 10:41 AM, Gleb Natapov wrote:
> > On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote:
> >> On real hardware it is shared between BIOS and the OS, actually.
> >>
> > Guest OS can write in qemu CMOS too. But w
On 10/12/2010 10:41 AM, Gleb Natapov wrote:
> On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote:
>> On real hardware it is shared between BIOS and the OS, actually.
>>
> Guest OS can write in qemu CMOS too. But what is it useful for? Most of
> its content is not standard AFAIK.
>
Thi
On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote:
> On real hardware it is shared between BIOS and the OS, actually.
>
Guest OS can write in qemu CMOS too. But what is it useful for? Most of
its content is not standard AFAIK.
> "Gleb Natapov" wrote:
>
> >On Tue, Oct 12, 2010 at 09
On real hardware it is shared between BIOS and the OS, actually.
"Gleb Natapov" wrote:
>On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote:
>> On 10/12/2010 01:01 AM, Gleb Natapov wrote:
>> > On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote:
>> >>> I don't disagree.
>>
On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote:
> On 10/12/2010 01:01 AM, Gleb Natapov wrote:
> > On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote:
> >>> I don't disagree.
> >>>
> >>> I think the best thing to do is to let SeaBIOS create a boot order table
> >>> that
On 10/12/2010 01:01 AM, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote:
>>> I don't disagree.
>>>
>>> I think the best thing to do is to let SeaBIOS create a boot order table
>>> that contains descriptive information and then advertise that to QEMU.
>>>
>>> QE
On Mon, Oct 11, 2010 at 6:04 PM, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 12:01:58PM -0500, Anthony Liguori wrote:
>> On 10/11/2010 10:52 AM, Stefan Hajnoczi wrote:
>> >2010/10/11 Gleb Natapov:
>> >>On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
>> >>>On Mon, Oct 11, 2010 at
On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote:
> > I don't disagree.
> >
> > I think the best thing to do is to let SeaBIOS create a boot order table
> > that contains descriptive information and then advertise that to QEMU.
> >
> > QEMU can then try to associate the list of boo
On Mon, Oct 11, 2010 at 02:08:13PM +0200, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 01:16:00PM +0200, Bernhard Kohl wrote:
> > I think this also applies to network booting via gPXE. Usually our VMs
> > have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
> > be used for booti
On Mon, Oct 11, 2010 at 07:04:25PM +0200, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 12:01:58PM -0500, Anthony Liguori wrote:
> > On 10/11/2010 10:52 AM, Stefan Hajnoczi wrote:
> > >SeaBIOS may do that but gPXE internally just probes all PCI devices.
> > >It does not take advantage of the PCI bu
On 10/11/2010 02:41 PM, Sebastian Herbszt wrote:
> H. Peter Anvin wrote:
>> On 10/11/2010 01:30 PM, Anthony Liguori wrote:
>>> On 10/11/2010 02:59 PM, Gleb Natapov wrote:
No boot rom should do that. extboot wreaks havoc when it is used.
And since virtio is now supported by bios there is n
H. Peter Anvin wrote:
On 10/11/2010 01:30 PM, Anthony Liguori wrote:
On 10/11/2010 02:59 PM, Gleb Natapov wrote:
No boot rom should do that. extboot wreaks havoc when it is used.
And since virtio is now supported by bios there is no reason to use it.
You don't really have a choice. You could
On Mon, Oct 11, 2010 at 03:50:08PM -0500, Anthony Liguori wrote:
> On 10/11/2010 03:36 PM, Gleb Natapov wrote:
> >On Mon, Oct 11, 2010 at 03:30:21PM -0500, Anthony Liguori wrote:
> >>On 10/11/2010 02:59 PM, Gleb Natapov wrote:
> >>>No boot rom should do that. extboot wreaks havoc when it is used.
>
On 10/11/2010 01:30 PM, Anthony Liguori wrote:
> On 10/11/2010 02:59 PM, Gleb Natapov wrote:
>> No boot rom should do that. extboot wreaks havoc when it is used.
>> And since virtio is now supported by bios there is no reason to use it.
>
> You don't really have a choice. You could be doing hardw
On 10/11/2010 03:36 PM, Gleb Natapov wrote:
On Mon, Oct 11, 2010 at 03:30:21PM -0500, Anthony Liguori wrote:
On 10/11/2010 02:59 PM, Gleb Natapov wrote:
No boot rom should do that. extboot wreaks havoc when it is used.
And since virtio is now supported by bios there is no reason to us
On Mon, Oct 11, 2010 at 03:30:21PM -0500, Anthony Liguori wrote:
> On 10/11/2010 02:59 PM, Gleb Natapov wrote:
> >No boot rom should do that. extboot wreaks havoc when it is used.
> >And since virtio is now supported by bios there is no reason to use it.
>
> You don't really have a choice. You co
On 10/11/2010 02:59 PM, Gleb Natapov wrote:
No boot rom should do that. extboot wreaks havoc when it is used.
And since virtio is now supported by bios there is no reason to use it.
You don't really have a choice. You could be doing hardware passthrough
and the ROM on the card may hijack
On 10/11/2010 12:51 PM, Anthony Liguori wrote:
>
> -kernel hijacks int19 so it cannot participate in any kind of boot
> order. It's either present (and therefore the bootable disk) or not
> present.
>
That's a misdesign, though: it should be able to participate in BBS as a
BEV.
-hpa
On Mon, Oct 11, 2010 at 02:51:09PM -0500, Anthony Liguori wrote:
> On 10/11/2010 07:07 AM, Gerd Hoffmann wrote:
> > Hi,
> >
> >>Floppy? Yes, I think we do.
> >
> >And *one* floppy controllers can actually have *two* drives
> >connected, although booting from 'b' doesn't work IIRC.
> >
> >>>and sin
On Mon, Oct 11, 2010 at 02:48:48PM -0500, Anthony Liguori wrote:
> On 10/11/2010 07:16 AM, Gleb Natapov wrote:
> >On Mon, Oct 11, 2010 at 02:07:14PM +0200, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >>>Floppy? Yes, I think we do.
> >>And *one* floppy controllers can actually have *two* drives
> >>conne
On 10/11/2010 07:07 AM, Gerd Hoffmann wrote:
Hi,
Floppy? Yes, I think we do.
And *one* floppy controllers can actually have *two* drives connected,
although booting from 'b' doesn't work IIRC.
and since one PCI device may
control more then one disk (ATA slave/master, SCSI LUNs). We can
On 10/11/2010 07:16 AM, Gleb Natapov wrote:
On Mon, Oct 11, 2010 at 02:07:14PM +0200, Gerd Hoffmann wrote:
Hi,
Floppy? Yes, I think we do.
And *one* floppy controllers can actually have *two* drives
connected, although booting from 'b' doesn't work IIRC.
and since
On Mon, Oct 11, 2010 at 12:01:58PM -0500, Anthony Liguori wrote:
> On 10/11/2010 10:52 AM, Stefan Hajnoczi wrote:
> >2010/10/11 Gleb Natapov:
> >>On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
> >>>On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl
> >>>wrote:
> Am 11.10.2010 1
On 10/11/2010 10:52 AM, Stefan Hajnoczi wrote:
2010/10/11 Gleb Natapov:
On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl wrote:
Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
Currently if VM is starte
On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
> On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl wrote:
> > Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
> >>
> >> Currently if VM is started with multiple disks it is almost impossible to
> >> guess which one of them will be used
On Mon, Oct 11, 2010 at 04:52:31PM +0100, Stefan Hajnoczi wrote:
> 2010/10/11 Gleb Natapov :
> > On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
> >> On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl
> >> wrote:
> >> > Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
> >> >>
> >> >>
2010/10/11 Gleb Natapov :
> On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
>> On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl
>> wrote:
>> > Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
>> >>
>> >> Currently if VM is started with multiple disks it is almost impossible to
>> >>
On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl wrote:
> Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
>>
>> Currently if VM is started with multiple disks it is almost impossible to
>> guess which one of them will be used as boot device especially if there
>> is a mix of ATA/virtio/SCSI devices.
On Mon, Oct 11, 2010 at 02:07:14PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >Floppy? Yes, I think we do.
>
> And *one* floppy controllers can actually have *two* drives
> connected, although booting from 'b' doesn't work IIRC.
>
> >>and since one PCI device may
> >>control more then one disk (ATA
On Mon, Oct 11, 2010 at 01:16:00PM +0200, Bernhard Kohl wrote:
> Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
> >Currently if VM is started with multiple disks it is almost impossible to
> >guess which one of them will be used as boot device especially if there
> >is a mix of ATA/virtio/SCSI devi
Hi,
Floppy? Yes, I think we do.
And *one* floppy controllers can actually have *two* drives connected,
although booting from 'b' doesn't work IIRC.
and since one PCI device may
control more then one disk (ATA slave/master, SCSI LUNs). We can do what
EDD specification does. Describe disk
Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
Currently if VM is started with multiple disks it is almost impossible to
guess which one of them will be used as boot device especially if there
is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
and without looking into the cod
Am 11.10.2010 12:43, schrieb Gleb Natapov:
> On Mon, Oct 11, 2010 at 12:32:48PM +0200, Kevin Wolf wrote:
>> Am 11.10.2010 12:18, schrieb Gleb Natapov:
>>> Currently if VM is started with multiple disks it is almost impossible to
>>> guess which one of them will be used as boot device especially if
On Mon, Oct 11, 2010 at 12:32:48PM +0200, Kevin Wolf wrote:
> Am 11.10.2010 12:18, schrieb Gleb Natapov:
> > Currently if VM is started with multiple disks it is almost impossible to
> > guess which one of them will be used as boot device especially if there
> > is a mix of ATA/virtio/SCSI devices.
Am 11.10.2010 12:18, schrieb Gleb Natapov:
> Currently if VM is started with multiple disks it is almost impossible to
> guess which one of them will be used as boot device especially if there
> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> and without looking into the c
Currently if VM is started with multiple disks it is almost impossible to
guess which one of them will be used as boot device especially if there
is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
and without looking into the code you can't tell what the order will
be (and in q
39 matches
Mail list logo
