Amit Shah writes:
> On (Tue) Jun 08 2010 [18:33:00], Markus Armbruster wrote:
>> Amit Shah writes:
>>
>> > The correct model type wasn't getting added when hotplugging nics with
>> > pci_add.
>> >
>> > Testcase: start VM with default nic type. In the qemu_monitor:
>> >
>> > (qemu) pci_add auto
Marcos Oviedo writes:
> This adds a way to force the removal/unplug of previously added pci
> devices when ACPI-based hotplug mechanism is not present.
>
> Signed-off-by: Marcos Oviedo
If this makes sense for pci_del (I'm not passing judgement), then we
need it for device_del as well.
This bug is still present on latest git. It seems, please double check
this, that the commit you tested is related to a different issue.
The steps to reproduce the bug are attached on the case. Usually, when
there is support for ACPI operations on the guest OS, the pci_del
command triggers a gener
Although there is no difference, other migration related code use
qemu_free(), and it should be better to be consistent.
Signed-off-by: Yoshiaki Tamura
---
migration.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/migration.c b/migration.c
index fbf2339..64ed36e 10064
This adds a way to force the removal/unplug of previously added pci
devices when ACPI-based hotplug mechanism is not present.
Signed-off-by: Marcos Oviedo
---
hw/pci-hotplug.c | 16 +---
qemu-monitor.hx |4 ++--
sysemu.h |2 +-
3 files changed, 16 insertions(+), 6
On Wed, 2010-06-09 at 03:54 +0100, Paul Brook wrote:
> > On 06/08/2010 09:30 PM, Paul Brook wrote:
> > >> The offset given to a block created via qemu_ram_alloc/map() is
> > >> arbitrary, let the caller specify a name so we can make a positive
> > >> match.
> > >>
> > >>
> > >> @@ -1924,7 +1925,9
On Tue, 2010-06-08 at 14:41 -0700, Chris Wright wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > +// XXX check duplicates
>
> Yes, definitely.
Yep, I was just thinking that without freeing, the uniqueness really
falls apart. If we hotplug a nic multiple times on the source
> On 06/08/2010 09:30 PM, Paul Brook wrote:
> >> The offset given to a block created via qemu_ram_alloc/map() is
> >> arbitrary, let the caller specify a name so we can make a positive
> >> match.
> >>
> >>
> >> @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev)
> >> +snprin
On 06/08/2010 09:30 PM, Paul Brook wrote:
The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
let the caller specify a name so we can make a positive match.
@@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev)
+snprintf(name, sizeof(name), "pc
> The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
> let the caller specify a name so we can make a positive match.
> @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev)
> +snprintf(name, sizeof(name), "pci:%02x.%x.rom",
> + PCI_SLOT(pdev-
> >>>Once you eliminate machine_register_core that knowledge has
> >>>
> >>> somehow got to come from your device tree description file. Having a
> >>> single device tree that can morph into significantly different machines
> >>> seems like unnecessary complexity given this is a user-specifie
On 06/08/2010 11:32 PM, Alex Williamson wrote:
On Tue, 2010-06-08 at 15:11 -0600, Alex Williamson wrote:
Allows us to compress the protocol a bit.
...
@@ -284,6 +290,33 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage,
void *opaque)
return (stage == 2)&& (expected_time<= migra
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Tue, 2010-06-08 at 14:26 -0700, Chris Wright wrote:
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> > > extern int phys_ram_fd;
> > > -extern uint8_t *phys_ram_dirty;
> > > extern ram_addr_t ram_size;
> > > -extern ram_addr_t
On Tue, 2010-06-08 at 14:26 -0700, Chris Wright wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > extern int phys_ram_fd;
> > -extern uint8_t *phys_ram_dirty;
> > extern ram_addr_t ram_size;
> > -extern ram_addr_t last_ram_offset;
> > +
> > +typedef struct RAMBlock {
> > +uin
* Alex Williamson (alex.william...@redhat.com) wrote:
> +// XXX check duplicates
Yes, definitely. You created a notion of a hierarchical namespace,
can this be formalized any more? Currently scattered...
> +char name[14];
> +snprintf(name, sizeof(name), "pci:
On Tue, 2010-06-08 at 13:54 -0700, Chris Wright wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > @@ -257,7 +272,7 @@ int ram_load(QEMUFile *f, void *opaque, int version_id)
> > ram_addr_t addr;
> > int flags;
> >
> > -if (version_id != 3) {
> > +if (version_id
On Tue, 2010-06-08 at 15:11 -0600, Alex Williamson wrote:
> Allows us to compress the protocol a bit.
...
> @@ -284,6 +290,33 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage,
> void *opaque)
> return (stage == 2) && (expected_time <= migrate_max_downtime());
> }
>
> +static inlin
* Alex Williamson (alex.william...@redhat.com) wrote:
> extern int phys_ram_fd;
> -extern uint8_t *phys_ram_dirty;
> extern ram_addr_t ram_size;
> -extern ram_addr_t last_ram_offset;
> +
> +typedef struct RAMBlock {
> +uint8_t *host;
> +ram_addr_t offset;
> +ram_addr_t length;
> +
On 08.06.2010, at 18:15, Anthony Liguori wrote:
>
>> 4) expose everything to the user, at the cost of regretting it later. This
>> is the current patchset.
>>
>>
>> One "smart way to implement default devices" could be an inclusion mechanism
>> where a machine can ask qemu to read other conf
* Alex Williamson (alex.william...@redhat.com) wrote:
> No reason not to call qemu_ram_map() once we have the allocation
> and remove duplicate code.
>
> Signed-off-by: Alex Williamson
good cleanup regardless
Acked-by: Chris Wright
On Tue, 08 Jun 2010 11:01:19 -0500
Anthony Liguori wrote:
> On 06/08/2010 10:05 AM, Chris Wright wrote:
[...]
> > migration events?
> > - QMP (wire protocol) has nice async events
> >- QError reasonable
> >- migration is async command, can complete w/ error or success
> > - QMP broken f
On 06/08/2010 03:59 PM, Luiz Capitulino wrote:
Now, QError.
This is something I think we should fix for 0.13. However, I still don't
know how to get it right: most of what you say in the wiki page has already
been discussed before.
For example, you suggest the error object should be retur
On 06/08/2010 04:05 PM, Alexander Graf wrote:
On 08.06.2010, at 18:15, Anthony Liguori wrote:
4) expose everything to the user, at the cost of regretting it later. This is
the current patchset.
One "smart way to implement default devices" could be an inclusion mechanism
where a ma
Allows us to compress the protocol a bit.
Signed-off-by: Alex Williamson
---
arch_init.c | 77 +--
1 files changed, 43 insertions(+), 34 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 5780195..8ae6a10 100644
--- a/arch_init.c
On Tue, 2010-06-08 at 15:12 -0500, Anthony Liguori wrote:
> On 06/08/2010 02:16 PM, Alex Williamson wrote:
> > if (is_dup_page(p, *p)) {
> > -qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_COMPRESS);
> > +qemu_put_be64(f, offset | RAM_SAVE_FLAG_COMPRESS)
* Alex Williamson (alex.william...@redhat.com) wrote:
> @@ -257,7 +272,7 @@ int ram_load(QEMUFile *f, void *opaque, int version_id)
> ram_addr_t addr;
> int flags;
>
> -if (version_id != 3) {
> +if (version_id < 3) {
> return -EINVAL;
Should we clamp to 3 and 4?
>
Signed-off-by: Nathan Froyd
---
target-mips/translate_init.c | 61 ++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index b79ed56..8e17f4b 100644
--- a/target-mips/translate_in
Unlike MIPS16, microMIPS lets you choose the ISA mode for your exception
handlers. The ISA mode is selectable via a user-writable CP0.Config3
flag.
Signed-off-by: Nathan Froyd
---
target-mips/cpu.h|1 +
target-mips/helper.c | 21 +++--
2 files changed, 16 insertions(+)
Change code handling mips16-specific branches to use ISA-neutral special
opcodes. Since there are several places where the delay slot
requirements for microMIPS branches differ from mips16 branches, using
opcodes is easier than checking hflags, then checking mips16
vs. microMIPS.
Signed-off-by: N
Add FMT_* constants for the floating-point format field in opcodes and
tweak a few places to use them. Add enums for various invocations of
FOP and tweak gen_farith and its lone caller accordingly.
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 437 --
Move all knowledge about coprocessor-checking and register numbering
into the gen_cmp* helper functions.
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 164 +++
1 files changed, 81 insertions(+), 83 deletions(-)
diff --git a/target-mips/tr
Signed-off-by: Nathan Froyd
---
hw/mips_mipssim.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
index a747de5..293d99e 100644
--- a/hw/mips_mipssim.c
+++ b/hw/mips_mipssim.c
@@ -106,7 +106,10 @@ static void main_cpu_reset(void
Signed-off-by: Nathan Froyd
---
linux-user/main.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 0f23fc9..ad292f1 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3271,7 +3271,10 @@ int main(int argc, char **argv
This patch series adds support for the microMIPS ASE. microMIPS is a
new ASE similar to MIPS16, but re-encodes the entire instruction set
into 16-bit and 32-bit instructions--in contrast to MIPS16, which
re-encodes only integer instructions. The mechanisms for going in and
out of microMIPS mode a
On 06/08/2010 02:16 PM, Alex Williamson wrote:
Synchronize RAM blocks with the target and migrate using name/offset
pairs. This ensures both source and target have the same view of
RAM and that we get the right bits into the right slot.
Signed-off-by: Alex Williamson
---
arch_init.c | 103 +
On Tue, 2010-06-08 at 15:07 -0500, Anthony Liguori wrote:
> On 06/08/2010 02:15 PM, Alex Williamson wrote:
> > The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
> > let the caller specify a name so we can make a positive match.
> >
> > Note, this only addresses the qemu-kvm
On 06/08/2010 02:15 PM, Alex Williamson wrote:
The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
let the caller specify a name so we can make a positive match.
Note, this only addresses the qemu-kvm callers so far.
Signed-off-by: Alex Williamson
---
cpu-all.h
Synchronize RAM blocks with the target and migrate using name/offset
pairs. This ensures both source and target have the same view of
RAM and that we get the right bits into the right slot.
Signed-off-by: Alex Williamson
---
arch_init.c | 103 ++
The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
let the caller specify a name so we can make a positive match.
Note, this only addresses the qemu-kvm callers so far.
Signed-off-by: Alex Williamson
---
cpu-all.h |1 +
cpu-common.h |4 ++-
This makes the RAM block list easier to manipulate. Also incorporate
relevant variables into the RAMList struct.
Signed-off-by: Alex Williamson
---
arch_init.c | 14 ++-
cpu-all.h | 28 ---
exec.c | 72 ++-
We currently need this either to allocate the next ram_addr_t for a
new block, or for total memory to be migrated. Both of which we can
calculate without need of this to keep us in a contiguous address space.
Signed-off-by: Alex Williamson
---
arch_init.c | 23 ---
cpu-al
We don't want to assume a contiguous address space, so migrate based
on RAM blocks instead of a fixed linear address map.
Signed-off-by: Alex Williamson
---
arch_init.c | 67 +--
1 files changed, 42 insertions(+), 25 deletions(-)
diff -
No reason not to call qemu_ram_map() once we have the allocation
and remove duplicate code.
Signed-off-by: Alex Williamson
---
exec.c | 37 ++---
1 files changed, 10 insertions(+), 27 deletions(-)
diff --git a/exec.c b/exec.c
index 7b0e1c5..c60f9e7 100644
---
As we discussed at the KVM developer call this morning, there are
a number of issues with how we migrate RAM in the presence of
hotplug, particularly:
- RAM allocated on the source may not match the target
- Abiguity of ram_addr_t between source and target
- Inability to remove RAM
- etc...
T
I am experiencing similar problems with Win2008 / Win7 guests; BSOD when
trying to install; sometimes before the first screen, sometimes just
after.
Using Ubuntu Lucid:
kernel 2.6.32-21-server
qemu-kvm-0.12.3
Also on Fedora 12:
kernel 2.6.32.12-115.fc12.x86_64
qemu-0.11.0-13.fc12.x86_64
qemu-syst
On Mon, 7 Jun 2010 10:20:47 +0530 (IST)
akshay st wrote:
> Hello,
> Basically i want to seperate QEMU(Instruction translations, hardware
> emulation drivers etc...) and Simulators (UI,events etc...), Someone
> suggested me to use json mechanism. I want to understand more on json, can u
> pleas
2010/6/4 Blue Swirl :
> On Tue, Jun 1, 2010 at 8:16 PM, Artyom Tarasenko
> wrote:
>> 2010/6/1 Blue Swirl :
>>> On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko
>>> wrote:
2010/6/1 Blue Swirl :
> On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko
> wrote:
>> lower interrupt durin
On 06/08/2010 09:37 AM, Paul Brook wrote:
I see three possible options to handle this.
(1) Write a hub (or morph the current vlan code into this). Then
you can do something like:
qemu -netdev socket,id=p1 \
-netdev user,id=p2 \
On Mon, May 24, 2010 at 09:19:35AM -0700, Nathan Froyd wrote:
>
> Signed-off-by: Nathan Froyd
> ---
> target-mips/translate.c | 106
> ++-
> 1 files changed, 59 insertions(+), 47 deletions(-)
Thanks, applied.
> diff --git a/target-mips/translate.c
"Daniel P. Berrange" writes:
> When mistakenly configuring two devices in the same PCI slot,
> QEMU gives a not entirely obvious message about a 'devfn' being
> in use:
>
> $ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
> qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0
On (Tue) Jun 08 2010 [18:33:00], Markus Armbruster wrote:
> Amit Shah writes:
>
> > The correct model type wasn't getting added when hotplugging nics with
> > pci_add.
> >
> > Testcase: start VM with default nic type. In the qemu_monitor:
> >
> > (qemu) pci_add auto nic model=virtio
> >
> > This
One "smart way to implement default devices" could be an inclusion
mechanism where a machine can ask qemu to read other config files.
Then you'd have config files for the default serial/parallel/etc.
This could also be implemented on top of choices 2/3/4 though.
Defaults are tough because
On (Tue) Jun 08 2010 [17:31:04], Gerd Hoffmann wrote:
> On 06/08/10 17:17, Amit Shah wrote:
> >The correct model type wasn't getting added when hotplugging nics with
> >pci_add.
> >
> >Testcase: start VM with default nic type. In the qemu_monitor:
> >
> >(qemu) pci_add auto nic model=virtio
> >
> >
Amit Shah writes:
> The correct model type wasn't getting added when hotplugging nics with
> pci_add.
>
> Testcase: start VM with default nic type. In the qemu_monitor:
>
> (qemu) pci_add auto nic model=virtio
>
> This results in a nic hot-plug of the same nic type as the default.
Works fine for
Am 07.06.2010 12:06, schrieb Christoph Hellwig:
> Use bdrv_pwrite to access the backing device instead of pread, and
> convert the driver to implementing the bdrv_open method which gives
> it an already opened BlockDriverState for the underlying device.
>
> Signed-off-by: Christoph Hellwig
Thank
On 06/08/2010 10:05 AM, Chris Wright wrote:
Accelerating counters (aka moving PIT to userspace, keeping HPET in
userspace)
- PIT (in-kernel, userspace, or split)
- userspace PIT, too slow
- kernel PIT (already seen bugs)
- split PIT, not realistic w/out a sane interface (see bugs above)
- exit to
Well, I tried your command line and I've got the bug "qemu: could not
load PC BIOS 'bios.bin'"
It seems something went wrong with my compiled qemu. I'll try qemu.git
now.
--
WinXP install cd hangs at boot time if machine started with floppy
https://bugs.launchpad.net/bugs/586420
You received thi
Pass the MultiReqBuffer structure down all the way to the I/O submission
instead of takin it apart. Also mark num_writes unsigned as it can't
go negative, and take the check for any pending I/O requests into the
submission function. Last but not least rename do_multiwrite to
virtio_submit_multiwr
> > Once you eliminate machine_register_core that knowledge has
> >
> > somehow got to come from your device tree description file. Having a
> > single device tree that can morph into significantly different machines
> > seems like unnecessary complexity given this is a user-specified file.
>
There is a 1:1 relation between VirtIOBlock and BlockDriverState instances,
no need to track it because it won't change.
Signed-off-by: Christoph Hellwig
Index: qemu/hw/virtio-blk.c
===
--- qemu.orig/hw/virtio-blk.c 2010-05-26 13:
On 06/08/2010 10:58 AM, Paolo Bonzini wrote:
On 06/08/2010 05:36 PM, Paul Brook wrote:
Once you eliminate machine_register_core that knowledge has
somehow got to come from your device tree description file. Having a
single device tree that can morph into significantly different
machines
s
On 06/08/10 17:17, Amit Shah wrote:
The correct model type wasn't getting added when hotplugging nics with
pci_add.
Testcase: start VM with default nic type. In the qemu_monitor:
(qemu) pci_add auto nic model=virtio
>
This results in a nic hot-plug of the same nic type as the default.
Same
On 06/08/2010 09:30 AM, Paul Brook wrote:
I'm undecided how much parameterisation it's worth trying to support in
the device tree. IMO the current code has way too much magic, because
creating a new variant involves hacking and rebuilding pc.c.
See patch 22/22. There is really no magic
On 06/08/2010 10:37 AM, Gerd Hoffmann wrote:
What'd expect is:
[net "user"]
guestfwd = ..
I think multiple entry options are probably not a good thing to have.
We already have them though (-net switch so QemuOpts added them).
Yeah, but let's ignore that for the moment. If we didn't have
On 06/08/2010 08:44 AM, Gerd Hoffmann wrote:
On 06/08/10 15:07, Anthony Liguori wrote:
Note that this reverses the ordering for users which want multiple
values (slirp forwarding for example).
And qemu_opt_find seems to have thought about this too:
static QemuOpt *qemu_opt_find(QemuOpts *opts
Accelerating counters (aka moving PIT to userspace, keeping HPET in
userspace)
- PIT (in-kernel, userspace, or split)
- userspace PIT, too slow
- kernel PIT (already seen bugs)
- split PIT, not realistic w/out a sane interface (see bugs above)
- exit to userspace is a base cost, add MSR save/restor
On 06/08/2010 05:36 PM, Paul Brook wrote:
Once you eliminate machine_register_core that knowledge has
somehow got to come from your device tree description file. Having a
single device tree that can morph into significantly different machines
seems like unnecessary complexity given this is a
Public bug reported:
The thumb2 and unsigned arm state SIMD add/sub instructions are
implemented incorrectly, for example:
UQSUB8 r0, r1, r0
gives r0 as 0, where r0 is 0x12345678 and r1 is 0x23456789 in ARM
state, and:
UHSUB8 r0, r1, r0
gives r0 as 0xbe01, where r0 is 0x12345678 and r
Amit Shah wrote:
> The correct model type wasn't getting added when hotplugging nics with
> pci_add.
>
> Testcase: start VM with default nic type. In the qemu_monitor:
>
> (qemu) pci_add auto nic model=virtio
>
> This results in a nic hot-plug of the same nic type as the default.
>
> This was brok
The correct model type wasn't getting added when hotplugging nics with
pci_add.
Testcase: start VM with default nic type. In the qemu_monitor:
(qemu) pci_add auto nic model=virtio
This results in a nic hot-plug of the same nic type as the default.
This was broken in 5294e2c774f120e10b44652ac143
Hi,
This currently adds an emulated USB webcam compliant with USB Video Class
Specification 1.0a.
It only works on Linux guests and feeds the emulated device using a Video4Linux
2 host device, as long as it supports 320x240 MJPEG format.
This is a Request for Comments as surely code needs some
What'd expect is:
[net "user"]
guestfwd = ..
I think multiple entry options are probably not a good thing to have.
We already have them though (-net switch so QemuOpts added them).
cheers,
Gerd
Signed-off-by: Natalia Portillo
---
Makefile.objs |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index 110f8fd..1535b61 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -70,6 +70,7 @@ common-obj-y += scsi-disk.o cdrom.o
common-obj-y += scs
Signed-off-by: Natalia Portillo
---
hw/usb-uvc.c | 1096 ++
1 files changed, 1096 insertions(+), 0 deletions(-)
create mode 100644 hw/usb-uvc.c
diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
new file mode 100644
index 000..b711f51
--- /dev/n
The correct model type wasn't getting added when hotplugging nics with
pci_add.
Testcase: start VM with default nic type. In the qemu_monitor:
(qemu) pci_add auto nic model=virtio
This results in a nic hot-plug of the same nic type as the default.
Signed-off-by: Amit Shah
---
net.c |6 +++
On 06/08/2010 09:38 AM, Paul Brook wrote:
The problem I was trying to address can be seen with something like:
-drive file=foo.img,if=virtio,file=bar.img
You get no error, and foo.img is what gets used. It's fair to argue
this is a silly use case but what I'm trying to achieve is to make it
po
> The magic I'm preferring to is precisely things like pci="on".
Hmm, pci=on is magic indeed. :-)
> What I'm objecting to is making machine construction be controlled by an
> arbitrary set of hardcoded parameters.
> My argument is that in the short term this parameterization provides limited
>
> The problem I was trying to address can be seen with something like:
>
> -drive file=foo.img,if=virtio,file=bar.img
>
> You get no error, and foo.img is what gets used. It's fair to argue
> this is a silly use case but what I'm trying to achieve is to make it
> possible to do:
>
> -drive file
> I see three possible options to handle this.
>
>(1) Write a hub (or morph the current vlan code into this). Then
>you can do something like:
>
> qemu -netdev socket,id=p1 \
> -netdev user,id=p2 \
> -netdev dump,id=p3 \
>
> > I'm undecided how much parameterisation it's worth trying to support in
> > the device tree. IMO the current code has way too much magic, because
> > creating a new variant involves hacking and rebuilding pc.c.
>
> See patch 22/22. There is really no magic involved, even though the
> compat m
On 06/08/10 15:02, Anthony Liguori wrote:
On 06/08/2010 06:09 AM, Michael S. Tsirkin wrote:
On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote:
On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote:
So I see two ways to go forward: switch default value in my patch,
or disable vlans unc
On Tue, Jun 08, 2010 at 11:16:48PM +0900, Isaku Yamahata wrote:
> On Tue, Jun 08, 2010 at 02:58:25PM +0100, Daniel P. Berrange wrote:
> > When mistakenly configuring two devices in the same PCI slot,
> > QEMU gives a not entirely obvious message about a 'devfn' being
> > in use:
> >
> > $ qemu -de
When mistakenly configuring two devices in the same PCI slot,
QEMU gives a not entirely obvious message about a 'devfn' being
in use:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0x3: PCI: devfn 24 not
available for virti
On Tue, Jun 08, 2010 at 02:58:25PM +0100, Daniel P. Berrange wrote:
> When mistakenly configuring two devices in the same PCI slot,
> QEMU gives a not entirely obvious message about a 'devfn' being
> in use:
>
> $ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
> qemu-kvm: -devi
Am 08.06.2010 15:40, schrieb Miguel Di Ciurcio Filho:
> Both bdrv_can_snapshot() and bdrv_has_snapshot() does not work as advertized.
>
> First issue: Their names implies different porpouses, but they do the same
> thing
> and have exactly the same code. Maybe copied and pasted and forgotten?
> b
This patch updates the megasas HBA emulation to version 1.01.
It fixes the following issues:
- Remove hand-crafted inquiry command
- Remove bounce-buffer for direct commands
- Implements qdev properties to set 'max_sge', 'max_cmds'.
- Implement JBOD mode
- Improve direct command handling
- Minor
On 06/07/2010 10:12 PM, Paul Brook wrote:
This series introduces a rather radical change in the way we deal with
machine definitions in QEMU.
I think we should aim to eliminate machine_register_core, and design
appropriately. In particular I'd try and avoid adding options that become
triv
On 06/08/2010 04:38 PM, Peter Lieven wrote:
Avi Kivity wrote:
On 06/08/2010 04:28 PM, Peter Lieven wrote:
i will retry the case later today and send info register output.
what is the recommended value for nx (and why)?
Enabled (so you get no-execute memory protection).
do you have a guide
Both bdrv_can_snapshot() and bdrv_has_snapshot() does not work as advertized.
First issue: Their names implies different porpouses, but they do the same thing
and have exactly the same code. Maybe copied and pasted and forgotten?
bdrv_has_snapshot() is called in various places for actually checkin
Avi Kivity wrote:
On 06/08/2010 04:28 PM, Peter Lieven wrote:
i will retry the case later today and send info register output.
what is the recommended value for nx (and why)?
Enabled (so you get no-execute memory protection).
do you have a guideline which flags should be identical to ensur
On 06/08/10 15:07, Anthony Liguori wrote:
Note that this reverses the ordering for users which want multiple
values (slirp forwarding for example).
And qemu_opt_find seems to have thought about this too:
static QemuOpt *qemu_opt_find(QemuOpts *opts, const char *name)
{
QemuOpt *opt;
QTAILQ_FO
Avi Kivity wrote:
On 06/08/2010 04:38 PM, Peter Lieven wrote:
Avi Kivity wrote:
On 06/08/2010 04:28 PM, Peter Lieven wrote:
i will retry the case later today and send info register output.
what is the recommended value for nx (and why)?
Enabled (so you get no-execute memory protection).
When mistakenly configuring two devices in the same PCI slot,
QEMU gives a not entirely obvious message about a 'devfn' being
in use:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0x3: PCI: devfn 24 not
available for virti
On 06/08/2010 04:44 PM, Peter Lieven wrote:
-cpu host is good if you have identical machines and don't plan to
add new ones.
i will likely add new ones, but my plan would be to use qemu64 and
then add all flags manually that
are common to all cpus in the pool.
would that be safe?
Yes.
--
e
On 06/08/2010 04:28 PM, Peter Lieven wrote:
i will retry the case later today and send info register output.
what is the recommended value for nx (and why)?
Enabled (so you get no-execute memory protection).
do you have a guideline which flags should be identical to ensure
proper live migr
On Tue, Jun 08, 2010 at 08:02:27AM -0500, Anthony Liguori wrote:
> On 06/08/2010 06:09 AM, Michael S. Tsirkin wrote:
>> On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote:
>>
>>> On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote:
>>>
So I see two ways to go forward: switc
On 06/08/10 15:09, Anthony Liguori wrote:
On 06/08/2010 03:03 AM, Gerd Hoffmann wrote:
+ .opts_default = (QemuOptValue[]) {
+ {
+ .name = "acpi",
+ .value = "on",
+ },
Should be moved into a separate struct and just referenced as it is
identical for pc-0.*
Would need to be macros because in
On 06/08/10 13:50, Paul Brook wrote:
Kill nographic timer. Have a global gui_timer instead. Have the gui
timer enabled unconditionally. We need a timer running anyway for mmio
flush, so the whole have-gui-timer-only-when-needed logic is pretty
pointless. It also simplifies displaylisteners co
On Tue, Jun 08, 2010 at 08:03:33AM -0500, Anthony Liguori wrote:
> On 06/08/2010 07:13 AM, Michael S. Tsirkin wrote:
>> On Mon, Jun 07, 2010 at 04:57:09PM -0500, Anthony Liguori wrote:
>>
>>> On 06/07/2010 04:37 PM, Anthony Liguori wrote:
>>>
On 06/07/2010 03:58 PM, Michael S. Tsirki
Avi Kivity wrote:
On 06/08/2010 03:49 PM, Peter Lieven wrote:
And finally, perhaps you have NX disabled in the bios of one of the
machines?
What does 'dmesg | grep NX' show on both hosts?
nx was disabled on one of the nodes.
That explains the problem.
i will retry the case later toda
1 - 100 of 152 matches
Mail list logo
