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
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: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 fwcfg
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/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
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'.
> Pro
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
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 config-
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 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 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 writt
On 08/03/2010 07:45 PM, Stefan Hajnoczi wrote:
On Tue, Aug 3, 2010 at 6:37 AM, 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
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 4, 2010 at 10:33 AM, Prerna Saxena
wrote:
> On 08/03/2010 07:45 PM, Stefan Hajnoczi wrote:
>> On Tue, Aug 3, 2010 at 6:37 AM, Prerna Saxena
>> wrote:
>>> @@ -2590,6 +2597,12 @@ int main(int argc, char **argv, char **envp)
>>> }
>>> xen_mode = XEN_ATTACH
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 0xa0
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
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 with the 'simple' tra
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
Hi,
On 4 August 2010 12:30, Kevin Wolf 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 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 u
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 Tue, Aug 3, 2010 at 5:55 PM, Blue Swirl 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),
>> "---00
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 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 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 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 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 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: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
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 dur
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 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 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: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 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 Liguo
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 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 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 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 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/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
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 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 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 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 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: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:
>
>>>
** 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 U
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 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 poin
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 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 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 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 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 sp
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 linu
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 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 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: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 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 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 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 en
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 wo
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 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 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 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 how
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 out.
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 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 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 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 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.
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 vm-MMDDHHMMSS.
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 s
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 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 f
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 ava
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
1 - 100 of 135 matches
Mail list logo
