On Tue, Aug 27, 2013 at 05:48:36PM +0100, Yongbok Kim wrote:
> From: James Hogan
>
> In get_physical_address() is a qemu_log() call inside an #if 0 block.
> When enabled the following build error is hit:
>
> target-mips/helper.c In function ‘get_physical_address’:
> target-mips/helper.c:220:13:
On Thu, Aug 22, 2013 at 09:58:33AM -0700, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> tcg/aarch64/tcg-target.h | 3 +--
> tcg/arm/tcg-target.h | 9 -
> tcg/hppa/tcg-target.h| 3 +--
> tcg/i386/tcg-target.h| 3 +--
> tcg/ia64/tcg-target.h| 3 +--
On Thu, Aug 22, 2013 at 09:58:34AM -0700, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> cpu-exec.c | 2 +-
> tcg/ppc/tcg-target.h | 2 +-
> tcg/tcg.h| 3 +--
> tcg/tci/tcg-target.h | 2 +-
> tci.c| 4 ++--
> 5 files changed, 6 insertions
On 28 August 2013 21:42, Edgar E. Iglesias wrote:
> I like what you propose aswell. A question, some archs have an endian swap
> controlled via the MMU, e.g per page selectable
It seems to be a rule that no matter how weird a concept in CPU architecture,
some CPU designer will have implemented a
On Thu, Aug 22, 2013 at 09:58:35AM -0700, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> cpu-exec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 14af2ed..5a43995 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -20
On 08/28/2013 01:42 PM, Edgar E. Iglesias wrote:
> A question, some archs have an endian swap
> controlled via the MMU, e.g per page selectable (some PPC, microblaze and
> maybe others). AFAIK the behaviour is implementable in QEMU today but not
> very efficiently. Any thoughts/ideas on this?
The
On Wed, Aug 28, 2013 at 4:02 PM, H. Peter Anvin wrote:
> On 08/28/2013 10:35 AM, Anthony Liguori wrote:
>> Yes, it was originally designed with the 16TB limit in mind.
>>
>> PCI doesn't support 64-bit PIO operations so it would have required a
>> high/low register and additional magic.
>>
>
> s/PC
On 08/28/2013 02:28 PM, Anthony Liguori wrote:
> Ack. Although I wonder if there is a device out there that actually
> expects 64-bit writes to a register in an PIO region...
If IBM makes any custom hardware that sits off a PCI bus, that's where I'd
expect to find such these days. I know DEC had
On 08/28/2013 10:35 AM, Anthony Liguori wrote:
> Yes, it was originally designed with the 16TB limit in mind.
>
> PCI doesn't support 64-bit PIO operations so it would have required a
> high/low register and additional magic.
>
s/PCI/x86/
"Additional magic" is needed only if atomic changes are
This is based on the "Further tcg ldst improvements" patch set.
The first patch is unchanged from the original "tcg ldst" patch set.
The second patch is modified to avoid defining local helpers in
the tcg/arm backend. This is trivial now that we can use the real
return address, so the extra para
Reviewed-by: Aurelien Jarno
Signed-off-by: Richard Henderson
---
tcg/arm/tcg-target.c | 48 +++-
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 6d084b3..9176930 100644
--- a/tcg/arm/tcg-
Signed-off-by: Richard Henderson
---
tcg/arm/tcg-target.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 5f71f24..a0a7539 100644
--- a/tcg/arm/tcg-target.c
+++ b/tcg/arm/tcg-target.c
@@ -1156,9 +1156,16 @@ stati
Instead of using a branch-call-branch sequence, arrange for a
call-branch sequence, using the ARM's conditional call insn.
This reduces the size of the slow-path within the TB, and makes
the GETPC_EXT implementation identical for TCG and not-TCG.
Signed-off-by: Richard Henderson
---
include/exec
One of the two constraints we already checked via #if, but
the tlb offset distance was only checked at runtime.
Signed-off-by: Richard Henderson
---
tcg/arm/tcg-target.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target
Moves the load for the tlb addend earlier, to better load latency.
Avoids the writeback from the comparator load, since we know how
to adjust the offset between the two loads.
: e2862c03 add r2, r6, #768; 0x300
: e20c00ff and r0, ip, #255; 0xff
: e0822280 add r2,
Public bug reported:
Download a Fedora 19 ISO from:
http://mirrors.kernel.org/fedora-secondary/releases/19/Fedora/ppc64/iso/
Compile qemu from git (I'm using 401c227b0a1134245ec61c6c5a9997cfc963c8e4
from today).
Run qemu-system-ppc64 like this:
ppc64-softmmu/qemu-system-ppc64 -M pseries -m 4096
** Description changed:
Download a Fedora 19 ISO from:
http://mirrors.kernel.org/fedora-secondary/releases/19/Fedora/ppc64/iso/
Compile qemu from git (I'm using 401c227b0a1134245ec61c6c5a9997cfc963c8e4
from today).
Run qemu-system-ppc64 like this:
ppc64-softmmu/qemu-system-ppc
On Mon, Aug 26, 2013 at 02:00:12PM -0700, Richard Henderson wrote:
> Discontinue the jump-around-jump-to-jump scheme, trading it for a single
> immediate move instruction. The two extra jumps always consume 7 bytes,
> whereas the immediate move is either 5 or 7 bytes depending on where the
> code_
git bisect points the finger at:
401c227b0a1134245ec61c6c5a9997cfc963c8e4 is the first bad commit
commit 401c227b0a1134245ec61c6c5a9997cfc963c8e4
Author: Richard Henderson
Date: Thu Jul 25 07:16:52 2013 -1000
tcg-i386: Use new return-argument ld/st helpers
Discontinue the jump-aro
The function qemu_notify_event is defined by a header that we don't
include in the PPC KVM code. Include it to get the code building
again.
target-ppc/kvm_ppc.c: In function 'kvmppc_timer_hack':
target-ppc/kvm_ppc.c:26:5: error: implicit declaration of function
'qemu_notify_event' [-Werror=im
On 08/29/2013 01:18 AM, Alex Williamson wrote:
> On Thu, 2013-08-22 at 21:29 +1000, Alexey Kardashevskiy wrote:
>> Upcoming VFIO on SPAPR PPC64 support will initialize the IOMMU
>> memory region with UINT64_MAX (2^64 bytes) size so int128_get64()
>> will assert.
>>
>> The patch takes care of this c
Now there's a second whitelist, right before the vcpu starts. The second
whitelist is the same as the first one, except for exec() and select().
Signed-off-by: Eduardo Otubo
---
The second whitelist is installed right before the vcpu starts, it contains all
the system calls the first one has exce
于 2013-8-28 16:49, Stefan Hajnoczi 写道:
On Wed, Aug 28, 2013 at 11:25:33AM +0800, Wenchao Xia wrote:
+void aio_context_release(AioContext *ctx)
+{
+qemu_mutex_lock(&ctx->acquire_lock);
+assert(ctx->owner && qemu_thread_is_self(ctx->owner));
+ctx->owner = NULL;
+qemu_cond_signal(&c
On Thu, 2013-08-29 at 11:03 +1000, Alexey Kardashevskiy wrote:
> On 08/29/2013 01:18 AM, Alex Williamson wrote:
> > On Thu, 2013-08-22 at 21:29 +1000, Alexey Kardashevskiy wrote:
> >> Upcoming VFIO on SPAPR PPC64 support will initialize the IOMMU
> >> memory region with UINT64_MAX (2^64 bytes) size
After OS ejecting a vcpu successful, it will call CPEJ method,
there communicate the masked vcpu bitmap to QEMU.
Signed-off-by: Chen Fan
---
src/acpi-dsdt-cpu-hotplug.dsl | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/acpi-dsdt-cpu-hotplug.dsl b/src/acpi-dsdt-cpu-ho
On 2013/8/28 20:57, Eric Blake wrote:
On 08/12/2013 10:31 PM, Dong Xu Wang wrote:
This patch moves the default value entirely to QemuOptDesc.
When getting the value of an option that hasn't been set, and
QemuOptDesc has a default value, return that. Else, behave as
before.
...
Else, ret
On 2013/8/28 20:53, Eric Blake wrote:
On 08/12/2013 10:31 PM, Dong Xu Wang wrote:
qemu_opts_print has no user now, so can re-write the function safely.
qemu_opts_print is used while using "qemu-img create", it
produces the same output as previous code.
The behavior of this function has changed
After ACPI get a signal to eject a vcpu, then it will notify
the vcpu thread of needing to exit, before the vcpu exiting,
will release the vcpu related objects.
Signed-off-by: Chen Fan
---
cpus.c | 36
hw/acpi/piix4.c | 16
Rename variable 'cpu_added_notifier' to 'cpu_hotplug_notifier', for
adding vcpu-remove notifier support.
Signed-off-by: Chen Fan
---
hw/acpi/piix4.c | 10 +-
hw/i386/pc.c| 2 +-
include/sysemu/sysemu.h | 2 +-
qom/cpu.c | 10 +-
4 files changed
Signed-off-by: Chen Fan
---
hw/i386/pc.c | 5 +
hw/i386/pc_piix.c| 1 +
include/hw/boards.h | 2 ++
include/hw/i386/pc.h | 1 +
qapi-schema.json | 12
qmp-commands.hx | 23 +++
qmp.c| 9 +
7 files changed, 53
When OS eject a vcpu (like: echo 1 > /sys/bus/acpi/devices/LNXCPUXX/eject),
it will call acpi EJ0 method, the firmware will write the new cpumap, QEMU
will know which vcpu need to be ejected.
Signed-off-by: Chen Fan
---
hw/acpi/piix4.c | 35 ++-
1 file changed, 34
via implementing ACPI standard methods _EJ0, after Guest OS hot remove
one vcpu, it is able to send a signal to QEMU, then QEMU could notify
the assigned vcpu to exit.
this series patches must be used with seabios patch and KVM patch together.
for KVM patches:
http://comments.gmane.org/gmane.co
Move struct HotplugEventType from file piix4.c to file qom/cpu.c,
and add struct CPUNotifier for supporting PLUG and UNPLUG cpu notifier.
Signed-off-by: Chen Fan
---
hw/acpi/piix4.c | 8 ++--
include/qom/cpu.h | 10 ++
qom/cpu.c | 6 +-
3 files changed, 17 insertions(
Implement cpu interface 'cpu_common_unrealizefn' for emiting vcpu-remove
notifier to ACPI, then ACPI could send sci interrupt to OS for hot-remove
vcpu.
Signed-off-by: Chen Fan
---
hw/i386/pc.c | 19 ++-
qom/cpu.c| 13 +
2 files changed, 31 insertions(+), 1 deleti
On 08/28/2013 09:44 PM, Paolo Bonzini wrote:
> Il 26/08/2013 10:43, Andrew Jones ha scritto:
>>
>> - Original Message -
On 08/26/2013 03:46 PM, Andrew Jones wrote:
>> Is this patch still necessary? I thought that dropping the
>> numa_num_configured_nodes() calls fro
On 08/29/2013 11:42 AM, Alex Williamson wrote:
> On Thu, 2013-08-29 at 11:03 +1000, Alexey Kardashevskiy wrote:
>> On 08/29/2013 01:18 AM, Alex Williamson wrote:
>>> On Thu, 2013-08-22 at 21:29 +1000, Alexey Kardashevskiy wrote:
Upcoming VFIO on SPAPR PPC64 support will initialize the IOMMU
>>
As you know, QEMU can't direct it's memory allocation now, this may cause
guest cross node access performance regression.
And, the worse thing is that if PCI-passthrough is used,
direct-attached-device uses DMA transfer between device and qemu process.
All pages of the guest will be pinned by get_u
These are used to generate stuff for OptsVisitor.
Reviewed-by: Laszlo Ersek
Signed-off-by: Wanlong Gao
---
qapi-schema.json | 47 +++
1 file changed, 47 insertions(+)
diff --git a/qapi-schema.json b/qapi-schema.json
index a51f7d2..11851a1 100644
---
Signed-off-by: Wanlong Gao
---
cpus.c | 14 -
include/sysemu/cpus.h | 1 -
include/sysemu/sysemu.h | 2 ++
numa.c | 76 +
vl.c| 57 +
5 files chang
Change -numa option like following as Paolo suggested:
-numa node,nodeid=0,cpus=0-1 \
-numa mem,nodeid=0,size=1G
This new option will make later coming memory hotplug better.
And this new option is implemented using OptsVisitor.
And just remain "-numa node,mem=xx" as legacy.
Reviewed-by:
The memory policy setting format is like:
policy={default|membind|interleave|preferred}[,relative=true],host-nodes=N-N
And we are adding this setting as a suboption of "-numa mem,",
the memory policy then can be set like following:
-numa node,nodeid=0,cpus=0 \
-numa node,nodeid=1,cpus=1
Add the numa_info structure to contain the numa nodes memory,
VCPUs information and the future added numa nodes host memory
policies.
Reviewed-by: Eduardo Habkost
Signed-off-by: Andre Przywara
Signed-off-by: Wanlong Gao
---
hw/i386/pc.c| 4 ++--
include/sysemu/sysemu.h | 8 ++
Add hmp command set-mem-policy to set host memory policy for a guest
NUMA node. Then we can also set node's memory policy using
the monitor command like:
(qemu) set-mem-policy 0 policy=membind,relative=false,host-nodes=0-1
Signed-off-by: Wanlong Gao
---
hmp-commands.hx | 16 ++
h
Set the guest numa nodes memory policies using the mbind(2)
system call node by node.
After this patch, we are able to set guest nodes memory policies
through the QEMU options, this arms to solve the guest cross
nodes memory access performance issue.
And as you all know, if PCI-passthrough is used,
This QMP command allows user set guest node's memory policy
through the QMP protocol. The qmp-shell command is like:
set-mem-policy nodeid=0 policy=membind relative=true host-nodes=0-1
Signed-off-by: Wanlong Gao
---
numa.c | 62 ++
If the total number of the assigned numa nodes memory is not
equal to the assigned ram size, it will write the wrong data
to ACPI talb, then the guest will ignore the wrong ACPI table
and recognize all memory to one node. It's buggy, we should
check it to ensure that we write the right data to ACPI
Add qmp command query-numa to show guest NUMA information.
Signed-off-by: Wanlong Gao
---
numa.c | 65
qapi-schema.json | 36 +++
qmp-commands.hx | 49 ++
3 fil
Signed-off-by: Wanlong Gao
---
hmp.c | 54 ++
hmp.h | 1 +
monitor.c | 21 +
3 files changed, 56 insertions(+), 20 deletions(-)
diff --git a/hmp.c b/hmp.c
index ae695b0..2d878c6 100644
--- a/hmp.c
+++ b/hmp.c
@@ -27
On Wed, Aug 28, 2013 at 12:49:27PM +0200, Andreas Färber wrote:
> According to the only reply I received, it's "POWER7", not "POWER7+" -
> see my patch description. If that information was wrong, we'll need to
> move POWER7P introduction before my fw_name patch and update it accordingly.
It shoul
On 08/16/2013 08:35 AM, Andreas Färber wrote:
> Instead of relying on cpu_model, obtain the device tree node label
> per CPU. Use DeviceClass::fw_name when available. This implicitly
> resolves HOST@0 node labels for those CPUs through inheritance.
>
> Whenever DeviceClass::fw_name is not availabl
On 08/16/2013 08:35 AM, Andreas Färber wrote:
> Whenever DeviceClass::fw_name is not available, derive it from the CPU's
> type name, resorting to the parent's type in case of -cpu host, and fill
> it in for that class in a PAPR-compliant way with "PowerPC," prefix.
>
> Reported-by: Prerna Saxena
On 08/16/2013 08:35 AM, Andreas Färber wrote:
> PAPR requires that PowerPC, shall not contain underscores, so skip
> any underscores in the type name.
Again, as this is for sPAPR only and spapr-supported CPUs have fw_name, why
to bother with "_" at all? Where can it possibly come from?
Sorry if I
On Thu, Aug 29, 2013 at 01:33:07PM +1000, Paul Mackerras wrote:
> On Wed, Aug 28, 2013 at 12:49:27PM +0200, Andreas Färber wrote:
>
> > According to the only reply I received, it's "POWER7", not "POWER7+" -
> > see my patch description. If that information was wrong, we'll need to
> > move POWER7P
On Thu, 2013-08-29 at 14:52 +1000, Paul Mackerras wrote:
> We are going to need a way to do that for pseries guests. So for
> example if we are running on a POWER8 machine and using KVM, we would
> want to be able to tell qemu that we want a POWER7 machine and have
> qemu put 0x0f03 in the dev
Am 29.08.2013 04:09, schrieb Chen Fan:
> After ACPI get a signal to eject a vcpu, then it will notify
> the vcpu thread of needing to exit, before the vcpu exiting,
> will release the vcpu related objects.
>
> Signed-off-by: Chen Fan
> ---
> cpus.c | 36
Am 29.08.2013 04:09, schrieb Chen Fan:
> Implement cpu interface 'cpu_common_unrealizefn' for emiting vcpu-remove
> notifier to ACPI, then ACPI could send sci interrupt to OS for hot-remove
> vcpu.
>
> Signed-off-by: Chen Fan
> ---
> hw/i386/pc.c | 19 ++-
> qom/cpu.c| 13 +++
Am 29.08.2013 06:29, schrieb Alexey Kardashevskiy:
> On 08/16/2013 08:35 AM, Andreas Färber wrote:
>> Instead of relying on cpu_model, obtain the device tree node label
>> per CPU. Use DeviceClass::fw_name when available. This implicitly
>> resolves HOST@0 node labels for those CPUs through inherit
Am 29.08.2013 06:33, schrieb Alexey Kardashevskiy:
> On 08/16/2013 08:35 AM, Andreas Färber wrote:
>> Whenever DeviceClass::fw_name is not available, derive it from the CPU's
>> type name, resorting to the parent's type in case of -cpu host, and fill
>> it in for that class in a PAPR-compliant way
Am 29.08.2013 06:39, schrieb Alexey Kardashevskiy:
> On 08/16/2013 08:35 AM, Andreas Färber wrote:
>> PAPR requires that PowerPC, shall not contain underscores, so skip
>> any underscores in the type name.
>
> Again, as this is for sPAPR only and spapr-supported CPUs have fw_name, why
> to bother
I just tried it on Windows XP and its working fine there. So this
problem comes only on Windows 7.
-Taimoor
On Thu, Aug 29, 2013 at 12:10 AM, Taimoor Mirza wrote:
> Hi Stefan,
>
> Below is result of bt:
>
> Breakpoint 1, 0x006ac304 in abort ()
> (gdb) bt
> #0 0x006ac304 in abort ()
> #1 0x0055
Il 29/08/2013 04:26, Alexey Kardashevskiy ha scritto:
>
> Right. I was planning to add my IOMMU stuff right before calculating @end.
But then the non-IOMMU stuff can just use int128_get64, no? So even if
this patch simply uses int128_get64, it is still a suitable basis for
adding IOMMU stuff.
P
201 - 261 of 261 matches
Mail list logo
