On 08/07/2015 10:46 AM, Yang Hongyang wrote:
> add netfilter_{add|del} commands
> This is mostly the same with netdev_{add|del} commands.
>
> When we delete the netdev, we also delete the netfilter object
> attached to it, because if the netdev is removed, the filters
> which attached to it is use
On 08/07/2015 10:46 AM, Yang Hongyang wrote:
> Using qtest qmp interface to implement following cases:
> 1) add/remove netfilter
> 2) add a netfilter then delete the netdev
> 3) add/remove more than one netfilters
> 4) add more than one netfilters and then delete the netdev
>
> Signed-off-by: Yang
Hello!
> The need to add num_irq to this prototype reveals the ugliness
> of it as an interface.
> I don't think we gain much by making these two functions common,
> and we do get a lot of churn in the existing code below.
You know, i was also thinking about it. And actually there is a way to
If quorum's child is broken, we can use mirror job to replace it.
But sometimes, the user only need to remove the broken child, and
add it later when the problem is fixed.
ChangLog:
v2:
1. Use bdrv_get_device_or_node_name() instead of new function
bdrv_get_id_or_node_name()
2. Update the error
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
blockdev.c | 79
qapi/block-core.json | 40 ++
qmp-commands.hx | 67
3 fil
In some cases, we want to take a quorum child offline, and take
another child online.
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Reviewed-by: Alberto Garcia
---
block.c | 43 +++
include/block/block
It will be used by BlockdevOptionsNBD.
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Reviewed-by: Alberto Garcia
---
qapi-schema.json | 27 ---
qapi/common.json | 27 +++
2 files changed, 27 insertions(+), 27 de
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Cc: Luiz Capitulino
---
blockdev.c| 33 +
hmp-commands.hx | 28
include/sysemu/blockdev.h | 2 ++
3 files changed, 63 insertio
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Reviewed-by: Alberto Garcia
---
qapi/block-core.json | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 7b2efb8..3ed8114 100644
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Reviewed-by: Alberto Garcia
---
block/quorum.c | 75 --
1 file changed, 73 insertions(+), 2 deletions(-)
diff --git a/block/quorum.c b/block/quorum.c
index 2
> > +#define GICV3_NCPU 64
>
> What is imposing this NCPU limit?
Currently qemu does not support Aff2 field. Can we have more than 64 CPUs only
with Aff0 and Aff1?
Well, if you really-really insist, i can just raise it to 128 and stop it
finally. It's actually Shlomo's heritage, and i believe
Benjamin Herrenschmidt writes:
> On Mon, 2015-08-10 at 17:26 +0200, fred.kon...@greensocs.com wrote:
>> From: KONRAD Frederic
>>
>> This is the 7th round of the MTTCG patch series.
>>
>>
>> It can be cloned from:
>> g...@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v7.
>>
>> This pa
On 10/08/2015 20:39, Alex Bennée wrote:
> > ... ah, the lock is recursive!
> >
> > I think this can be avoided. Let's look at it next week.
>
> I take it your around on the Tuesday (Fred and I arrive Monday evening).
> Shall we pick a time or hunt for each other in the hacking room?
Yes, I wil
On 11/08/2015 08:46, Frederic Konrad wrote:
>> I think you should start easy and reuse the existing tb_lock code in
>> cpu-exec.c:
>
> I think it's definitely not sufficient. Is user-mode multithread still
> working today?
For some definition of "working", yes. It's not sufficient, but it's a
On 27.07.15 10:19, Laurent Vivier wrote:
> Alex,
>
> could you ACK this patch ?
>
> It's not perfect and it will be removed later, but for the moment it
> allows to hotplug PCI card in pseries.
PCIe definitely allows for BARs to be allocated to 0, so this is more or
less "the right thing". I r
On 11/08/2015 10:50, Alexander Graf wrote:
>
>
> On 27.07.15 10:19, Laurent Vivier wrote:
>> Alex,
>>
>> could you ACK this patch ?
>>
>> It's not perfect and it will be removed later, but for the moment it
>> allows to hotplug PCI card in pseries.
>
> PCIe definitely allows for BARs to be all
Please, note that this series also require the "[PATCH v2 for-2.4] i.MX: Fix
UART driver to work with unitialized "chardev" device".
http://lists.nongnu.org/archive/html/qemu-stable/2015-07/msg00140.html
Without it, Qemu will crash when accessing the 5th serial device on imx25_pdk
platform.
On 10 August 2015 at 08:13, Gavin Shan wrote:
> The header file was introduced by following Linux upstream commits:
>
> commit ed3e81f ("powerpc/eeh: Move PE state constants around")
> commit ec33d36 ("powerpc/eeh: Introduce eeh_pe_inject_err()")
>
> Signed-off-by: Gavin Shan
> ---
> lin
On 11 August 2015 at 08:53, Pavel Fedin wrote:
>> > +#define GICV3_NCPU 64
>>
>> What is imposing this NCPU limit?
>
> Currently qemu does not support Aff2 field. Can we have more
> than 64 CPUs only with Aff0 and Aff1?
The GIC code itself doesn't care, so it shouldn't be imposing
its own limit,
On 11 August 2015 at 09:34, Paolo Bonzini wrote:
>
>
> On 11/08/2015 08:46, Frederic Konrad wrote:
>>> I think you should start easy and reuse the existing tb_lock code in
>>> cpu-exec.c:
>>
>> I think it's definitely not sufficient. Is user-mode multithread still
>> working today?
>
> For some de
On Tue, 2015-08-11 at 08:54 +0100, Alex Bennée wrote:
>
> > How do you handle the memory model ? IE , ARM and PPC are OO while x86
> > is (mostly) in order, so emulating ARM/PPC on x86 is fine but emulating
> > x86 on ARM or PPC will lead to problems unless you generate memory
> > barriers with ev
On 11 August 2015 at 10:22, Benjamin Herrenschmidt
wrote:
> On Tue, 2015-08-11 at 08:54 +0100, Alex Bennée wrote:
>>
>> > How do you handle the memory model ? IE , ARM and PPC are OO while x86
>> > is (mostly) in order, so emulating ARM/PPC on x86 is fine but emulating
>> > x86 on ARM or PPC will
Hello!
> No it won't, because "don't impose an arbitrary 64 bit limit"
> was one of my review comments on the emulation code; that
> will need to be fixed before the emulation code can be accepted.
Sorry for may be being ignorant, i really had no time to read GICv3 arch
manual from beginning t
This problem is fixed with commit 3e5feb62 ("qcow2: Handle EAGAIN
returned from update_refcount"), which will be included in qemu 2.4.0.
** Changed in: qemu
Status: Incomplete => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subsc
This is a different case. The original report used "qemu-img create" in
step 2, which results in a sparse image that refers to the backing file
for all data. Your sequence has "qemu-img convert" instead, which fully
populates disk.qcow. Therefore, in step 3, "qemu-img convert" leaves the
full alloc
On 11/08/2015 11:21, Peter Maydell wrote:
> > > I think it's definitely not sufficient. Is user-mode multithread still
> > > working today?
> >
> > For some definition of "working", yes. It's not sufficient, but it's a
> > good start.
> >
> > The main problem with user-mode multithreading is tha
On Thu, May 14, 2015 at 07:31:16PM +0200, Andrea Arcangeli wrote:
> This activates the userfaultfd syscall.
>
> Signed-off-by: Andrea Arcangeli
> ---
> arch/powerpc/include/asm/systbl.h | 1 +
> arch/powerpc/include/uapi/asm/unistd.h | 1 +
> arch/x86/syscalls/syscall_32.tbl | 1 +
>
On Tue, 2015-08-11 at 10:29 +0100, Peter Maydell wrote:
> Is it possible in some of these combinations to use the load-acquire
> and store-release instructions rather than explicit barriers?
> (ARMv8 has those, which I think should be slightly less heavyweight
> than explicit barriers everywhere, i
On 11 August 2015 at 10:35, Pavel Fedin wrote:
> Hello!
>
>> No it won't, because "don't impose an arbitrary 64 bit limit"
>> was one of my review comments on the emulation code; that
>> will need to be fixed before the emulation code can be accepted.
>
> Sorry for may be being ignorant, i reall
My mistake. It's different case than mine. Above sequence (original
report) works fine.
But I do not really understand why the same is not achieved in my case.
I use the convert instead of the create to get a full image in qcow
format. From that point, the desired behaviour is to create a qcow tha
Hello!
> In any case, if you want
> to impose a compile-time limit in the QEMU code then you need
> to point out the part of the GIC spec that imposes that limit.
Ok, i agreed and gave up. Will do in v9. :)
By the way, how to migrate such a thing? Is migration of variable-length state
structu
On 11 August 2015 at 11:39, Pavel Fedin wrote:
> By the way, how to migrate such a thing? Is migration of
> variable-length state structures supported?
Yes; this is what the _VARRAY_ vmstate macros are for.
-- PMM
On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
> @@ -583,5 +587,6 @@ int cpu_exec(CPUState *cpu)
>
> /* fail safe : never use current_cpu outside cpu_exec() */
> current_cpu = NULL;
> +tcg_cpu_allow_execution(cpu);
I don't think this is correct; safe_work_pending() is a mu
On 31 July 2015 at 12:34, Jean-Christophe Dubois wrote:
> The "chardev" property initialization might have failed (for example because
> there are not enough chardevs provided by QEMU).
>
> The serial device emulator need to be able to work with an uninitialized
> (NULL) chardev device pointer.
>
On 11/08/2015 12:53, Paolo Bonzini wrote:
On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
@@ -583,5 +587,6 @@ int cpu_exec(CPUState *cpu)
/* fail safe : never use current_cpu outside cpu_exec() */
current_cpu = NULL;
+tcg_cpu_allow_execution(cpu);
I don't think this i
On 10/08/2015 17:26, fred.kon...@greensocs.com wrote:
> From: KONRAD Frederic
>
> This is the 7th round of the MTTCG patch series.
Here is a list of issues that I found:
- tb_lock usage in tb_find_fast is complicated and introduces the need
for other complicated code such as the tb_invalidate c
> > When debugging (via gdbstub), I would like to get the current process
> > id by a virtual address. When the virtual address is in the
> > user-space, the only way to find the current task_struct I can think
> > of is to iterate over all the task_struct's (assuming we know
> > task_init and the
On 11/08/2015 13:11, Frederic Konrad wrote:
> On 11/08/2015 12:53, Paolo Bonzini wrote:
>>
>> On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
>>> @@ -583,5 +587,6 @@ int cpu_exec(CPUState *cpu)
>>> /* fail safe : never use current_cpu outside cpu_exec() */
>>> current_cpu = NU
On 11 August 2015 at 13:53, Igor R wrote:
> Reading ttbr0 worked for me on ARM, reading cr3 worked on x86.
> Now I'm looking for a similar thing on MIPS. I.e. I need a pointer to the
> process' translation table - something that can be compared to task->mm->pgd
> (after virt2phys conversion).
> I'
Oh, it seems a little complex, for a testsuite case, it lets double add
and double mul together! We need save more information for the correct
calculation in pack1.
It is 20020314-1.exe, the related code (I guess it is correct):
...
fdouble_unpack_max r10, r3, zero
.LVL2:
On Fri, Aug 7, 2015 at 7:03 PM, Alvise Rigo
wrote:
> The new helpers rely on the legacy ones to perform the actual read/write.
>
> The LoadLink helper (helper_ldlink_name) prepares the way for the
> following SC operation. It sets the linked address and the size of the
> access.
> These helper als
Hello Bharata,
On Tue, Aug 11, 2015 at 03:37:29PM +0530, Bharata B Rao wrote:
> May be it is a bit late to bring this up, but I needed the following fix
> to userfault21 branch of your git tree to compile on powerpc.
Not late, just in time. I increased the number of syscalls in earlier
versions,
Hi All,
I am using linux 4.0 kernel on host side and 3.19 on guest side.
I have enabled the iommu and nested virtualization on host.
The DMAR is visible in the host side and when I start a VM using qemu-kvm,
the same DMAR not visible on the guest side. But it says IOMMU is enabled
when I look at
On 07/08/2015 19:03, Alvise Rigo wrote:
> +static inline int cpu_physical_memory_excl_atleast_one_clean(ram_addr_t addr)
> +{
> +unsigned long *bitmap = ram_list.dirty_memory[DIRTY_MEMORY_EXCLUSIVE];
> +unsigned long next, end;
> +
> +if (likely(smp_cpus <= BITS_PER_LONG)) {
This onl
On 11/08/2015 15:32, alvise rigo wrote:
>> > +#if DATA_SIZE > 1
>> > +#define helper_ldlink_name glue(glue(helper_le_ldlink, USUFFIX),
>> > MMUSUFFIX)
>> > +#define helper_stcond_name glue(glue(helper_le_stcond, SUFFIX),
>> > MMUSUFFIX)
>> > +#define helper_ld_legacy glue(glue(helper_le_ld, U
On 11/08/2015 14:45, Paolo Bonzini wrote:
On 10/08/2015 17:26, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This is the 7th round of the MTTCG patch series.
Thanks to look at this.
Here is a list of issues that I found:
- tb_lock usage in tb_find_fast is complicated and introduces
On 11/08/2015 15:59, Frederic Konrad wrote:
>> - tb_lock usage in tb_find_fast is complicated and introduces the need
>> for other complicated code such as the tb_invalidate callback. Instead,
>> the tb locking should reuse the cpu-exec.c code for user-mode emulation,
>> with additional locking
Convert the pxa2xx_mmci device to be a sysbus device.
Signed-off-by: Peter Maydell
---
hw/sd/pxa2xx_mmci.c | 96 +++--
1 file changed, 79 insertions(+), 17 deletions(-)
diff --git a/hw/sd/pxa2xx_mmci.c b/hw/sd/pxa2xx_mmci.c
index d1fe6d5..5b676c7
This patchset updates the ancient pxa2xx_mmci device to something
resembling modern standards for devices. In particular it makes
it a proper sysbus device and switches to VMStateDescription structs.
The major issue I have with this is in patch 1:
I wanted the device to have a property so its user
Add a reset function to the pxa2xx_mmci device; previously it had
no handling for system reset at all.
Signed-off-by: Peter Maydell
---
hw/sd/pxa2xx_mmci.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/hw/sd/pxa2xx_mmci.c b/hw/sd/pxa2xx_mmci.c
index ea42434.
Convert the pxa2xx_mmci device from manual save/load
functions to a VMStateDescription structure.
This is a migration compatibility break.
Signed-off-by: Peter Maydell
---
hw/sd/pxa2xx_mmci.c | 149
1 file changed, 57 insertions(+), 92 deleti
On 11 August 2015 at 14:52, Paolo Bonzini wrote:
>
> I don't think real hardware has ll/sc per CPU.
On ARM, the exclusives are handled by the 'global monitor', which
supports tracking an exclusive access per CPU.
> Can we have the bitmap as:
>
> - 0 if one or more CPUs have the address set to e
This small patch series is a formal submission of another part
of my previous RFC series
https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg02038.html
Now we have the basic crypto module defined for hash/cipher APIs,
we extend it to also cover TLS credential and TLS session handling
APIs.
Various VNC server I/O functions return 'long' and then
also pass this to a method accepting 'int'. All these
should be ssize_t to match the signature of read/write
APIs and thus avoid potential for integer truncation /
wraparound.
Signed-off-by: Daniel P. Berrange
---
ui/vnc.c | 36
Introduce a QCryptoTLSSession object that will encapsulate
all the code for setting up and using a client/sever TLS
session. This isolates the code which depends on the gnutls
library, avoiding #ifdefs in the rest of the codebase, as
well as facilitating any possible future port to other TLS
librar
Introduce a QCryptoTLSCreds class to store TLS credentials, for use
by later TLS session code. The class is a user creatable object, so
instances can be created/deleted via 'object-add' and 'object-del'
QMP commands respectively, or via the -object command line arg.
If the credentials cannot be in
Switch VNC server over to using the QCryptoTLSSession object
for the TLS session. This removes the direct use of gnutls
from the VNC server code. It also removes most knowledge
about TLS certificate handling from the VNC server code.
This has the nice effect that all the CONFIG_VNC_TLS
conditionals
If the administrator incorrectly sets up their x509 certificates,
the errors seen at runtime during connection attempts are very
obscure and difficult to diagnose. This has been a particular
problem for people using openssl to generate their certificates
instead of the gnutls certtool, because the
On Tue, Aug 11, 2015 at 4:24 PM, Peter Maydell wrote:
> On 11 August 2015 at 14:52, Paolo Bonzini wrote:
>>
>> I don't think real hardware has ll/sc per CPU.
>
> On ARM, the exclusives are handled by the 'global monitor', which
> supports tracking an exclusive access per CPU.
>
>> Can we have th
This allows one to see the size of blocks that get translated (in
target instructions) without the verbosity that in_asm would bring.
This is a step towards generating Basic Block Vectors (BBVs)* which
are histograms of blocks within a given interval. BBVs are useful in
determining whether one inte
Hi,
Please find in this series two small patches adding debugging
facilities related to instruction counting. My ultimate goal is to
provide accurate instruction counts to target software through
the Performance Monitors Unit (PMU) and enable the collection of
Basic Block Vectors (BBVs). These pat
When -icount shift=n is in use, print the instruction count when
finished. In conjunction with the `time` command, this can be used to
calculate how many instructions per second QEMU TCG can translate and
execute. The output can also be used to double-check future facilities
such as exposing the in
On 5 August 2015 at 17:51, Christopher Covington wrote:
> This series is a jumble of changes that I have found useful for
> creating samples of long-running applications. I do not expect any of
> these patches to be merged upstream as-is but I'm publishing them as a
> way to ask for high-level fee
** Also affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1448985
Title:
Ubuntu 14.04 LTS, 14.10, 15.04, 15.10 guests do not boot to Unity from
On Tue, Aug 11, 2015 at 3:52 PM, Paolo Bonzini wrote:
>
>
> On 07/08/2015 19:03, Alvise Rigo wrote:
>> +static inline int cpu_physical_memory_excl_atleast_one_clean(ram_addr_t
>> addr)
>> +{
>> +unsigned long *bitmap = ram_list.dirty_memory[DIRTY_MEMORY_EXCLUSIVE];
>> +unsigned long next,
On 11/08/2015 17:54, alvise rigo wrote:
> This can lead to an excessive rate of flush requests, since for one
> CPU that removes the TLB_EXCL flag, all the others that are competing
> for the same excl address will need to flush the entire cache and
> start all over again.
Why flush the entire c
On Tue, Aug 11, 2015 at 3:52 PM, Paolo Bonzini wrote:
>
>
> On 11/08/2015 15:32, alvise rigo wrote:
>>> > +#if DATA_SIZE > 1
>>> > +#define helper_ldlink_name glue(glue(helper_le_ldlink, USUFFIX),
>>> > MMUSUFFIX)
>>> > +#define helper_stcond_name glue(glue(helper_le_stcond, SUFFIX),
>>> > MMU
On Tue, Aug 11, 2015 at 5:55 PM, Paolo Bonzini wrote:
>
>
> On 11/08/2015 17:54, alvise rigo wrote:
>> This can lead to an excessive rate of flush requests, since for one
>> CPU that removes the TLB_EXCL flag, all the others that are competing
>> for the same excl address will need to flush the en
On 11/08/2015 18:11, alvise rigo wrote:
>> > Why flush the entire cache (I understand you mean TLB)?
> Sorry, I meant the TLB.
> If for each removal of an exclusive entry we set also the bit to 1, we
> force the following LL to make a tlb_flush() on every vCPU.
What if you only flush one entry w
On 11/08/2015 16:26, Daniel P. Berrange wrote:
> -object tls-creds,id=tls0,credtype=anon,endpoint=server \
> -vnc hostname:0,tls-creds=tls0
>
> Old syntax for x509 credentials, no client certs:
>
> -vnc hostname:0,tls,x509=/path/to/certs
>
> New syntax:
>
> -object
> tls-creds,id=tls
From: Marc-André Lureau
QAPI_EVENT_VSERPORT_CHANGE reports changes of a virtio serial port
state. However, the events may be for different ports, but the throttle
mechanism may replace the event for a different port, since it only
checks the event type.
libvirt relies on a correct state to be re
On Tue, Aug 11, 2015 at 07:04:07PM +0200, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> QAPI_EVENT_VSERPORT_CHANGE reports changes of a virtio serial port
> state. However, the events may be for different ports, but the throttle
> mechanism may replace the event for a different
On Tue, Aug 11, 2015 at 06:44:34PM +0200, Paolo Bonzini wrote:
>
>
> On 11/08/2015 16:26, Daniel P. Berrange wrote:
> > -object tls-creds,id=tls0,credtype=anon,endpoint=server \
> > -vnc hostname:0,tls-creds=tls0
> >
> > Old syntax for x509 credentials, no client certs:
> >
> > -vnc hostn
On 5 August 2015 at 17:51, Christopher Covington wrote:
> This is for full-system only; not implemented in user mode
>
> Written by Derek Hower.
> -cpu_memory_rw_debug(cs, env->regs[13]-64+32, (uint8_t *)&size, 4, 0);
> -env->regs[0] = be32_to_cpu(size);
> +if (env->aarch64) {
> +
On 08/11/15 19:04, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> QAPI_EVENT_VSERPORT_CHANGE reports changes of a virtio serial port
> state. However, the events may be for different ports, but the throttle
> mechanism may replace the event for a different port, since it only
>
From: "Gabriel Somlo"
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 0554077..8f07202 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -847,6 +847,7 @@ struct kobject *kset_find_obj(struct kset *kset, const
From: "Gabriel Somlo"
This patch set makes QEMU fw_cfg blobs available for viewing (read-only)
via SysFS.
New since v1:
1/3:
- renamed sysfs path components:
s/fw_cfg/qemu_fw_cfg/g, at Greg's suggestion
s/by_select/by_key/g since it
From: "Gabriel Somlo"
Make fw_cfg entries of type "file" available via sysfs. Entries
are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders
named after each entry's selector key. Filename, selector value,
and size read-only attributes are included for each entry. Also,
a "raw" attribute a
From: "Gabriel Somlo"
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp")
Benjamin Herrenschmidt writes:
> On Tue, 2015-08-11 at 08:54 +0100, Alex Bennée wrote:
>>
>> > How do you handle the memory model ? IE , ARM and PPC are OO while x86
>> > is (mostly) in order, so emulating ARM/PPC on x86 is fine but emulating
>> > x86 on ARM or PPC will lead to problems unless
Paolo Bonzini writes:
> On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
>> void qemu_mutex_lock_iothread(void)
>> {
>> -atomic_inc(&iothread_requesting_mutex);
>> -/* In the simple case there is no need to bump the VCPU thread out of
>> - * TCG code execution.
>> - */
>>
Hi everyone,
I am pleased to announce that the QEMU v2.3.1 stable release is now
available at:
http://wiki.qemu.org/download/qemu-2.3.1.tar.bz2
v2.3.1 is now tagged in the official qemu.git repository,
and the stable-2.3 branch has been updated accordingly:
http://git.qemu.org/?p=qemu.git;a
On behalf of the QEMU Team, I'd like to announce the availability of
the QEMU 2.4.0 release. This release contains 1900+ commits from 182
authors.
http://wiki.qemu.org/download/qemu-2.4.0.tar.bz2
The full list of changes are available at:
http://wiki.qemu.org/ChangeLog/2.4
Highlights includ
On 11/08/2015 22:12, Alex Bennée wrote:
Paolo Bonzini writes:
On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
void qemu_mutex_lock_iothread(void)
{
-atomic_inc(&iothread_requesting_mutex);
-/* In the simple case there is no need to bump the VCPU thread out of
- * TCG cod
On 11 August 2015 at 22:17, Michael Roth wrote:
> On behalf of the QEMU Team, I'd like to announce the availability of
> the QEMU 2.4.0 release. This release contains 1900+ commits from 182
> authors.
>
> http://wiki.qemu.org/download/qemu-2.4.0.tar.bz2
Thanks!
I've reopened the trunk for gene
On 08/09/2015 01:13 PM, Laurent Vivier wrote:
> INSN(undef, , , CF_ISA_A);
> +INSN(undef, , , M68000);
> INSN(arith_im, 0080, fff8, CF_ISA_A);
> +INSN(arith_im, , ff00, M68000);
> +INSN(undef, 00c0, ffc0, M68000);
> INSN(bitrev,00c0,
On 08/11/2015 07:11 PM, Peter Maydell wrote:
On 10 August 2015 at 08:13, Gavin Shan wrote:
The header file was introduced by following Linux upstream commits:
commit ed3e81f ("powerpc/eeh: Move PE state constants around")
commit ec33d36 ("powerpc/eeh: Introduce eeh_pe_inject_err()")
SMBIOS tables present userful system hardware info to management
applications, such as DMI tools. Even though SMBIOS was originally
developed for Intel x86, it has been extended to both Itanium and
ARM (32bit & 64bit). More and more ARM server releases, such as
RHEL Server for ARM, start to integ
Current smbios builds type 19 table from e820, which is x86 specific.
This patch removes smbios' dependency on e820 by passing an array
of memory area to smbios_get_tables().
Acked-by: Gabriel Somlo
Tested-by: Gabriel Somlo
Reviewed-by: Laszlo Ersek
Tested-by: Leif Lindholm
Signed-off-by: Wei
This patch adds support for SMBIOS 3.0 entry point. When caller invokes
smbios_set_defaults(), it can specify entry point as 2.1 or 3.0. Then
smbios_get_tables() will return the entry point table in right format.
Acked-by: Gabriel Somlo
Tested-by: Gabriel Somlo
Tested-by: Leif Lindholm
Signed-o
This patch generates smbios tables for ARM mach-virt. Also add
CONFIG_SMBIOS=y for ARM default config.
Acked-by: Gabriel Somlo
Tested-by: Gabriel Somlo
Reviewed-by: Laszlo Ersek
Reviewed-by: Shannon Zhao
Tested-by: Leif Lindholm
Signed-off-by: Wei Huang
---
default-configs/arm-softmmu.mak |
This patch extracts out the procedure of buidling x86 SMBIOS tables
into a dedicated function.
Acked-by: Gabriel Somlo
Tested-by: Gabriel Somlo
Reviewed-by: Laszlo Ersek
Tested-by: Leif Lindholm
Signed-off-by: Wei Huang
---
hw/i386/pc.c | 38 ++
1 file cha
To share smbios among different architectures, this patch moves SMBIOS
code (smbios.c and smbios.h) from x86 specific folders into new
hw/smbios directories. As a result, CONFIG_SMBIOS=y is defined in
x86 default config files.
Acked-by: Gabriel Somlo
Tested-by: Gabriel Somlo
Reviewed-by: Laszlo
On 08/11/2015 09:08 PM, Wei Huang wrote:
> SMBIOS tables present userful system hardware info to management
> applications, such as DMI tools. Even though SMBIOS was originally
> developed for Intel x86, it has been extended to both Itanium and
> ARM (32bit & 64bit). More and more ARM server rel
On Tue, Aug 11, 2015 at 10:11:03AM +0100, Peter Maydell wrote:
> On 10 August 2015 at 08:13, Gavin Shan wrote:
> > The header file was introduced by following Linux upstream commits:
> >
> > commit ed3e81f ("powerpc/eeh: Move PE state constants around")
> > commit ec33d36 ("powerpc/eeh: In
On Mon, Aug 03, 2015 at 11:05:38AM +0530, Bharata B Rao wrote:
> This patchset includes some updates to sPAPR memory hotplug code that
> currently resides in spapr-next branch of David Gibson's tree.
>
> The main change here is to use drc-count hotplug identifier type for memory
> hotplug. Current
On Thu, Aug 06, 2015 at 03:25:57PM +1000, Alexey Kardashevskiy wrote:
> At the moment get_monitor_def() prints only registers from monitor_defs.
> However there is a lot of BOOK3S SPRs which are not in the list and
> cannot be printed.
>
> This makes use of the new get_monitor_def() callback and p
On Thu, Aug 06, 2015 at 03:25:56PM +1000, Alexey Kardashevskiy wrote:
> At the moment the monitor only prints registers from monitor_defs.
> Some may not be supported but it will print those anyway, other
> may be missing in the list so monitor_defs needs an update every time
> new register is adde
On Thu, Aug 06, 2015 at 01:37:24PM +1000, Alexey Kardashevskiy wrote:
> sPAPR uses hard coded limit of maximum 255 supported CPUs which is
> exactly the same as QEMU-wide limit which is MAX_CPUMASK_BITS and also
> defined as 255.
>
> This makes use of a global CPU number limit for the "pseries" ma
On Thu, Aug 06, 2015 at 10:57:06AM +0530, Bharata B Rao wrote:
> Hi,
>
> This is the next version of CPU hotplug support patchset for PowerPC
> sPAPR guests. This is a split-out from the previous version (v3) that
> was carrying CPU and memory hotplug together. This patchset applies on
> spapr-nex
1 - 100 of 119 matches
Mail list logo
