Please resend it as inline code (pasted) not as an attachment.
Thanks
El 04/08/2010, a las 00:46, Aaron Mason escribió:
Hi,
Now that I have half a clue, please find attached a properly formatted
patch for the above with a signed-off line. Hopefully attaching it
won't cause issues as I
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
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
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
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
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
https://bugs.launchpad.net/bugs/611646
reports that ./i386-softmmu/qemu -M isapc segfaults.
This patch fixes the segfault introduced by
f885f1eaa8711c06033ceb1599e3750fb37c306f
It's because i440fx_state in pc_init1() isn't initialized.
Core was generated by `./i386-softmmu/qemu -M isapc'.
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 pass the option rom
This patch adds an optional command line switch '-trace' to specify the
filename to write traces to, when qemu starts.
Eg, If compiled with the 'simple' trace backend,
[t...@system]$ qemu -trace FILENAME IMAGE
Allows the binary traces to be written to FILENAME instead of the option
set at
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
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 devices
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 right
On Wed, 4 Aug 2010, Prerna Saxena wrote:
This patch adds an optional command line switch '-trace' to specify the
filename to write traces to, when qemu starts.
Eg, If compiled with the 'simple' trace backend,
[t...@system]$ qemu -trace FILENAME IMAGE
Allows the binary traces to be written
On 08/03/2010 07:45 PM, Stefan Hajnoczi wrote:
On Tue, Aug 3, 2010 at 6:37 AM, Prerna Saxenapre...@linux.vnet.ibm.com wrote:
This patch adds an optional command line switch '-trace' to specify the
filename to write traces to, when qemu starts.
Eg, If compiled with the 'simple' trace backend,
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
On Wed, Aug 4, 2010 at 10:33 AM, Prerna Saxena
pre...@linux.vnet.ibm.com wrote:
On 08/03/2010 07:45 PM, Stefan Hajnoczi wrote:
On Tue, Aug 3, 2010 at 6:37 AM, Prerna Saxenapre...@linux.vnet.ibm.com
wrote:
@@ -2590,6 +2597,12 @@ int main(int argc, char **argv, char **envp)
}
Hi Aaron,
Am 04.08.2010 01:46, schrieb Aaron Mason:
Now that I have half a clue, please find attached a properly formatted
patch for the above with a signed-off line. Hopefully attaching it
won't cause issues as I have winblows on this machine and can't get
git send-email to work at this
Stefanha, Malc,
Thanks for suggestions. Resending the patch after clean-up.
This patch adds an optional command line switch '-trace' to specify the
filename to write traces to, when qemu starts.
Eg, If compiled with the 'simple' trace backend,
[t...@system]$ qemu -trace FILENAME IMAGE
Allows the
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 0xa-0xf or
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 4, 2010 at 11:53 AM, Prerna Saxena
pre...@linux.vnet.ibm.com wrote:
Stefanha, Malc,
Thanks for suggestions. Resending the patch after clean-up.
This patch adds an optional command line switch '-trace' to specify the
filename to write traces to, when qemu starts.
Eg, If compiled
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.
Because of limits of the
Hi,
On 4 August 2010 12:30, Kevin Wolf kw...@redhat.com wrote:
Am 04.08.2010 01:46, schrieb Aaron Mason:
+ const char *real_filename, *temp_str, *adapterType = ide;
Sorry to complain about style, but note that uppercase characters are
not used in variable names in Qemu (that I see).
Cheers
Am 04.08.2010 14:27, schrieb andrzej zaborowski:
Hi,
On 4 August 2010 12:30, Kevin Wolf kw...@redhat.com wrote:
Am 04.08.2010 01:46, schrieb Aaron Mason:
+const char *real_filename, *temp_str, *adapterType = ide;
Sorry to complain about style, but note that uppercase characters are
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
On Tue, Aug 3, 2010 at 5:55 PM, Blue Swirl blauwir...@gmail.com wrote:
+ if (strlen(current_snapshot_id) 0) {
+ pstrcpy(sn-parent_id_str, sizeof(sn-parent_id_str),
current_snapshot_id);
+ } else {
+ pstrcpy(sn-parent_id_str, sizeof(sn-parent_id_str),
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 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.
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
Existing fwcfg is
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
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 whatever we decide
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
- fwcfg+dma
-
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:
For
Guten Tag Kundennummer KK-216330,
Sie nutzen derzeit einen Krankenkassen Tarif, der durch einen günstigeren
ersetzt werden kann.
Damit Sie erfahren welcher Tarif günstiger ist und bessere Leistungen bietet,
müssten Sie einfach nur kurz einen kostenlosen Vergleich auf unserer
Internetseite
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 options:
-
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
- fwcfg+dma
-
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
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
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 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
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
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/-initrd to just
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,
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
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: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 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 how hardware
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
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 an
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
discourage
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 emulates a PC,
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:
libguestfs does not
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 08/03/10 12:43,
** Changed in: debian
Status: New = Fix Released
--
Windows XP/2003 doesn't boot
https://bugs.launchpad.net/bugs/586175
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Incomplete
Status in “qemu-kvm” package in
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, Anthony Liguori
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 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
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
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
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
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
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: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
Public bug reported:
Hi,
I am currently hunting a strange bug in qemu/kvm:
I am using an lvm logical volume as a virtual hard disk for a virtual
machine.
I use fdisk or parted to create a partition table and partitions, kpartx
to generate the device entries for the partitions, then install
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
devices to have more
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
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
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 for JBOD
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
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
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 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 enable support for more
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 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 workloads.
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
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.
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).
I don't
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 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
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 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
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 gets with
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 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 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 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
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
vs. 2 seconds.
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
big. The code that
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
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.
When savevm is run using an previously saved snapshot id or name, it will
delete the original and create a new one, using the same id and name and not
prompting the user of what just happened.
This behaviour is not good, IMHO.
We add a '-f' parameter to savevm, to really force that to happen, in
The output generated by 'info snapshots' shows only snapshots that exist on the
block device that saves the VM state. This output can cause an user to
erroneously try to load an snapshot that is not available on all block devices.
$ qemu-img snapshot -l xxtest.qcow2
Snapshot list:
IDTAG
Hi there!
This series introduces updates the 'info snapshots' and 'savevm' commands.
Patch 1 summarizes the output of 'info snapshots' to show only fully
available snapshots.
Patch 2 adds a default name to an snapshot in case the user did not provide one,
using a template like
When savevm is run without a name, the name stays blank and the snapshot is
saved anyway.
The new behavior is when savevm is run without parameters a name will be
created automaticaly, so the snapshot is accessible to the user without needing
the id when loadvm is run.
(qemu) savevm
(qemu) info
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, but not reusing
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. The
result is faster and has a smaller memory
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 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
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 generating
an
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
1 - 100 of 133 matches
Mail list logo
