Introduce documentation for qemu-core-filter in .texi format and update
Makefile to generate man page. Modified qemu-doc.texi to include documentation
for qemu-core-filter tool as a new chapter.
Signed-off-by: Mahesh Salgaonkar
---
Makefile | 14 ++--
qemu-core-filter.texi |
Hi All,
Please find the patch series that implements qemu-core-filter, a userspace
tool to filter out guest OS memory from qemu coredump.
The qemu-core-filter tool is a post-processing tool works offline on qemu
coredumps. When qemu[-kvm] application crashes, it generates a huge coredump
file t
Rusty Russell wrote:
> On Tue, 22 Jun 2010 02:13:21 am Ryan Harper wrote:
>> * john cooper [2010-06-21 01:11]:
>>> Rusty Russell wrote:
/* id_str is not necessarily nul-terminated! */
buf[VIRTIO_BLK_ID_BYTES] = '\0';
return virtblk_get_id(disk, buf);
>>> The /sys file is re
PCIDevice::romfile is allocatedi n pci_qdev_init(). But nowhere freed.
Free it in do_pci_unregister_device().
Cc: Gerd Hoffmann
Signed-off-by: Isaku Yamahata
---
hw/pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 7787005..7e5c539 100644
-
make pci hotplug callback return value to caller.
And when returning error, allocated resources are freed.
Signed-off-by: Isaku Yamahata
---
hw/pci.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 75acbd3..76418c5 100644
--- a/hw
When pci deivce is freed, the option rom isn't freed.
Although qemu_ram_free() is nop right now in fact, pci layer should
be prepared for it.
Cc: Gerd Hoffmann
Signed-off-by: Isaku Yamahata
---
hw/pci.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c
pci qdev exit code patch(pci_unregister_device) doesn't release
all the resource allocated by pci qdev initialization.(pci_qdev_init)
This patch series sorts it out and make pci::hotplug error code to the caller.
Isaku Yamahata (3):
pci: fix memory leak of PCIDevice::romfile.
pci: option rom c
On Tue, Jun 15, 2010 at 12:51:16PM +0900, Isaku Yamahata wrote:
> allow qemu to load dsdt as external acpi table.
I'm okay with the general idea. However, I don't much like building
and copying the dsdt just to free it later. It would be preferable if
the code would load in all the qemu provided
Hi,
I should have written the infomation for u-boot's board configuration.
> (2) build u-boot(2010.03) by the (1)compiler.
I rewrite configuration file for 'qemu-mips':
u-boot-2010.03/board/qemu-mips/u-bool.lds
--[original]
/*
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
*/
Hi,
I have built u-boot binary for 'qemu-system-mips -M mips'.
It is fine to run ths u-boot binary.
But the same u-boot binary does not run on 'qemu-system-mips64 -M mips'.
I do not understand what happends on the qemu-mips64 execution.
Is this a bug for qemu-system-mips64 ?
Or should I build u-b
On Tue, 22 Jun 2010 02:13:21 am Ryan Harper wrote:
> * john cooper [2010-06-21 01:11]:
> > Rusty Russell wrote:
> > > On Sat, 19 Jun 2010 04:08:02 am Ryan Harper wrote:
> > >> Create a new attribute for virtio-blk devices that will fetch the serial
> > >> number
> > >> of the block device. This
On Mon, Jun 21, 2010 at 10:58:32PM +0200, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Marcelo Tosatti wrote:
> >> Clear exit_request when iothread grabs the global lock.
> >>
> >> Signed-off-by: Marcelo Tosatti
> >>
> >> diff --git a/cpu-exec.c b/cpu-exec.c
> >> index 026980a..74cb973 100644
> >> -
On (09:43 21/06/10), Anthony Liguori put forth the
proposition:
On 06/19/2010 08:58 PM, David Woodfall wrote:
Hi, I'm the maintainer for the kqemu and now qemu 0.11 slackbuilds at
slackbuilds.org and just wanted to find out if the old 0.11 sources
are likely to be continued to be hosted, or if
SYNOPSIS
size[4] Tlcreate tag[2] fid[4] name[s] flags[4] mode[4] gid[4]
size[4] Rlcreate tag[2] qid[13] iounit[4]
DESCRIPTION
The Tlreate request asks the file server to create a new regular file with the
name supplied, in the directory (dir) represented by fid.
The mode argument specif
On 22.06.2010, at 00:13, Jan Kiszka wrote:
> Jan Kiszka wrote:
>> And there is some race that cause a lock up in qemu_mutex_lock_iothread
>> after a while (the cpu_unlink_tb seems to race with the linking - just a
>> guess so far).
>
> This seems to fix a long-standing race between cpu_exec and
Jan Kiszka wrote:
> And there is some race that cause a lock up in qemu_mutex_lock_iothread
> after a while (the cpu_unlink_tb seems to race with the linking - just a
> guess so far).
This seems to fix a long-standing race between cpu_exec and
signal-driven cpu_unlink_tb:
diff --git a/cpu-exec.c
Jan Kiszka wrote:
> Marcelo Tosatti wrote:
>> Clear exit_request when iothread grabs the global lock.
>>
>> Signed-off-by: Marcelo Tosatti
>>
>> diff --git a/cpu-exec.c b/cpu-exec.c
>> index 026980a..74cb973 100644
>> --- a/cpu-exec.c
>> +++ b/cpu-exec.c
>> @@ -236,10 +236,8 @@ int cpu_exec(CPUSt
These commands show the information about active backend network devices.
Changes from v2
---
- Got rid of vlans, a separate command for them will be created if needed
- Removed socket as a type (it is used to connect vlans)
- 'script', 'downscript' and 'vhostfd' are now optional when
Marcelo Tosatti wrote:
> Clear exit_request when iothread grabs the global lock.
>
> Signed-off-by: Marcelo Tosatti
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 026980a..74cb973 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -236,10 +236,8 @@ int cpu_exec(CPUState *env1)
> asm("");
Debugging with gdb-stub does not work with qemu-system-sparc target
Qemu compiled from current git tree.
execution string: qemu-system-sparc.exe -s -S -m 256 -L Bios -hda
sparc.img -boot c
connect with telnet localhost 1234
enter '$s#73' (without quotes, this is single step command to gdb stub)
g
Clear exit_request when iothread grabs the global lock.
Signed-off-by: Marcelo Tosatti
diff --git a/cpu-exec.c b/cpu-exec.c
index 026980a..74cb973 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -236,10 +236,8 @@ int cpu_exec(CPUState *env1)
asm("");
env = env1;
-if (exit_request)
On Thu, Jun 17, 2010 at 04:48:09PM +0900, Isaku Yamahata wrote:
> Thanks for the patch.
> Does vista boot with the patch eventually?
As I mentioned before, Windows boots but PCIe root ports fail with a
resource allocation error. Digging into it, it looks like the issue is
with IRQ assignment. I'
The MASTER_DISABLE bit (aka mask-all) masks all the interrupts.
According to Sun-4M System Architecture
"The level–15 interrupt sources [...] are maskable with the Interrupt Target
Mask Register. While these interrupts are considered ’non–maskable’ within
the SPARC IU, a mask capability is provide
2010/5/25 Blue Swirl :
>>> About bugs, IIRC NetBSD 3.x crash could be related to IOMMU.
>>
>> What does indicate it? It happens where the disk sizes are normally
>> reported, so it could be a scsi/dma/irq/fpu issue as well.
>
> IIRC the DVMA address was 0xfc004000, but the mapped entries were for
>
On Mon, Jun 21, 2010 at 11:42 AM, Luiz Capitulino
wrote:
>> +- "info": json-object containing the configuration information about the
>> device.
>> + - When "type" is "tap", the following values might be available:
>> + - "fd": available if connected to an already opened TAP
>>
Ryan Harper wrote:
> * john cooper [2010-06-21 01:11]:
>> Rusty Russell wrote:
>>> On Sat, 19 Jun 2010 04:08:02 am Ryan Harper wrote:
Create a new attribute for virtio-blk devices that will fetch the serial
number
of the block device. This attribute can be used by udev to create
Jan Kiszka writes:
> Luiz Capitulino wrote:
>> On Fri, 18 Jun 2010 13:26:27 -0300
>> Miguel Di Ciurcio Filho wrote:
>>
>>> These commands show the information about active backend network devices.
>>>
>>> Signed-off-by: Miguel Di Ciurcio Filho
>>> ---
>>> qemu-monitor.hx | 105
>>> +
* Christoph Hellwig [2010-06-21 07:46]:
> On Fri, Jun 18, 2010 at 01:38:02PM -0500, Ryan Harper wrote:
> > Create a new attribute for virtio-blk devices that will fetch the serial
> > number
> > of the block device. This attribute can be used by udev to create
> > disk/by-id
> > symlinks for de
Luiz Capitulino writes:
> On Mon, 21 Jun 2010 10:12:06 +0200
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
>>
>> > On Wed, 02 Jun 2010 09:31:24 +0200
>> > Markus Armbruster wrote:
>> >
>> >> Luiz Capitulino writes:
>> >
>> > [...]
>> >
>> >> > static void check_mandatory_args(cons
* john cooper [2010-06-21 01:11]:
> Rusty Russell wrote:
> > On Sat, 19 Jun 2010 04:08:02 am Ryan Harper wrote:
> >> Create a new attribute for virtio-blk devices that will fetch the serial
> >> number
> >> of the block device. This attribute can be used by udev to create
> >> disk/by-id
> >> s
Christoph Hellwig writes:
> On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote:
[...]
>> [2] -blockdev format=vvfat,file=/path/to/directory,id=blk1
>>
>>
>> It's not clear to me why [2] should be transport=vvfat. vvfat really
>> isn't a transport.
>
> Well, it's a wart if you wan
Christoph Hellwig writes:
> On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote:
>> I can appreciate the desire to keep protocols and formats as an internal
>> distinction but as a user visible concept, I think your two examples
>> highlight why exposing protocols as formats make se
On 06/21/2010 11:01 AM, Christoph Hellwig wrote:
On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote:
There's just a couple cases we should consider:
[1] -blockdev format=raw,file=/dev/cdrom,id=blk1
For [1], we just defaulting transport to file is would not give us th
On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote:
> There's just a couple cases we should consider:
>
> [1] -blockdev format=raw,file=/dev/cdrom,id=blk1
> For [1], we just defaulting transport to file is would not give us the
> same semantics we have today. Is that desirable?
By
Kevin Wolf writes:
> Am 21.06.2010 15:37, schrieb Anthony Liguori:
>> On 06/21/2010 08:30 AM, Kevin Wolf wrote:
>>> Am 21.06.2010 15:09, schrieb Anthony Liguori:
>>>
On 06/21/2010 03:19 AM, Kevin Wolf wrote:
> Am 20.06.2010 12:51, schrieb Avi Kivity:
>
>
>>
** Tags added: kernel-reviewed
** Tags removed: kernel-needs-review
--
kernel NULL pointer in -virtual (-server) kernel
https://bugs.launchpad.net/bugs/546458
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Invalid
Statu
** Tags added: kernel-core kernel-needs-review
** Tags removed: needs-kernel-logs needs-upstream-testing
--
kernel NULL pointer in -virtual (-server) kernel
https://bugs.launchpad.net/bugs/546458
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
On 06/21/2010 10:00 AM, Christoph Hellwig wrote:
Keeping these separate makes a lot of sense to me, even with my user
hat on. And as lon as we don't require the transport protocol but fall
back to file it's even more understandable for the users, as he simply
doesn't have to care about it for th
On Mon, 21 Jun 2010 10:12:06 +0200
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > On Wed, 02 Jun 2010 09:31:24 +0200
> > Markus Armbruster wrote:
> >
> >> Luiz Capitulino writes:
> >
> > [...]
> >
> >> > static void check_mandatory_args(const char *cmd_arg_name,
> >> > @@ -4344,6 +
On 06/21/2010 09:01 AM, Kevin Wolf wrote:
No, what I'm saying is that even in your model
-blockdev format=qcow2,file=image.qcow2,id=blk1
becomes qcow2 -> file automatically, whereas
-blockdev format=vvfat,file=/tmp/dir/,id=blk1
doesn't become vvfat -> file, but stays just vvfat.
> The user basically can specify two things:
>
> - a transport protocol. Normally this is just the filesystem
>interface, but it can also be nbd, http or for really sick people
>vvfat. This is a setting which can't be guessed, btw - it needs
>to be explicitly set in some way, with f
> Thanks for your reply. This isn't about a specific IOMMU. Let me
> describe the situation better:
>
> 1. I'm implementing the AMD IOMMU, which is a PCI IOMMU (not in the CPU).
> 2. Devices need address translation and checking through this IOMMU.
> 3. But in the future there might be other IOMMU
On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote:
> I can appreciate the desire to keep protocols and formats as an internal
> distinction but as a user visible concept, I think your two examples
> highlight why exposing protocols as formats make sense. A user doesn't
> necessari
On 06/21/2010 09:51 AM, Anthony Liguori wrote:
This is the difference between a protocol and a format.
I can appreciate the desire to keep protocols and formats as an
internal distinction but as a user visible concept,
but *not* as a user visible concept. /me heads for the second cup of
c
On 06/21/2010 09:01 AM, Kevin Wolf wrote:
Am 21.06.2010 15:37, schrieb Anthony Liguori:
On 06/21/2010 08:30 AM, Kevin Wolf wrote:
Am 21.06.2010 15:09, schrieb Anthony Liguori:
On 06/21/2010 03:19 AM, Kevin Wolf wrote:
Am 20.06.2010 12:51, schrieb Avi Kivity:
Luiz Capitulino wrote:
> On Fri, 18 Jun 2010 13:26:27 -0300
> Miguel Di Ciurcio Filho wrote:
>
>> These commands show the information about active backend network devices.
>>
>> Signed-off-by: Miguel Di Ciurcio Filho
>> ---
>> qemu-monitor.hx | 105
>> +
On 06/19/2010 08:58 PM, David Woodfall wrote:
Hi, I'm the maintainer for the kqemu and now qemu 0.11 slackbuilds at
slackbuilds.org and just wanted to find out if the old 0.11 sources
are likely to be continued to be hosted, or if it's likely they may be
removed at some point?
Their location mi
On Fri, 18 Jun 2010 13:26:27 -0300
Miguel Di Ciurcio Filho wrote:
> These commands show the information about active backend network devices.
>
> Signed-off-by: Miguel Di Ciurcio Filho
> ---
> qemu-monitor.hx | 105
> +++
> 1 files changed,
On Mon, Jun 21, 2010 at 03:07:13PM +0100, Paul Brook wrote:
> > So I've been looking for a way to obtain things like a PCIDevice from a
> > more generic structure (say from hw/qdev.h),
>
> If you're having to figure out what kind of a device you have then I think
> you're already doing something
On Mon, 21 Jun 2010 10:27:11 +0200
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > On Fri, 18 Jun 2010 15:28:42 -0500
> > Anthony Liguori wrote:
> >
> >> On 06/18/2010 11:26 AM, Miguel Di Ciurcio Filho wrote:
> >> > These commands show the information about active backend network devi
> So I've been looking for a way to obtain things like a PCIDevice from a
> more generic structure (say from hw/qdev.h),
If you're having to figure out what kind of a device you have then I think
you're already doing something else wrong. I'd expect the bits of code that
needs to identify device
Am 21.06.2010 15:37, schrieb Anthony Liguori:
> On 06/21/2010 08:30 AM, Kevin Wolf wrote:
>> Am 21.06.2010 15:09, schrieb Anthony Liguori:
>>
>>> On 06/21/2010 03:19 AM, Kevin Wolf wrote:
>>>
Am 20.06.2010 12:51, schrieb Avi Kivity:
> On 06/18/2010 03:59 PM, Mar
Hi,
I'm working on implementing AMD IOMMU emulation in QEMU/KVM and I'm also
creating an API for address translation and access checking. Ideally,
this API should work with different kinds of devices and IOMMUs. These
operations would typically require specific device information to figure
out whi
On 06/21/2010 08:30 AM, Kevin Wolf wrote:
Am 21.06.2010 15:09, schrieb Anthony Liguori:
On 06/21/2010 03:19 AM, Kevin Wolf wrote:
Am 20.06.2010 12:51, schrieb Avi Kivity:
On 06/18/2010 03:59 PM, Markus Armbruster wrote:
The code is pretty confused about format vs
Am 21.06.2010 15:09, schrieb Anthony Liguori:
> On 06/21/2010 03:19 AM, Kevin Wolf wrote:
>> Am 20.06.2010 12:51, schrieb Avi Kivity:
>>
>>> On 06/18/2010 03:59 PM, Markus Armbruster wrote:
>>>
The code is pretty confused about format vs. protocol, and so are we.
Let's try to fi
On Mon, Jun 21, 2010 at 03:04:01PM +0900, Isaku Yamahata wrote:
> make pci bridge aware of pci multi function property and let pci generic
> code to set the bit.
>
> Cc: Blue Swirl
> Signed-off-by: Isaku Yamahata
> ---
> hw/apb_pci.c |7 ++-
> hw/dec_pci.c |2 +-
> hw/pci.c |
On Mon, Jun 21, 2010 at 03:03:59PM +0900, Isaku Yamahata wrote:
> diff --git a/hw/piix4.c b/hw/piix4.c
> index f75951b..03926a7 100644
> --- a/hw/piix4.c
> +++ b/hw/piix4.c
> @@ -93,8 +93,7 @@ static int piix4_initfn(PCIDevice *d)
> pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_INTEL);
>
On 06/21/2010 03:19 AM, Kevin Wolf wrote:
Am 20.06.2010 12:51, schrieb Avi Kivity:
On 06/18/2010 03:59 PM, Markus Armbruster wrote:
The code is pretty confused about format vs. protocol, and so are we.
Let's try to figure them out.
From cruising altitude, all this format, protocol,
On Fri, Jun 18, 2010 at 01:38:02PM -0500, Ryan Harper wrote:
> Create a new attribute for virtio-blk devices that will fetch the serial
> number
> of the block device. This attribute can be used by udev to create disk/by-id
> symlinks for devices that don't have a UUID (filesystem) associated wit
On Mon, Jun 21, 2010 at 03:03:58PM +0900, Isaku Yamahata wrote:
> Set PCI multi-function bit according to multifunction property.
> PCI address, devfn ,is exported to users as addr property,
> so users can populate pci function(PCIDevice in qemu)
> at arbitrary devfn.
> It means each function(PCIDe
On Mon, Jun 21, 2010 at 02:40:06PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 15, 2010 at 12:47:27PM +0900, Isaku Yamahata wrote:
> > Make pci hotplug callback return value to caller.
> > There is no reason to discard return value.
> >
> > Signed-off-by: Isaku Yamahata
> > ---
> > hw/pci.c |
On Mon, Jun 21, 2010 at 03:03:56PM +0900, Isaku Yamahata wrote:
> Use PCI_DEVFN() and PCI_FUNC_MAX where appropriate.
> This patch make it clear that func = 0 and
> added assert() to ensure it.
> This patch guarantees that auto assigned function is always
> single function device at function = 0.
>
On Tue, Jun 15, 2010 at 12:47:27PM +0900, Isaku Yamahata wrote:
> Make pci hotplug callback return value to caller.
> There is no reason to discard return value.
>
> Signed-off-by: Isaku Yamahata
> ---
> hw/pci.c | 11 +++
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --
On Tue, Jun 15, 2010 at 12:48:36PM +0900, Isaku Yamahata wrote:
> staticfy pci_device_hot_remove().
>
> Signed-off-by: Isaku Yamahata
Applied, thanks.
> ---
> hw/pci-hotplug.c |2 +-
> sysemu.h |1 -
> 2 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/hw/pci-ho
Am 21.06.2010 10:50, schrieb Yoshiaki Tamura:
> Although it is really rare to get in to the while loop, the list
> operation in the loop is obviously wrong.
>
> Signed-off-by: Yoshiaki Tamura
Thanks, applied to the block branch.
Kevin
Am 20.06.2010 21:03, schrieb MORITA Kazutaka:
> Some block drivers use an aio handler and do I/O completion routines
> in it. However, the handler is not invoked if we only do
> aio_read/write, because registered fds are not checked at all.
>
> This patch registers an aio handler of STDIO to chec
Ping.
Michael, do you have any comment on this?
On Tue, Jun 15, 2010 at 12:48:36PM +0900, Isaku Yamahata wrote:
> staticfy pci_device_hot_remove().
>
> Signed-off-by: Isaku Yamahata
> ---
> hw/pci-hotplug.c |2 +-
> sysemu.h |1 -
> 2 files changed, 1 insertions(+), 2 deletions(
Ping.
Michael, is there any issues to address?
On Tue, Jun 15, 2010 at 12:47:27PM +0900, Isaku Yamahata wrote:
> Make pci hotplug callback return value to caller.
> There is no reason to discard return value.
>
> Signed-off-by: Isaku Yamahata
> ---
> hw/pci.c | 11 +++
> 1 files chang
On Mon, Jun 21, 2010 at 11:45:15AM +0200, Juan Quintela wrote:
> Isaku Yamahata wrote:
> > Set PCI multi-function bit according to multifunction property.
> > PCI address, devfn ,is exported to users as addr property,
> > so users can populate pci function(PCIDevice in qemu)
> > at arbitrary devfn
Isaku Yamahata wrote:
> Set PCI multi-function bit according to multifunction property.
> PCI address, devfn ,is exported to users as addr property,
> so users can populate pci function(PCIDevice in qemu)
> at arbitrary devfn.
> It means each function(PCIDevice) don't know whether pci device
> (PC
(2010/06/21 17:19), Avi Kivity wrote:
> On 06/21/2010 08:24 AM, Hidetoshi Seto wrote:
>> I think some people have noticed that:
>>
>>> $ ./configure
>>> $ make
>>> $ git status
>>> # On branch master
>>> # Untracked files:
>>> # (use "git add ..." to include in what will be committed)
>>> #
>>> #
I'm using Qemu 0.12.4 and VMware SVGA driver. Then I suffered from segmentation
fault when using VNC connecting to my host. After digging into the problem, I
found
it's due to inconsistent depth computation. With VNC connection, depth of SDL
display is set to 16, however what VMware SVGA emulation
Although it is really rare to get in to the while loop, the list
operation in the loop is obviously wrong.
Signed-off-by: Yoshiaki Tamura
---
hw/virtio-blk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 75878eb..0bf929a 100644
On 18.06.2010 18:52, Paul Brook wrote:
$ qemu-system-arm -semihosting -cpu cortex-a9 -nographic -kernel
./input.exe
-nographic implies -monitor stdio -serial stdio. Don't do that if you want to
access stdio via semihosting.
Indeed, using either
-monitor null -serial none -nographic
or
-monit
Luiz Capitulino writes:
> On Fri, 18 Jun 2010 15:28:42 -0500
> Anthony Liguori wrote:
>
>> On 06/18/2010 11:26 AM, Miguel Di Ciurcio Filho wrote:
>> > These commands show the information about active backend network devices.
>> >
>> > Signed-off-by: Miguel Di Ciurcio Filho
>> > ---
>> > qemu-m
Yoshiaki Tamura writes:
> This fixes the following scenario using QMP.
>
> First, put a bogus argument "foo" to "type", which results in an error.
> {"execute": "netdev_add", "arguments": { "type": "foo", "id": "netdev1" } }
> Then, call it again with correct argument "user".
> {"execute": "netde
Anthony Liguori writes:
> On 06/18/2010 11:26 AM, Miguel Di Ciurcio Filho wrote:
>> These commands show the information about active backend network devices.
>>
>> Signed-off-by: Miguel Di Ciurcio Filho
>> ---
>> qemu-monitor.hx | 105
>> +++
Am 20.06.2010 12:51, schrieb Avi Kivity:
> On 06/18/2010 03:59 PM, Markus Armbruster wrote:
>> The code is pretty confused about format vs. protocol, and so are we.
>> Let's try to figure them out.
>>
>> From cruising altitude, all this format, protocol, stacking business
>> doesn't matter. We pr
Luiz Capitulino writes:
> On Wed, 02 Jun 2010 09:31:24 +0200
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
>
> [...]
>
>> > static void check_mandatory_args(const char *cmd_arg_name,
>> > @@ -4344,6 +4413,9 @@ out:
>> > * Client argument checking rules:
>> > *
>> > * 1. Client
Avi Kivity writes:
> On 06/18/2010 03:59 PM, Markus Armbruster wrote:
>> The code is pretty confused about format vs. protocol, and so are we.
>> Let's try to figure them out.
>>
>> From cruising altitude, all this format, protocol, stacking business
>> doesn't matter. We provide a bunch of arg
80 matches
Mail list logo
