https://bugs.launchpad.net/qemu/+bug/612901
Just curious if anyone has any information on this, perhaps this is
fixed in a CVS or git branch of Qemu
or a possible work around someone knows may work, or any information really.
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 Wed, Aug 04, 2010 at 05:21:33PM -0700, Hollis Blanchard wrote:
> These patches get the PowerPC Bamboo platform working again. I've re-written
> two of the patches based on feedback from qemu-devel.
>
> Note that this platform still only works in conjunction with KVM, since the
> PowerPC 440 MMU
On Wed, Aug 04, 2010 at 05:21:37PM -0700, Hollis Blanchard wrote:
> We can't use the return value of load_uimage() for the kernel because it
> can't account for BSS size, and the PowerPC kernel does not relocate
> blobs before zeroing BSS.
>
> Instead, we now load at the fixed addresses chosen by
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.
export qdev_reset() for later use.
Signed-off-by: Isaku Yamahata
---
hw/qdev.c | 29 +
hw/qdev.h |1 +
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index e99c73f..322b315 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -256,13
Make pci_device_reset handle qdevfied device and non-converted device
differently.
Later they will be handled differently.
Signed-off-by: Isaku Yamahata
---
hw/pci.c | 35 +--
hw/pci.h |1 +
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/hw/
implement secondary bus reset.
Signed-off-by: Isaku Yamahata
---
hw/pci_bridge.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
index ab7ed6e..37710e9 100644
--- a/hw/pci_bridge.c
+++ b/hw/pci_bridge.c
@@ -119,6 +119,9 @@ p
fix typo.
Signed-off-by: Isaku Yamahata
---
hw/apb_pci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 10a5baa..c619112 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -362,7 +362,7 @@ PCIBus *pci_apb_init(target_phys_addr_t speci
export pci_bus_reset() and pci_device_reset() for later use
with slight function signature adjustment.
Signed-off-by: Isaku Yamahata
---
hw/pci.c | 17 +
hw/pci.h |4
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 2dc1577..6a6
Introduce bus reset callback to support bus reset at qbus layer
and a function to trigger bus reset.
Now qdev reset callback is triggered by parent qbus reset callback.
And qdev should trigger child qbus reset callback.
Signed-off-by: Isaku Yamahata
---
changes v1 -> v2
- eliminate qemu_register_
Eliminate work around in pci_device_reset() by
making each pci reset function to call pci_device_reset_default().
Each device should know reset itself. It shouldn't be done pci generic
layer automatically. PCI layer should just signal reset and let each device
respond to reset.
Signed-off-by: Isak
use qbus bus reset callback.
Signed-off-by: Isaku Yamahata
---
hw/apb_pci.c|2 ++
hw/pci.c| 23 ++-
hw/pci_bridge.c |2 ++
3 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index c619112..775063a 100644
--- a/hw
Changes v1 -> v2:
- addressed personal feed back from Gerd.
- reset signal are triggered by bus and propagated down into device.
- Only 5/8 is modified. Other patches remains same.
This patch isn't for 0.13 release. and for MST pci branch.
(git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.g
On Mon, Jul 26, 2010 at 02:33:30PM +0300, Michael S. Tsirkin wrote:
> > +/*
> > + * TODO: there remains some boards which doesn't use PCIHostState.
> > + * Enhance PCIHostState API and convert remaining boards.
>
> I think I remember this comment from Paul:
> On Tuesday 12 January 2010
Public bug reported:
Please implement a fullscreen functionality (similar to the one found in
vmware, where there is an autohide bar), that enables display of a 1920x1080 VM
on a 1920x1080 (for example) without resizing (currently the menubar prevents
this).
Thank you.
** Affects: qemu
Im
We can't use the return value of load_uimage() for the kernel because it
can't account for BSS size, and the PowerPC kernel does not relocate
blobs before zeroing BSS.
Instead, we now load at the fixed addresses chosen by u-boot (the normal
firmware for the board).
Signed-off-by: Hollis Blanchard
The PowerPC 4xx SDRAM controller emulation unregisters RAM in its reset
callback. However, qemu_system_reset() is now called at initialization
time, so all RAM is unregistered before starting the guest (!).
Signed-off-by: Hollis Blanchard
---
hw/ppc4xx_devs.c |1 -
1 files changed, 0 insert
The message "Truncating memory to %d MiB to fit SDRAM controller limits"
should be displayed only when a user chooses an amount of RAM which
can't be represented by the PPC 4xx SDRAM controller (e.g. 129MB, which
would only be valid if the controller supports a bank size of 1MB).
Signed-off-by: Ho
We must be able to use a non-native strip executable, but not all
versions of 'install' support the --strip-program option (e.g.
OpenBSD). Accordingly, we can't use 'install -s', and we must run strip
separately.
Signed-off-by: Hollis Blanchard
Cc: blauwir...@gmail.com
---
Makefile.target |5
These patches get the PowerPC Bamboo platform working again. I've re-written
two of the patches based on feedback from qemu-devel.
Note that this platform still only works in conjunction with KVM, since the
PowerPC 440 MMU is still not accurately emulated by TCG.
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
This introduces emulation for the AMD IOMMU, described in "AMD I/O
Virtualization Technology (IOMMU) Specification".
Signed-off-by: Eduard - Gabriel Munteanu
---
Makefile.target |2 +
configure | 10 +
hw/amd_iommu.c | 671 +++
hw
Emulated PCI IDE controllers now use the memory access interface. This
also allows an emulated IOMMU to translate and check accesses.
Map invalidation results in cancelling DMA transfers. Since the guest OS
can't properly recover the DMA results in case the mapping is changed,
this is a fairly goo
This allows the device to work properly with an emulated IOMMU.
Signed-off-by: Eduard - Gabriel Munteanu
---
hw/rtl8139.c | 99 -
1 files changed, 56 insertions(+), 43 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 72e2242..
Hi,
I hope I solved the issues raised by Anthony and Paul.
Please have a look and tell me what you think. However, don't merge it yet (in
case you like it), I need to test and cleanup some pieces further. There are
also some patches from the previous series I didn't include yet.
Thanks,
PCI devices should access memory through pci_memory_*() instead of
cpu_physical_memory_*(). This also provides support for translation and
access checking in case an IOMMU is emulated.
Memory maps are treated as remote IOTLBs (that is, translation caches
belonging to the IOMMU-aware device itself)
there
sent from my Telstra NEXTG™ handset
-Original Message-
From: Kevin Wolf
Sent: Wednesday, 4 August 2010 10:29 PM
To: andrzej zaborowski
Cc: Aaron Mason ; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Added an option to set the VMDK adapter type
Am 04.08.2010 14:27, schri
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
Seems to be the same issue as in
http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=5218
--
qemu does not accept regular disk geometry
https://bugs.launchpad.net/bugs/613529
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
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
I am able to run qemu with the following commandline:
/usr/local/bin/qemu-system-ppcemb -enable-kvm -kernel uImage.bamboo
-nographic -M bamboo ppc440-angstrom-linux.img
However, when I try to use virtio instead, I get this segfault:
/usr/local/bin/qemu-system-ppcemb -enable-kvm -kernel uImage.bamb
That patch did not fix my issue. My problem turned out to be due to TLS
accesses to cp15 not being allowed by qemu in user mode, even though these
are permitted in ARMv6 and above architectures (e.g. see
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388f/CIHFGFGE.html).
This was corrected by
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: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 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,
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
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.
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
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
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 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 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 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 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 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 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 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: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 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 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: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 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: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: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 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: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
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 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
** 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 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
> >
1 - 100 of 135 matches
Mail list logo
