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
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
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
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
>> +++
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
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
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
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
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
(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)
>>> #
>>> #
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
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
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
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(
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
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
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
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 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 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: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 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 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 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 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 |
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 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
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
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
> 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
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
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 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 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
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/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:
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 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
> 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
> 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
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.
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 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
** 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
** 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
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:
>
>
>>
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
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
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
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
* 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
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
* 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
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
>>> +
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
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
>>
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
>
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
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'
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)
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
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("");
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
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
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
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
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 (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
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 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
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
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")
*/
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
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
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
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
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
-
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
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
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 |
80 matches
Mail list logo
