On 31 March 2014 08:08, Stefan Hajnoczi wrote:
> Check incoming_posn to avoid out-of-bounds array accesses if the ivshmem
> server on the host sends invalid values.
>
> Cc: Cam Macdonell
> Reported-by: Sebastian Krahmer
> Signed-off-by: Stefan Hajnoczi
> ---
> hw/misc/ivshmem.c | 9 +
>
14.04.2014 17:17, Paolo Bonzini wrote:
[]
>>> * win64 virtio-scsi regression
>>
>> In the absence of any patches here I think we should deem
>> win64 virtio-scsi sufficiently minor that it will get
>> fixed in 2.0.1.
>
> The patch is at
> http://article.gmane.org/gmane.comp.emulators.qemu/264111/
On 14 April 2014 13:30, Michael S. Tsirkin wrote:
> The following changes since commit 590e5dd98fcc926cc3b63aad35aed79235ca4c2a:
>
> configure: Make stack-protector test check both compile and link
> (2014-04-14 12:11:18 +0100)
>
> are available in the git repository at:
>
> git://git.kernel.
On Thursday, April 03, 2014 12:14:21 PM Peter Maydell wrote:
> On 2 April 2014 16:53, Paolo Bonzini wrote:
> > Il 01/04/2014 15:06, Eduardo Otubo ha scritto:
> >> Not sure why it didn't get upstream yet.
> >> Anthony, Peter, could you take a closer look at this?
> >
> > Peter filters on "for you
On Tue, 1 Apr 2014 16:33:02 +0800
Qiao Nuohan wrote:
> Dumping guest memory is available to specify the dump format now. This patch
> adds options '-z|-l|-s' to HMP command dump-guest-memory to specify dumping in
> kdump-compression format, with zlib/lzo/snappy compression. And without these
> op
Public bug reported:
qemu release verison: 1.7.1
guest os : win7 32bits
qemu cmdline:
/usr/bin/qemu-system-x86_64 -name hch_test -S -machine
pc-i440fx-1.7,accel=kvm,usb=off -cpu
SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+
I can confirm the same bug. I am not building from source, but rather
using the unofficial Windows binaries linked to by Qemu.
http://wiki.qemu.org/Links
I'm running as Administrator on Win8.1 x86_64
qemu-system-i386.exe -L . -hda \\.\PhysicalDrive3
qemu-system-i386.exe: -hda \\.\PhysicalDrive
On 14 April 2014 13:14, Michael Tokarev wrote:
> This reverts commit b533f658a98325d0e47b36113bd9f5bcc046fdae.
>
> The original code was wrong, because effectively it ignored errors
> from kernel, because kernel does not return -1 on error case but
> returns -errno, and does not return -EPERM for
On 04/14/2014 01:41 AM, Alexey Kardashevskiy wrote:
> On 04/14/2014 05:34 PM, Alexander Graf wrote:
>>
>> On 11.04.14 18:30, Alexey Kardashevskiy wrote:
>>> On 04/12/2014 02:15 AM, Alexander Graf wrote:
On 11.04.14 18:01, Alexey Kardashevskiy wrote:
> On 04/12/2014 01:38 AM, Alexander Graf
On 04/13/2014 01:08 PM, Lluís Vilanova wrote:
> Signed-off-by: Lluís Vilanova
> ---
> tests/qapi-schema/test-qapi.py |3 ---
> 1 file changed, 3 deletions(-)
Reviewed-by: Eric Blake
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
s
On 04/13/2014 01:07 PM, Lluís Vilanova wrote:
> Signed-off-by: Lluís Vilanova
> ---
> Makefile | 24 ++--
> tests/Makefile | 20
> 2 files changed, 34 insertions(+), 10 deletions(-)
Has this changed from v8?
https://lists.gnu.org/archive/html/q
Am 10.04.2014 17:18, schrieb Alexey Kardashevskiy:
> On 04/11/2014 12:52 AM, Andreas Färber wrote:
>> Am 10.04.2014 16:40, schrieb Alexey Kardashevskiy:
>>> On 04/10/2014 10:40 PM, Alexander Graf wrote:
Juan, is a different command line device order supposed to work with
migration?
>
Hi Markus,
Really appreciate your review first. I almost a new participant. And
I read other's patches very little. So maybe this patch is duplicate to
one of Marcel's patch. But I really do not know. And I really don't
copying Marcel's. This is my own analysis. When I modify this issue, I
o
From: "Dr. David Alan Gilbert"
QEMU will assert if you attempt to start an outgoing migration on
a QEMU that's sitting waiting for an incoming migration (started
with -incoming), so disallow it with a proper error.
(This is a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1086987 )
Signed-
On 4/11/2014 11:16 AM, Alexander Graf wrote:
>
> On 11.04.14 18:12, Tom Musta wrote:
>> On 4/11/2014 10:31 AM, Alexander Graf wrote:
>>> I don't think this is possible. Libdecnumber is GPLv3+ code while QEMU
>>> overall is licensed at GPLv2 only. Gotta love licenses...
>>>
>>> Is there an older,
On 04/14/2014 09:18 AM, Tom Musta wrote:
>
> I am trying to make sense of the contents of the QEMU LICENSE file which
> states this:
>
> "1) QEMU as a whole is released under the GNU General Public License,
> version 2."
>
> but then later states this:
>
> "As of July 2013, contrib
On 04/14/2014 09:23 AM, Eric Blake wrote:
> On 04/14/2014 09:18 AM, Tom Musta wrote:
>>
>> I am trying to make sense of the contents of the QEMU LICENSE file which
>> states this:
>>
>> "1) QEMU as a whole is released under the GNU General Public License,
>> version 2."
>>
>> but then late
Thank you, Eric, for the clarification.
On 31 March 2014 08:08, Stefan Hajnoczi wrote:
> The third argument to the fd_read() callback implemented by
> ivshmem_read() is the number of bytes, not a flags field. Fix this and
> check we received enough bytes before accessing the buffer pointer.
>
> Cc: Cam Macdonell
> Reported-by: Sebasti
Am 14.04.2014 17:16, schrieb Dr. David Alan Gilbert (git):
> From: "Dr. David Alan Gilbert"
>
> QEMU will assert if you attempt to start an outgoing migration on
> a QEMU that's sitting waiting for an incoming migration (started
> with -incoming), so disallow it with a proper error.
>
> (This is
On 04/15/2014 01:16 AM, Andreas Färber wrote:
> Am 10.04.2014 17:18, schrieb Alexey Kardashevskiy:
>> On 04/11/2014 12:52 AM, Andreas Färber wrote:
>>> Am 10.04.2014 16:40, schrieb Alexey Kardashevskiy:
On 04/10/2014 10:40 PM, Alexander Graf wrote:
>
> Juan, is a different command line
Am 14.04.2014 17:33, schrieb Peter Maydell:
> On 31 March 2014 08:08, Stefan Hajnoczi wrote:
>> The third argument to the fd_read() callback implemented by
>> ivshmem_read() is the number of bytes, not a flags field. Fix this and
>> check we received enough bytes before accessing the buffer point
Am 14.04.2014 09:13, schrieb Markus Armbruster:
> Alistair Francis writes:
>
>> On Wed, Apr 9, 2014 at 9:58 PM, Peter Crosthwaite
>> wrote:
>>> On Wed, Apr 9, 2014 at 7:56 PM, Markus Armbruster wrote:
We have a number of device model names containing '.'. They're unusable
with -globa
Am 07.04.2014 04:26, schrieb Alexey Kardashevskiy:
> Why not to make a memory controller + bus instead? I thought this is the
> preferred approach in qom'ed QEMU :)
That's the historic approach of qdev, not QOM.
See:
http://www.linux-kvm.org/wiki/images/0/0b/Kvm-forum-2013-Modern-QEMU-devices.pd
Am 04.04.2014 15:36, schrieb Igor Mammedov:
> so that managment could detect via QOM interface if device was
"management"
> hotplugged
>
> Signed-off-by: Igor Mammedov
> ---
> hw/core/qdev.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/hw/core/qdev.c b/hw/core/q
From: "Dr. David Alan Gilbert"
QEMU will assert if you attempt to start an outgoing migration on
a QEMU that's sitting waiting for an incoming migration (started
with -incoming), so disallow it with a proper error.
(This is a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1086987 )
Signed-
Am 14.04.2014 18:03, schrieb Dr. David Alan Gilbert (git):
> From: "Dr. David Alan Gilbert"
>
> QEMU will assert if you attempt to start an outgoing migration on
> a QEMU that's sitting waiting for an incoming migration (started
> with -incoming), so disallow it with a proper error.
>
> (This is
On 04/14/2014 10:03 AM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> QEMU will assert if you attempt to start an outgoing migration on
> a QEMU that's sitting waiting for an incoming migration (started
> with -incoming), so disallow it with a proper error.
>
> (This i
On 04/10/2014 02:24 AM, Laszlo Ersek wrote:
> and rebase monitor_handle_fd_param() to it. (Note that this will slightly
> change the behavior when the qemu_parse_fd() branch is selected and it
> fails: we now report (and in case of QMP, set) the error immediately,
> rather than allowing the caller
lijun writes:
> Hi Markus,
> Really appreciate your review first. I almost a new participant. And
> I read other's patches very little. So maybe this patch is duplicate
> to one of Marcel's patch. But I really do not know. And I really don't
> copying Marcel's. This is my own analysis. When I m
Hi,
sorry for being late into the discussion.
Couldn't Intel Decimal Floating-Point Math Library be used?
It seems to be using a BSD license.
http://www.netlib.org/misc/intel/
Laurent
Am 14.04.2014 16:26, schrieb Peter Maydell:
> On 31 March 2014 08:08, Stefan Hajnoczi wrote:
>> Check incoming_posn to avoid out-of-bounds array accesses if the ivshmem
>> server on the host sends invalid values.
>>
>> Cc: Cam Macdonell
>> Reported-by: Sebastian Krahmer
>> Signed-off-by: Stefan
On Mon, 14 Apr 2014 18:02:32 +0200
Andreas Färber wrote:
> Am 04.04.2014 15:36, schrieb Igor Mammedov:
> > so that managment could detect via QOM interface if device was
>
> "management"
Thanks, I'll fix it.
>
> > hotplugged
> >
> > Signed-off-by: Igor Mammedov
> > ---
> > hw/core/qdev.c |
On Mon, 14 Apr 2014 15:25:01 +0800
Hu Tao wrote:
> On Fri, Apr 04, 2014 at 03:36:58PM +0200, Igor Mammedov wrote:
> > Needed for Windows to use hotplugged memory device, otherwise
> > it complains that server is not configured for memory hotplug.
> > Tests shows that aftewards it uses dynamically
Here's my current s390x patch queue, also available on
https://github.com/cohuck/qemu.git s390-next
- linux-headers update for registers, capabilites and irqfds
- capability work; the helper functions are now flexible enough to provide
an interface for adding arguments as well (will be used by
Base is 7cbb39d4d4d530dff12f2ff06ed6c85c504ba91a.
Gets several new interfaces:
Per-vm capability enablement, adapter interrupt sources, irq routing on s390.
Signed-off-by: Cornelia Huck
---
linux-headers/asm-s390/kvm.h | 24
linux-headers/linux/kvm.h| 17 +++
Make code using the same indicators point to a single allocated structure
that is freed when the last user goes away.
This will be used by the irqfd code to unmap addresses after the last user
is gone.
Reviewed-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
hw/s390x/virtio-ccw.c | 80 +
From: Christian Borntraeger
Some ONE_REGS on s390 are not protected by a capability. Older kernels
might not provide those and return an error. Fortunately these registers
are only critical for the migration path. There is no need to error out
on reset and normal runtime. Furthermore, these kerne
Provide helper functions for enabling capabilities (on a vcpu and on a vm).
Reviewed-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
include/sysemu/kvm.h |4
kvm-all.c| 33 -
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/i
Register an I/O adapter interrupt source for when virtio-ccw devices start
using adapter interrupts.
Reviewed-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
hw/intc/s390_flic.c | 59 +
hw/s390x/css.c| 51 +++
Make kvm_s390_enable_css_support() use new interface.
Signed-off-by: Cornelia Huck
---
target-s390x/kvm.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 56b9af7..fbdc1bb 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kv
Make use of the new s390 adapter irq routing support to enable real
in-kernel irqfds for virtio-ccw with adapter interrupts.
Note that s390 doesn't provide the common KVM_CAP_IRQCHIP capability, but
rather needs KVM_CAP_S390_IRQCHIP to be enabled. This is to ensure backward
compatibility.
Reviewe
Convert existing users of KVM_ENABLE_CAP to new helper.
Signed-off-by: Cornelia Huck
---
hw/intc/openpic_kvm.c |8 ++--
hw/intc/xics_kvm.c|8 ++--
target-ppc/kvm.c | 21 -
3 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/hw/intc/openp
From: Christian Borntraeger
We also need to sync guest breaking event address and program parameter
register for migration support.
Signed-off-by: Christian Borntraeger
Reviewed-by: Jason J. Herne
Reviewed-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
target-s390x/cpu.h |3 +++
targe
On 04/14/2014 04:32 AM, Claudio Fontana wrote:
> the problem is not in the two nibbles you show, but in the third nibble:
> 31 30 29 28 27 26 25 24 23 22 21 20
> size 1 1 1 v 0 0 opc 0 x
>
> the third nibble in your mask is 'E' and the expected result is 0, which
> forces opc to be
Current css code saves the operation request block (orb) in the
subchannel structure for later consumption by the start function
handler. This might make sense for asynchronous execution of the
start function (which qemu doesn't support), but not in our case;
it would even be wrong since orb contai
Hi Alex,
here's my conversion of the existing ppc KVM_ENABLE_CAP users to the
new helper functions, on top of my s390-next branch.
Unfortunately, I have no environment to test this (and I haven't been
able to setup a cross-build environment either).
Also available on
https://github.com/cohuck/q
Hi Alex,
Maik Broemme wrote:
> Hi Alex,
>
> Alex Williamson wrote:
> > On Fri, 2014-02-14 at 01:01 +0100, Maik Broemme wrote:
> > > Hi Alex,
> > >
> > > Maik Broemme wrote:
> > > > Hi Alex,
> > > >
> > > > Alex Williamson wrote:
> > > > > On Fri, 2014-02-07 at 01:22 +0100, Maik Broemme wrot
Hi team,
I am trying to understand the gdb breakpoint support in qemu. i could see
the arch_insert_sw_breakpoint adding a int3 opcode. But my question is,
when the break is hit, how it is propagated to gdb server. I mean which
routine or call is used from qemu to update the gdb server connected vi
Eric Blake writes:
> On 04/13/2014 01:07 PM, Lluís Vilanova wrote:
>> Signed-off-by: Lluís Vilanova
>> ---
>> Makefile | 24 ++--
>> tests/Makefile | 20
>> 2 files changed, 34 insertions(+), 10 deletions(-)
> Has this changed from v8?
> https://
Il 11/04/2014 05:14, Igor Mammedov ha scritto:
> > > How about simply looking for a hotplug handler type device instead?
> > > We aren't likely to have many of these, are we?
> >
> > How about adding link to PCMachine when it's created
> > and use it instead of piix4_pm_find()/ich9_lpc_find() e
Hi
Please, send any topic that you are interested in covering.
Thanks, Juan.
Call details:
15:00 CEST
13:00 UTC
09:00 EDT
Every two weeks
If you need phone number details, contact me privately.
On Mon, 14 Apr 2014 13:25:59 -0400
Paolo Bonzini wrote:
> Il 11/04/2014 05:14, Igor Mammedov ha scritto:
> > > > How about simply looking for a hotplug handler type device instead?
> > > > We aren't likely to have many of these, are we?
> >>> > >
> >>> > > How about adding link to PCMa
The following changes since commit 750036a848ea913ba6343718ffa70da98f7eef6b:
Merge remote-tracking branch 'remotes/afaerber/tags/prep-for-upstream' into
staging (2014-03-12 17:53:37 +)
are available in the git repository at:
git://github.com/otubo/qemu.git seccomp
for you to fetch chan
From: Paul Moore
Additional testing reveals that PulseAudio requires shmctl() and the
mlock()/munlock() syscalls on some systems/configurations. As before,
on systems that do require these syscalls, the problem can be seen with
the following command line:
# qemu -monitor stdio -sandbox on \
Am 13.04.2014 15:24, schrieb Jun Li:
> Add remove_boot_device_path() function to remove bootindex when hot-unplug
> a device. This patch fixed virtio-blk/virtio-net/scsi-disk/scsi-generic
> device.
> So it has fixed bug1086603, ref:
> https://bugzilla.redhat.com/show_bug.cgi?id=1086603
>
> Signed
From: Felix Geyer
libusb calls timerfd_create() and timerfd_settime() when it's built with
timerfd support.
Command to reproduce:
-device usb-host,hostbus=1,hostaddr=3,id=hostdev0
Log messages:
audit(1390730418.924:135): auid=4294967295 uid=121 gid=103 ses=4294967295
On 04/10/2014 02:24 AM, Laszlo Ersek wrote:
> Propagate any errors in monitor fd handling up to get_real_device(), and
> report them there. We'll continue the propagation upwards when
> get_real_device() becomes a leaf itself (when none of its callees will
> report errors internally any longer when
Check fw_cfg for the presence of a complete set of smbios
tables (etc/smbios/smbios-tables) and an entry point structure
(etc/smbios/smbios-anchor), and, if found, use them instead of
generating our own copies locally.
We ensure the presence of a type 0 (bios information) structure
by generating o
On 14 April 2014 21:06, New B wrote:
> Hi,
>
>
> Am I sending to the right forum/list?
>
> If not, I would appreciate if someone points me to the right one.
No; you want qemu-devel@nongnu.org (cc'd).
> I am new to qemu and have a few questions.
>
> Build Env Configuration:
> mac os x machine run
** Attachment added: "syslog excerpt related to VM starting / crash"
https://bugs.launchpad.net/qemu/+bug/1307656/+attachment/4083720/+files/qemu-syslog
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bu
Public bug reported:
libvirtd 1.2.3
virt-manager 1.0.1
qemu 1.7.92 (2.0.0-rc2)
1. Initially virt-manager is NOT running
2. I start a VM manually using "virsh start ...", causing a qemu
instance to be run as
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name Zeus_Virtualized -S
-machine pc-i44
No crash BTW if virt-manager is started first and THEN "virsh start..."
is executed.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1307656
Title:
qemu segfault when starting virt-manager
Status in
Judging by the backtrace this is the bug fixed by commit 92b3eeadd9bc,
which is in current git master and will be in the imminent 2.0.0-rc3.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1307656
Titl
On 04/14/14 20:47, Pieter Hollants wrote:
> Public bug reported:
>
> libvirtd 1.2.3
> virt-manager 1.0.1
> qemu 1.7.92 (2.0.0-rc2)
I think this should be fixed by Cole's patch, in rc3:
commit 92b3eeadd9bc72f1f4e5ba1f62a289dc0190e88f
Author: Cole Robinson
Date: Thu Apr 10 14:47:38 2014 -0400
Fix is already queued for qemu 2.0 GA
commit 92b3eeadd9bc72f1f4e5ba1f62a289dc0190e88f
Author: Cole Robinson
Date: Thu Apr 10 14:47:38 2014 -0400
qom: Fix crash with qom-list and link properties
** Changed in: qemu
Status: New => Incomplete
** Changed in: qemu
Status: Incom
Subsequent patches will utilize this function to set defaults for
more smbios types than just type 1, so the function name should
reflect this.
Signed-off-by: Gabriel Somlo
---
hw/i386/pc_piix.c| 12 ++--
hw/i386/pc_q35.c | 8
hw/i386/smbios.c | 4 ++--
The function smbios_set_defaults() uses a repeating code pattern
for each field. This patch replaces that pattern with a macro.
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/hw/i386/smbios.c b/hw/i386/smbio
This patch adds a set of macros which build full smbios tables
of a given type, including the logic to decide whether a given
table type should be built or not.
To illustrate this new functionality, we introduce and optionally
build a table of type 2 (base board), which is required by some
version
This patch removes smbios_add_field() and the old code to insert
individual fields for types 0 and 1 into fw_cfg.
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 80
1 file changed, 80 deletions(-)
diff --git a/hw/i386/smbios.c b/hw/i
Replace existing smbios_check_collision() functionality with
a pair of bitmaps: have_binfile_bitmap and have_fields_bitmap.
Bits corresponding to each smbios type are set by smbios_entry_add(),
which also uses the bitmaps to ensure that binary blobs and field
values are never accepted for the same
Build full smbios tables representing the system RAM:
- type 16 (physical memory array): represents the entire system RAM;
- type 17 (memory device) tables: one per virtual DIMM;
- type 19 (memory array mapped address): represent major RAM areas
(currently one for below-4G memory, and, if
New in version 6 of the patch set:
- down to 17 patches (squashed adding spec v2.4 fields
in together with adding v2.8 fields further down).
- switching to monolithic aggregate tables plus entry point
in patch 11/17, right after accomplishing full SeaBIOS
compatibility (in 10/17).
Build a complete set of smbios tables as a monolithic blob;
Also, build an entry point structure, and insert both the set
of tables and the entry point into distinct fw_cfg files.
This patch expects a SeaBIOS version equal or later than
commit X. An earlier
version will work, but without t
Build full tables for types 0 (bios information) and 1 (system
information). Type 0 is optional, and a table will only be built
if requested via the command line; the default is to leave type 0
tables up to the bios itself.
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 63 +
Build full smbios type 4 (processor information) tables, and make
them available to the bios via fw_cfg. For initial compatibility
with SeaBIOS, use "Bochs" as the default manufacturer string, and
leave version unset.
Signed-off-by: Gabriel Somlo
---
hw/i386/pc.c | 3 ++
hw/i386/smb
- Replace some arbitrarily hardcoded fields with proper
"n/a" or "unknown" values;
- Use QEMU-supplied default manufacturer and version strings;
- Count CPUs starting with 0 instead of 1, to maintain uniformity
with other multiple-instance items.
Signed-off-by: Gabriel Somlo
---
hw
Build full smbios type 32 (system boot info) and 127 (end-of-table)
tables, and make them available via fw_cfg.
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
index 6510ff3..b1f1d46 10
Build smbios type 3 (system enclosure) table, and make it available
to the bios via fw_cfg. For initial compatibility with SeaBIOS, use
"Bochs" as the default manufacturer string, and leave version unset.
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 67
Table type 20 (memory device mapped address) is no longer required
as of smbios spec v2.5. Leaving it out completely saves us from having
to figure out how to connect type 17 devices to type 19 memory areas.
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 99 +
With this update, we generate one type 4 (processor information) table
per socket, calculated as "smp_cpus / (smp_cores * smp_threads)", which
is in line with what happens on modern hardware.
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 22 +-
include/hw/i386/s
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 8 +++-
include/hw/i386/smbios.h | 3 ++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
index eb11095..25d2aa3 100644
--- a/hw/i386/smbios.c
+++ b/hw/i386/smbios.c
@@ -52,7 +52,7 @
Build type 19 (memory array mapped address, a.k.a. memory area)
tables by scanning the e820 map for E820_RAM entries. Since this
supercedes below_4g and above_4g ram amounts, we no longer need
them as arguments to smbios_set_defaults().
Signed-off-by: Gabriel Somlo
---
hw/i386/pc.c |
This patch adds extended start/end address and extended size fields
to each memory table type.
Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 52
include/hw/i386/smbios.h | 20 ---
2 files changed, 52 insertions(+), 20
On Mon, Apr 14, 2014 at 03:30:14PM -0400, Gabriel L. Somlo wrote:
> Check fw_cfg for the presence of a complete set of smbios
> tables (etc/smbios/smbios-tables) and an entry point structure
> (etc/smbios/smbios-anchor), and, if found, use them instead of
> generating our own copies locally.
>
> W
Dang, I was hoping some ground was being made on this.
On Wed, Apr 2, 2014 at 11:05 AM, Marcin Gibuła wrote:
>>> Yes, that's where it gets weird. I've never seen this on fresh VM.
>>> It needs to be idle for couple of hours at least. And even then it
>>> doesn't always hang.
>>
>>
>> So your OS i
On 04/14/2014 05:19 PM, Laszlo Ersek wrote:
On 04/14/14 04:27, Amos Kong wrote:
We already have a function buffer_is_zero() in util/cutils.c
Signed-off-by: Amos Kong
---
arch_init.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index
May any member help to check them?
And next, I shall try to find bug issues (not code style or document
issues), and fix them. Hope I can succeed.
Thanks.
On 04/08/2014 08:00 PM, Chen Gang wrote:
> In "vl.c", at least, we can simplify the code below, so can let readers
> read professional C cod
Hi,
I am a user of qemu. I found that in qemu2.0.0-rc0 the gic model was
updated. However, it seems loss ability to bind irqs to any specified core when
the board includes multiple cortex-a9 cores. The problematic codes maybe locate
at hw/intc/arm_gic.c:
50 void gic_update(GICState *s)
On Tue, Apr 8, 2014 at 10:01 PM, Chen Gang wrote:
> Normal "if (...) {...} else {...}" is enough in "while(...) {...}", not
> need additional useless 'continue'.
>
Only in the case where the if-else is not followed by any code. Which
is the case here. I found this sentance slightly confusing and
On Tue, Apr 8, 2014 at 10:02 PM, Chen Gang wrote:
> In function, if no additional resources to free before quit, commonly,
> need not use additional local variable 'res' to notice about it. So
> remove it to simplify code.
>
Styling wise, there is a school of thought that functions should only
ha
This series adds support for a sysbus device for RAMs. Patch 2 is the
main event. See commit message for full discussion.
This is primarily prompted by the recent discussions around data driven
machine creation.
P1 is a nicety more than anything to preserve custom naming of devices
(which oddly h
Add a sysbus device consisting of a single ram. This allows for
instantiation of RAM just like any other device. There are a number
of good reasons to want to do this this:
1: Consistency. RAM is not that special where board level files should
have to instantiate it with a completely different API
So clients can set the top level id string.
Signed-off-by: Peter Crosthwaite
---
hw/core/qdev.c | 13 +++--
include/hw/qdev-core.h | 2 +-
qdev-monitor.c | 3 ++-
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 60f9
For consistency with other devices and completeness of system device
tree.
Signed-off-by: Peter Crosthwaite
---
hw/arm/xilinx_zynq.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c
index 9ee21e7..7a0c951 100644
On Mon, Apr 14, 2014 at 7:56 AM, Beniamino Galvani wrote:
> On Wed, Apr 09, 2014 at 11:42:31PM -0700, Peter Crosthwaite wrote:
>> Add support for 16, 32 and 64 bit width FIFOs. The push and pop
>> functions are replicated to accept all four different integer types.
>> The element width of the FIFO
bdrv_getlength could fail, check the return value before using it.
Signed-off-by: Fam Zheng
---
v2: Make use of error_setg_errno and -errno. (Kevin)
Signed-off-by: Fam Zheng
---
block-migration.c | 28
block.c | 10 --
block/mirror.c
Hi, there:
I found an issue that cdrom device hotplug iso image.
1. if I startup qemu with an iso image, then iso can easily be replaced and it
worked.
2. but if I startup qemu with null image, when I change iso image use qemu
monitor command "change",
it told me with following message:
'
There is a utility helper for dealing with 8 bit fifos. This should be
applicable to other integer widths as well. These two patches
generalise this FIFO to work for 16, 32 and 64 bit ints.
changed since v3:
Initialised buffer_size (P2) (Beniamino review)
changed since v2:
Glueified hot paths to
Add support for 16, 32 and 64 bit width FIFOs. The push and pop
functions are replicated to accept all four different integer types.
The element width of the FIFO is set at creation time.
The backing storage for all element types is still uint8_t regardless of
element width so some save-load logic
101 - 200 of 217 matches
Mail list logo
