On 08/05/2010 02:28 AM, Gerd Hoffmann wrote:
Hi,
The option rom stuff has a number of short comings. Because we hijack
int19, extboot doesn't get to run. That means that if you use -kernel to
load a grub (the Ubuntu guys for their own absurd reasons) then grub
does not see extboot backed disk
On Thu, Aug 05, 2010 at 11:45:33AM +0300, Avi Kivity wrote:
> On 08/05/2010 10:59 AM, Gleb Natapov wrote:
> >
> >>We have the firmware configuration interface for that, if we can
> >>tolerate its speed.
> >>
> >To pass default boot device, sure :) The question is what to pass so
> >that seabios wi
On 08/05/2010 10:59 AM, Gleb Natapov wrote:
We have the firmware configuration interface for that, if we can
tolerate its speed.
To pass default boot device, sure :) The question is what to pass so
that seabios will be able to unambiguously determine what device to
boot from.
IMO seabios s
On Thu, Aug 05, 2010 at 10:56:52AM +0300, Avi Kivity wrote:
> On 08/05/2010 10:34 AM, Gleb Natapov wrote:
> >On Thu, Aug 05, 2010 at 09:28:57AM +0200, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >>>The option rom stuff has a number of short comings. Because we hijack
> >>>int19, extboot doesn't get to
On 08/05/2010 10:34 AM, Gleb Natapov wrote:
On Thu, Aug 05, 2010 at 09:28:57AM +0200, Gerd Hoffmann wrote:
Hi,
The option rom stuff has a number of short comings. Because we hijack
int19, extboot doesn't get to run. That means that if you use -kernel to
load a grub (the Ubuntu guys for the
On Thu, Aug 05, 2010 at 09:28:57AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >The option rom stuff has a number of short comings. Because we hijack
> >int19, extboot doesn't get to run. That means that if you use -kernel to
> >load a grub (the Ubuntu guys for their own absurd reasons) then grub
> >d
Hi,
The option rom stuff has a number of short comings. Because we hijack
int19, extboot doesn't get to run. That means that if you use -kernel to
load a grub (the Ubuntu guys for their own absurd reasons) then grub
does not see extboot backed disks. The solution for them is the same,
generate
On Wed, Aug 04, 2010 at 07:17:30PM -0400, Kevin O'Connor wrote:
> On Wed, Aug 04, 2010 at 06:25:52PM +0300, Gleb Natapov wrote:
> > On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
> > > There are better ways like using string I/O and optimizing the PIO
> > > path in the kernel. Th
On 08/04/2010 11:06 PM, David S. Ahern wrote:
On 08/04/10 11:34, Avi Kivity wrote:
And it's awesome for fast prototyping. Of course, once that fast
becomes dog slow, it's not useful anymore.
For the Nth time, it's only slow with 100MB initrds.
100MB is really not that large for an initrd.
On Wed, Aug 04, 2010 at 06:25:52PM +0300, Gleb Natapov wrote:
> On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
> > There are better ways like using string I/O and optimizing the PIO
> > path in the kernel. That should cut down the 1s slow down with a
> > 100MB initrd by a bit. B
On Wed, Aug 04, 2010 at 06:01:54PM +0300, Gleb Natapov wrote:
> On Wed, Aug 04, 2010 at 09:50:55AM -0500, Anthony Liguori wrote:
> > On 08/04/2010 09:38 AM, Gleb Natapov wrote:
> > >ROM does not muck with the e820. It uses PMM to allocate memory and the
> > >memory it gets is marked as reserved in
On Wed, Aug 04, 2010 at 02:06:58PM -0600, David S. Ahern wrote:
>
>
> On 08/04/10 11:34, Avi Kivity wrote:
>
> >> And it's awesome for fast prototyping. Of course, once that fast
> >> becomes dog slow, it's not useful anymore.
> >
> > For the Nth time, it's only slow with 100MB initrds.
>
> 10
On 08/04/10 11:34, Avi Kivity wrote:
>> And it's awesome for fast prototyping. Of course, once that fast
>> becomes dog slow, it's not useful anymore.
>
> For the Nth time, it's only slow with 100MB initrds.
100MB is really not that large for an initrd.
Consider the deployment of stateless no
On 08/04/2010 09:16 PM, Anthony Liguori wrote:
Why not go with 9p? That would save off even more time, as you don't
have to generate an iso. You could just copy all the relevant
executables into tmpfs and boot from there using your kernel and a
very small (pre-built) initrd.
You can't boot f
On 04.08.2010, at 20:16, Anthony Liguori wrote:
> On 08/04/2010 01:13 PM, Alexander Graf wrote:
>> On 04.08.2010, at 19:46, Richard W.M. Jones wrote:
>>
>>
>>> On Wed, Aug 04, 2010 at 07:36:04PM +0300, Avi Kivity wrote:
>>>
This is basically my suggestion to libguestfs: instead of g
On 08/04/2010 09:13 PM, Alexander Graf wrote:
It's not trivial mind you, and won't happen straightaway. Part of it
is that it requires reworking the appliance builder (a matter of just
coding really). The less trivial part is that we have to 'hide' the
CD device throughout the publically ava
On 08/04/2010 01:13 PM, Alexander Graf wrote:
On 04.08.2010, at 19:46, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 07:36:04PM +0300, Avi Kivity wrote:
This is basically my suggestion to libguestfs: instead of generating
an initrd, generate a bootable cdrom, and boot from that.
On 04.08.2010, at 19:53, Anthony Liguori wrote:
> On 08/04/2010 12:37 PM, Avi Kivity wrote:
>> On 08/04/2010 08:27 PM, Anthony Liguori wrote:
>>> On 08/04/2010 12:19 PM, Avi Kivity wrote:
On 08/04/2010 08:01 PM, Paolo Bonzini wrote:
>
> That's another story and I totally agree here,
On 08/04/2010 12:37 PM, Avi Kivity wrote:
On 08/04/2010 08:27 PM, Anthony Liguori wrote:
On 08/04/2010 12:19 PM, Avi Kivity wrote:
On 08/04/2010 08:01 PM, Paolo Bonzini wrote:
That's another story and I totally agree here, but not reusing
/dev/sd* is not intrinsic in the design of virtio-b
On 08/04/2010 08:46 PM, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 07:36:04PM +0300, Avi Kivity wrote:
This is basically my suggestion to libguestfs: instead of generating
an initrd, generate a bootable cdrom, and boot from that. The
result is faster and has a smaller memory footprint.
On Wed, Aug 04, 2010 at 07:36:04PM +0300, Avi Kivity wrote:
> This is basically my suggestion to libguestfs: instead of generating
> an initrd, generate a bootable cdrom, and boot from that. The
> result is faster and has a smaller memory footprint. Everyone wins.
We had some discussion of this
On Wed, Aug 04, 2010 at 11:44:33AM -0500, Anthony Liguori wrote:
> On 08/04/2010 11:36 AM, Avi Kivity wrote:
> > On 08/04/2010 07:30 PM, Avi Kivity wrote:
> >> On 08/04/2010 04:52 PM, Anthony Liguori wrote:
> >
> This is not like DMA event if done in chunks and chunks can be pretty
> bi
On 08/04/2010 08:27 PM, Anthony Liguori wrote:
On 08/04/2010 12:19 PM, Avi Kivity wrote:
On 08/04/2010 08:01 PM, Paolo Bonzini wrote:
That's another story and I totally agree here, but not reusing
/dev/sd* is not intrinsic in the design of virtio-blk (and one thing
that Windows gets right;
On 04.08.2010, at 19:36, Anthony Liguori wrote:
> On 08/04/2010 12:31 PM, Alexander Graf wrote:
>> On 04.08.2010, at 19:26, Anthony Liguori wrote:
>>
>>
>>> On 08/04/2010 11:45 AM, Alexander Graf wrote:
>>>
Frankly, I partially agreed to your point when we were talking about 300ms
On 08/04/2010 12:31 PM, Alexander Graf wrote:
On 04.08.2010, at 19:26, Anthony Liguori wrote:
On 08/04/2010 11:45 AM, Alexander Graf wrote:
Frankly, I partially agreed to your point when we were talking about 300ms vs.
2 seconds. Now that we're talking 8 seconds that whole point is
On 08/04/2010 08:31 PM, Alexander Graf wrote:
Even better yet, why not use virtio-9p and expose all of fw_cfg as files? Then
implement a simple virtio-9p client in SeaBIOS and maybe even get direct
kernel/initrd boot from a real 9p system ;).
libguestfs could use 9pfs directly. That will
On 08/04/2010 08:27 PM, Alexander Graf wrote:
Well, it isn't. Two external projects already use it. You can't change it due
to the needs to live migrate from older versions.
You can always extend it. You can even break it with a new -M.
Yes. But it's a pain to make sure it all works out.
On 04.08.2010, at 19:26, Anthony Liguori wrote:
> On 08/04/2010 11:45 AM, Alexander Graf wrote:
>> Frankly, I partially agreed to your point when we were talking about 300ms
>> vs. 2 seconds. Now that we're talking 8 seconds that whole point is moot. We
>> chose the wrong interface to transfer
On 08/04/2010 12:19 PM, Avi Kivity wrote:
On 08/04/2010 08:01 PM, Paolo Bonzini wrote:
That's another story and I totally agree here, but not reusing
/dev/sd* is not intrinsic in the design of virtio-blk (and one thing
that Windows gets right; everything is SCSI, period).
I don't really
On 04.08.2010, at 19:14, Avi Kivity wrote:
> On 08/04/2010 08:01 PM, Alexander Graf wrote:
>>
>>>
2) Using a different interface (that could also be DMA fw_cfg - remember,
we're on a private interface anyways)
>>> A guest/host interface is not private.
>> fw_cfg is as private as it g
On 08/04/2010 11:45 AM, Alexander Graf wrote:
Frankly, I partially agreed to your point when we were talking about 300ms vs.
2 seconds. Now that we're talking 8 seconds that whole point is moot. We chose
the wrong interface to transfer kernel+initrd data into the guest.
Now the question is how
On 04.08.2010, at 19:19, Avi Kivity wrote:
> On 08/04/2010 08:01 PM, Paolo Bonzini wrote:
>>
>> That's another story and I totally agree here, but not reusing /dev/sd* is
>> not intrinsic in the design of virtio-blk (and one thing that Windows gets
>> right; everything is SCSI, period).
>>
>
On 08/04/2010 08:01 PM, Paolo Bonzini wrote:
That's another story and I totally agree here, but not reusing
/dev/sd* is not intrinsic in the design of virtio-blk (and one thing
that Windows gets right; everything is SCSI, period).
I don't really get why everything must be SCSI. Everythin
On 08/04/2010 08:01 PM, Alexander Graf wrote:
2) Using a different interface (that could also be DMA fw_cfg - remember, we're
on a private interface anyways)
A guest/host interface is not private.
fw_cfg is as private as it gets with host/guest interfaces. It's about as close
as CPU spec
On 04.08.2010, at 18:54, Avi Kivity wrote:
> On 08/04/2010 07:45 PM, Alexander Graf wrote:
>>
>> I see two alternatives out of this mess:
>>
>> 1) Speed up string PIO so we're actually fast again.
>
> Certainly, the best option given that it needs no new interfaces, and
> improves the most wo
On 08/04/2010 06:49 PM, Anthony Liguori wrote:
Right, the only question is, to you inject your own bus or do you
just reuse SCSI. On the surface, it seems like reusing SCSI has a
significant number of advantages. For instance, without changing the
guest's drivers, we can implement PV cdroms or
On 08/04/2010 07:45 PM, Alexander Graf wrote:
I see two alternatives out of this mess:
1) Speed up string PIO so we're actually fast again.
Certainly, the best option given that it needs no new interfaces, and
improves the most workloads.
2) Using a different interface (that could also b
On 08/04/2010 07:44 PM, Anthony Liguori wrote:
The option rom stuff has a number of short comings. Because we hijack
int19, extboot doesn't get to run. That means that if you use -kernel
to load a grub (the Ubuntu guys for their own absurd reasons) then
grub does not see extboot backed dis
On 04.08.2010, at 18:49, Anthony Liguori wrote:
> On 08/04/2010 11:48 AM, Alexander Graf wrote:
>> On 04.08.2010, at 18:46, Anthony Liguori wrote:
>>
>>
>>> On 08/04/2010 11:44 AM, Avi Kivity wrote:
>>>
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
> So how do we en
On 08/04/2010 11:48 AM, Alexander Graf wrote:
On 04.08.2010, at 18:46, Anthony Liguori wrote:
On 08/04/2010 11:44 AM, Avi Kivity wrote:
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
So how do we enable support for more than 20 disks? I think a virtio-scsi is
inevitable..
On 08/04/2010 07:08 PM, Gleb Natapov wrote:
After applying cache fix nothing definite as far as I remember (I ran it last
time
almost 2 week ago, need to rerun). Code always go through emulator now
and check direction flags to update SI/DI accordingly. Emulator is a big
switch and it calls var
On 04.08.2010, at 18:46, Anthony Liguori wrote:
> On 08/04/2010 11:44 AM, Avi Kivity wrote:
>> On 08/04/2010 03:53 PM, Anthony Liguori wrote:
>>>
>>> So how do we enable support for more than 20 disks? I think a virtio-scsi
>>> is inevitable..
>>
>> Not only for large numbers of disks, also f
On 08/04/2010 11:44 AM, Avi Kivity wrote:
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
So how do we enable support for more than 20 disks? I think a
virtio-scsi is inevitable..
Not only for large numbers of disks, also for JBOD performance. If
you have one queue per disk you'll have lo
On 04.08.2010, at 18:36, Avi Kivity wrote:
> On 08/04/2010 07:30 PM, Avi Kivity wrote:
>> On 08/04/2010 04:52 PM, Anthony Liguori wrote:
>
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
d
On 08/04/2010 11:36 AM, Avi Kivity wrote:
On 08/04/2010 07:30 PM, Avi Kivity wrote:
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more sp
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
So how do we enable support for more than 20 disks? I think a
virtio-scsi is inevitable..
Not only for large numbers of disks, also for JBOD performance. If you
have one queue per disk you'll have low queue depths and high interrupt
rates.
On 08/04/2010 11:30 AM, Avi Kivity wrote:
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more space there.
That's a bit complicated becau
On 08/04/2010 07:30 PM, Avi Kivity wrote:
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more space there.
That's a bit complicated beca
On 08/04/2010 05:39 PM, Anthony Liguori wrote:
We could make kernel an awful lot smarter but unless we've got someone
just itching to write 16-bit option rom code, I think our best bet is
to try to leverage a standard bootloader and expose a disk containing
the kernel/initrd.
A problem w
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more space there.
That's a bit complicated because SeaBIOS is managing the PCI devices
whe
On 08/04/2010 04:24 PM, Richard W.M. Jones wrote:
It's boot time, so you can just map it over some existing RAM surely?
Linuxboot.bin can work out where to map it so it won't be in any
memory either being used or the target for the copy.
There's no such thing as boot time from the host's poin
On 08/04/2010 04:04 PM, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide the flash size is) and
have the BIOS copy them
Existing fwcfg is the least amount of
On Wed, Aug 04, 2010 at 05:59:40PM +0200, Alexander Graf wrote:
>
> On 04.08.2010, at 17:48, Gleb Natapov wrote:
>
> > On Wed, Aug 04, 2010 at 05:31:12PM +0200, Alexander Graf wrote:
> >>
> >> On 04.08.2010, at 17:25, Gleb Natapov wrote:
> >>
> >>> On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anth
On 04.08.2010, at 17:48, Gleb Natapov wrote:
> On Wed, Aug 04, 2010 at 05:31:12PM +0200, Alexander Graf wrote:
>>
>> On 04.08.2010, at 17:25, Gleb Natapov wrote:
>>
>>> On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
On 08/04/2010 09:51 AM, David S. Ahern wrote:
>
>>>
On Wed, Aug 04, 2010 at 05:31:12PM +0200, Alexander Graf wrote:
>
> On 04.08.2010, at 17:25, Gleb Natapov wrote:
>
> > On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
> >> On 08/04/2010 09:51 AM, David S. Ahern wrote:
> >>>
> >>> On 08/03/10 12:43, Avi Kivity wrote:
> libgu
On 04.08.2010, at 17:25, Gleb Natapov wrote:
> On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
>> On 08/04/2010 09:51 AM, David S. Ahern wrote:
>>>
>>> On 08/03/10 12:43, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 e
On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
> On 08/04/2010 09:51 AM, David S. Ahern wrote:
> >
> >On 08/03/10 12:43, Avi Kivity wrote:
> >>libguestfs does not depend on an x86 architectural feature.
> >>qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should
>
On Wed, Aug 04, 2010 at 10:07:24AM -0500, Anthony Liguori wrote:
> On 08/04/2010 10:01 AM, Gleb Natapov wrote:
> >
> >Hm, may be. I read seabios code differently, but may be I misread it.
>
> The BIOS Boot Specification spells it all out pretty clearly.
>
I have the spec. Isn't this enough to be
On 08/04/2010 10:01 AM, Gleb Natapov wrote:
Hm, may be. I read seabios code differently, but may be I misread it.
The BIOS Boot Specification spells it all out pretty clearly.
If a ROM needs memory after the init function, it needs to use the
traditional tricks to allocate long term memo
On Wed, Aug 04, 2010 at 09:50:55AM -0500, Anthony Liguori wrote:
> On 08/04/2010 09:38 AM, Gleb Natapov wrote:
> >>
> >>But even if it wasn't it can potentially create havoc. I think we
> >>currently believe that the northbridge likely never forwards RAM
> >>access to a device so this doesn't fit
On 08/04/2010 09:51 AM, David S. Ahern wrote:
On 08/03/10 12:43, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should
discourage people from depending on this interface for production use.
On 08/03/10 12:43, Avi Kivity wrote:
> libguestfs does not depend on an x86 architectural feature.
> qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should
> discourage people from depending on this interface for production use.
That is a feature of qemu - and an important one
On 08/04/2010 09:38 AM, Gleb Natapov wrote:
But even if it wasn't it can potentially create havoc. I think we
currently believe that the northbridge likely never forwards RAM
access to a device so this doesn't fit how hardware would work.
Good point.
More importantly, BIOSes and R
On 08/04/2010 09:22 AM, Paolo Bonzini wrote:
On 08/04/2010 04:00 PM, Gleb Natapov wrote:
Maybe we're just being too fancy here.
We could rewrite -kernel/-append/-initrd to just generate a floppy
image in RAM, and just boot from floppy.
May be. Can floppy be 100M?
Well, in theory you can hav
On Wed, Aug 04, 2010 at 09:22:22AM -0500, Anthony Liguori wrote:
> On 08/04/2010 08:26 AM, Gleb Natapov wrote:
> >On Wed, Aug 04, 2010 at 02:24:08PM +0100, Richard W.M. Jones wrote:
> >>On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
> >>>On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 09:14:01AM -0500, Anthony Liguori wrote:
> >Unmapping device and mapping it at the same place is easy. Enumerating
> >pci devices from multiboot.bin looks like unneeded churn though.
> >
> >>Maybe we're just being too fancy here.
> >>
> >>We could rewrite -kernel/-append/-in
On 08/04/2010 04:00 PM, Gleb Natapov wrote:
Maybe we're just being too fancy here.
We could rewrite -kernel/-append/-initrd to just generate a floppy
image in RAM, and just boot from floppy.
May be. Can floppy be 100M?
Well, in theory you can have 16384 bytes/sector, 256 tracks, 255
sectors
On 08/04/2010 08:26 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 02:24:08PM +0100, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguo
On 08/04/2010 09:00 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:52:44AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:34 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On
On Wed, Aug 04, 2010 at 08:52:44AM -0500, Anthony Liguori wrote:
> On 08/04/2010 08:34 AM, Gleb Natapov wrote:
> >On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
> >>On 08/04/2010 08:07 AM, Gleb Natapov wrote:
> >>>On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
>
On 08/04/2010 08:34 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For p
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
> On 08/04/2010 08:07 AM, Gleb Natapov wrote:
> >On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
> >>On 08/04/2010 03:17 AM, Avi Kivity wrote:
> >>>For playing games, there are three options:
> >>>- existing fwcfg
> >
On Wed, Aug 04, 2010 at 02:22:29PM +0100, Richard W.M. Jones wrote:
>
> On Wed, Aug 04, 2010 at 04:07:09PM +0300, Gleb Natapov wrote:
> > On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
> > > On 08/04/2010 03:17 AM, Avi Kivity wrote:
> > > >For playing games, there are three optio
On Wed, Aug 04, 2010 at 02:24:08PM +0100, Richard W.M. Jones wrote:
> On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
> > On 08/04/2010 08:07 AM, Gleb Natapov wrote:
> > >On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
> > >>On 08/04/2010 03:17 AM, Avi Kivity wrote
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
> On 08/04/2010 08:07 AM, Gleb Natapov wrote:
> >On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
> >>On 08/04/2010 03:17 AM, Avi Kivity wrote:
> >>>For playing games, there are three options:
> >>>- existing fwcfg
> >
On Wed, Aug 04, 2010 at 04:07:09PM +0300, Gleb Natapov wrote:
> On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
> > On 08/04/2010 03:17 AM, Avi Kivity wrote:
> > >For playing games, there are three options:
> > >- existing fwcfg
> > >- fwcfg+dma
> > >- put roms in 4GB-2MB (or what
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide the flash size i
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
> On 08/04/2010 03:17 AM, Avi Kivity wrote:
> >For playing games, there are three options:
> >- existing fwcfg
> >- fwcfg+dma
> >- put roms in 4GB-2MB (or whatever we decide the flash size is)
> >and have the BIOS copy them
> >
> >Exi
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide the flash size is) and
have the BIOS copy them
Existing fwcfg is the least amount of work and probably satisfactory
for isapc. fwcfg
On 08/04/2010 04:24 AM, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 08:54:35AM +0300, Avi Kivity wrote:
On 08/04/2010 01:06 AM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
Why do we need to transfer roms? These are devices on
On 08/04/2010 02:57 AM, Paolo Bonzini wrote:
On 08/03/2010 11:34 PM, Anthony Liguori wrote:
Comparing (from personal experience) the complexity of the Windows
drivers for Xen and virtio shows that it's not a bad idea at all.
Not quite sure what you're suggesting, but I could have been clearer
On Wed, Aug 04, 2010 at 12:33:18PM +0100, Richard W.M. Jones wrote:
> On Wed, Aug 04, 2010 at 12:52:23PM +0300, Avi Kivity wrote:
> > On 08/04/2010 12:24 PM, Richard W.M. Jones wrote:
> > >>>
> > >>>Just like the initrd?
> > >>There isn't enough address space for a 100MB initrd in ROM.
> > >Becaus
On 08/04/2010 02:33 PM, Richard W.M. Jones wrote:
I'm only allocating 500MB of RAM, so there's easily enough space to
put a large ROM, with tons of room for growth (of both RAM and ROM).
Yes, even real hardware has done this. The Weitek math copro mapped
itself in at physical memory addresses
On Wed, Aug 04, 2010 at 12:52:23PM +0300, Avi Kivity wrote:
> On 08/04/2010 12:24 PM, Richard W.M. Jones wrote:
> >>>
> >>>Just like the initrd?
> >>There isn't enough address space for a 100MB initrd in ROM.
> >Because of limits of the original PC, sure, where you had to fit
> >everything in 0xa0
On 08/04/2010 12:24 PM, Richard W.M. Jones wrote:
Just like the initrd?
There isn't enough address space for a 100MB initrd in ROM.
Because of limits of the original PC, sure, where you had to fit
everything in 0xa-0xf or whatever it was.
But this isn't a real PC.
You can map the re
On Wed, Aug 04, 2010 at 10:24:28AM +0100, Richard W.M. Jones wrote:
> On Wed, Aug 04, 2010 at 08:54:35AM +0300, Avi Kivity wrote:
> > On 08/04/2010 01:06 AM, Richard W.M. Jones wrote:
> > >On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
> > >>Why do we need to transfer roms? These are
On Wed, Aug 04, 2010 at 08:54:35AM +0300, Avi Kivity wrote:
> On 08/04/2010 01:06 AM, Richard W.M. Jones wrote:
> >On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
> >>Why do we need to transfer roms? These are devices on the memory
> >>bus or pci bus, it just needs to be there at the
On 08/04/10 10:17, Avi Kivity wrote:
On 08/04/2010 10:56 AM, Gerd Hoffmann wrote:
Hi,
(1) -M somethingold. PCI devices don't have a pci rom bar then by
default because they didn't not have one in older qemu versions,
so we need some other way to pass the option rom to seabios.
What did we do
On Wed, Aug 04, 2010 at 11:17:28AM +0300, Avi Kivity wrote:
> On 08/04/2010 10:56 AM, Gerd Hoffmann wrote:
> > Hi,
> >
> >>>(1) -M somethingold. PCI devices don't have a pci rom bar then by
> >>>default because they didn't not have one in older qemu versions,
> >>>so we need some other way to pas
On 08/03/2010 10:13 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We
should discourage people from depending on this interface f
On 08/04/2010 10:57 AM, Paolo Bonzini wrote:
On 08/03/2010 11:34 PM, Anthony Liguori wrote:
Comparing (from personal experience) the complexity of the Windows
drivers for Xen and virtio shows that it's not a bad idea at all.
Not quite sure what you're suggesting, but I could have been cleare
On 08/04/2010 10:56 AM, Gerd Hoffmann wrote:
Hi,
(1) -M somethingold. PCI devices don't have a pci rom bar then by
default because they didn't not have one in older qemu versions,
so we need some other way to pass the option rom to seabios.
What did we do back then? before we had the fwcfg
On 08/03/2010 11:34 PM, Anthony Liguori wrote:
Comparing (from personal experience) the complexity of the Windows
drivers for Xen and virtio shows that it's not a bad idea at all.
Not quite sure what you're suggesting, but I could have been clearer.
Instead of having virtio-blk where a virtio
Hi,
(1) -M somethingold. PCI devices don't have a pci rom bar then by
default because they didn't not have one in older qemu versions,
so we need some other way to pass the option rom to seabios.
What did we do back then? before we had the fwcfg interface?
Have qemu instead of bochs/seabio
On 08/03/2010 11:49 PM, Anthony Liguori wrote:
We could demand that OSes write device drivers for more qemu devices
-- already OS vendors write thousands of device drivers for all sorts
of obscure devices, so this isn't really much of a demand for them.
In fact, they're already doing it.
So
On 08/04/2010 01:06 AM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
Why do we need to transfer roms? These are devices on the memory
bus or pci bus, it just needs to be there at the right address.
Boot splash should just be another rom as it would be o
On 08/04/2010 12:20 AM, Gerd Hoffmann wrote:
Hi,
We're already doing bulk data transfer over fw_cfg as we need to do it
to transfer roms and potentially a boot splash.
Why do we need to transfer roms? These are devices on the memory bus or
pci bus, it just needs to be there at the right ad
On 08/03/2010 10:47 PM, Anthony Liguori wrote:
On 08/03/2010 02:41 PM, Avi Kivity wrote:
On 08/03/2010 10:38 PM, Anthony Liguori wrote:
Why do we need to transfer roms? These are devices on the memory
bus or pci bus, it just needs to be there at the right address.
Not quite. The BIOS own
Richard W.M. Jones wrote:
> We could demand that OSes write device drivers for more qemu devices
> -- already OS vendors write thousands of device drivers for all sorts
> of obscure devices, so this isn't really much of a demand for them.
> In fact, they're already doing it.
Result: Most OSes not
On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
> Why do we need to transfer roms? These are devices on the memory
> bus or pci bus, it just needs to be there at the right address.
> Boot splash should just be another rom as it would be on a real
> system.
Just like the initrd?
Rich.
1 - 100 of 145 matches
Mail list logo
