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
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
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
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: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 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 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
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
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 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 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:
> 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 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
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
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
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 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
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 ++
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:
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
>>
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
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
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(
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
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
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
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
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 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
于 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
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
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
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
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
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_
** 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
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
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,
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
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
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-
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
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
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 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 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 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 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: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 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 Sat, Aug 17, 2013 at 04:26:46PM -0700, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> tcg/optimize.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/tcg/optimize.c b/tcg/optimize.c
> index e8dedf3..b29bf25 100644
> --- a/tcg/optimize.c
>
On Sat, Aug 17, 2013 at 04:26:44PM -0700, Richard Henderson wrote:
> With the optimization in tcg_liveness_analysis,
> we can avoid the MFLO when it is unused.
>
> Signed-off-by: Richard Henderson
> ---
> tcg/mips/tcg-target.c | 10 ++
> tcg/mips/tcg-target.h | 4 ++--
> 2 files changed
On Sat, Aug 17, 2013 at 04:26:45PM -0700, Richard Henderson wrote:
> Using these instead of mulu2 and muls2 lets us avoid having to argument
> overlap analysis in the backend. Normal register allocation will DTRT.
>
> Signed-off-by: Richard Henderson
> ---
> tcg/ppc64/tcg-target.c | 32 +++-
On Sat, Aug 17, 2013 at 04:26:43PM -0700, Richard Henderson wrote:
> Use them in places where mulu2 and muls2 are used.
> Optimize mulx2 with dead low part to mulxh.
>
> Signed-off-by: Richard Henderson
> ---
> tcg/aarch64/tcg-target.h | 4
> tcg/arm/tcg-target.h | 2 ++
> tcg/hppa/tc
On Wed, Aug 28, 2013 at 08:26:43AM -0700, Richard Henderson wrote:
> On 08/28/2013 07:34 AM, Peter Maydell wrote:
> > On 28 August 2013 15:31, Richard Henderson wrote:
> >> On 08/28/2013 01:15 AM, Peter Maydell wrote:
> >>> [*] not impossible, we already do something on the ppc
> >>> that's simila
Benoît Canet wrote:
thanks for your help. I cloned the git and compiled it - but I'm not
completely sure how to enable the throttling finally - there were
several mails regarding averages and max values... And the "unit" of
the values would be interesting.
Hi Erik,
The main settings are bps, b
Jan Kiszka writes:
> On 2013-08-28 20:12, Lluís Vilanova wrote:
>> Jan Kiszka writes:
>> [...]
Is it possible to give a nested guest direct access to a device on the
guest?
(more specifically, an AHCI controller).
>>
>>> Nope, we are lacking support for emulating or (securely) for
Hi Stefan,
Below is result of bt:
Breakpoint 1, 0x006ac304 in abort ()
(gdb) bt
#0 0x006ac304 in abort ()
#1 0x00553052 in _fu10846stack_chk_guard () at qemu-coroutine.c:111
#2 0x0040d746 in _fu473stack_chk_guard () at block.c:4294
#3 0x00413cc7 in _fu805stack_chk_guard () at bloc
> thanks for your help. I cloned the git and compiled it - but I'm not
> completely sure how to enable the throttling finally - there were
> several mails regarding averages and max values... And the "unit" of
> the values would be interesting.
Hi Erik,
The main settings are bps, bps_rd and bps_w
Benoît Canet wrote:
Can you whip up a patch to avoid that? Or to honor bps_max if it is
specified (making avg/10 simply the default)?
Pushed in the same branch (it honor bps_max if specified).
Best regards
Benoît
Hi all,
thanks for your help. I cloned the git and compiled it - but I'm no
On 2013-08-28 20:12, Lluís Vilanova wrote:
> Jan Kiszka writes:
> [...]
>>> Is it possible to give a nested guest direct access to a device on the
>>> guest?
>>> (more specifically, an AHCI controller).
>
>> Nope, we are lacking support for emulating or (securely) forwarding
>> VT-d/IOMMU feature
Jan Kiszka writes:
[...]
>> Is it possible to give a nested guest direct access to a device on the guest?
>> (more specifically, an AHCI controller).
> Nope, we are lacking support for emulating or (securely) forwarding
> VT-d/IOMMU features to the first level guest. Would be cool to have,
> just
On 08/28/2013 10:28 AM, Stefan Weil wrote:
> Commit ac26eb69a311396668809eadbf7ff4e623447d4c added tcg_out64 to tcg/tcg.c.
> tcg/tci/tcg-target.c already had a nearly identical implementation which is
> now removed to fix a compiler error.
>
> Signed-off-by: Stefan Weil
Oops, yes.
Reviewed-by:
Am 30.07.2013 00:35, schrieb Laszlo Ersek:
> On 07/29/13 20:18, Stefan Weil wrote:
>> Am 29.07.2013 20:05, schrieb Anthony Liguori:
>>> Stefan Weil writes:
>>>
Hello,
maybe most developers will already have noticed that the terminal output
in QEMU's GTK user interface is broken
On Wed, Aug 28, 2013 at 01:39:52PM +0100, Leon Alrae wrote:
> From: James Hogan
>
> Commit a427338 (mips_malta: correct reading MIPS revision at 0x1fc00010)
> altered the behaviour of the monitor flash mapping at the reset address
> by making it read only. However this causes data bus error excep
On 08/28/2013 10:28 AM, Peter Maydell wrote:
> Well, what do ldl_p or ldl_phys or any of the other functions
> without an le/be qualifier mean any more if "is this CPU in
> big endian mode?" now requires you to have a CPUState
> to ask? I guess we can tackle that separately from getting
> the assum
Am 28.08.2013 18:38, schrieb Peter Maydell:
> On 28 August 2013 16:26, Richard Henderson wrote:
>
>> (D) Profit! I'm not sure what will be left of TARGET_WORDS_BIGENDIAN at this
>> point. Possibly only if we leave the current translator interface in place
>> in
>> step A.
> I think there are a
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.
When/if we switch to an MMIO region, we can switch to using a proper
64-bit register for setting up queues.
Regards,
Anthony
On 2013-08-28 18:37, Markus Armbruster wrote:
>>> 3. Why does CONFIG_MIXEMU exist?
>>>
>> I can post a patch for it (again) on top of these changes and
>> see where it goes. If the default value of the "mixer" property stays
>> off, malc's concerns mentioned elsewhere in this thread will be taken
On 28 August 2013 18:16, Richard Henderson wrote:
> On 08/28/2013 09:38 AM, Peter Maydell wrote:
>>> (B) Add an additional bit to the "opc" to indicate which endianness is
>>> desired.
>>> E.g. 0 = LE, 8 = BE. Expose the opc interface to the translators. At
>>> which
>>> point generating a lo
Commit ac26eb69a311396668809eadbf7ff4e623447d4c added tcg_out64 to tcg/tcg.c.
tcg/tci/tcg-target.c already had a nearly identical implementation which is
now removed to fix a compiler error.
Signed-off-by: Stefan Weil
---
tcg/tci/tcg-target.c |7 ---
1 file changed, 7 deletions(-)
diff
From: Jan Kiszka
Now that cpu_in/out is just a wrapper around address_space_rw, we can
also call the latter directly. As host endianness == guest endianness,
there is no need for the memory access helpers st*_p/ld*_p as well.
Signed-off-by: Jan Kiszka
Signed-off-by: Paolo Bonzini
---
kvm-all.
Il 27/08/2013 10:55, Alex Bligh ha scritto:
>> + * Note that this function should not be used when other threads also access
>> + * the timer list. The return value may be outdated by the time it is acted
>> + * upon.
>> + *
>
> I'm in two minds as to whether there is a problem with the comment o
On 2013-08-25 04:01, Liu Ping Fan wrote:
> With this series, we can set the mainloop timeout more precisely when slirp
> has
> to emulate tcp timeout problem.
>
> v4:
> use macro TIMEOUT_DEFAULT to define the default timeout of slirp and
> document it.
>
> v3:
> fix comment: document timeou
From: Liu Jinsong
This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623
IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to
cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs
or kvm_get_msrs.
Signed-off-by: Liu Jinsong
Signed-off-by
On 08/28/2013 09:38 AM, Peter Maydell wrote:
>> (B) Add an additional bit to the "opc" to indicate which endianness is
>> desired.
>> E.g. 0 = LE, 8 = BE. Expose the opc interface to the translators. At which
>> point generating a load becomes more like
>>
>> tcg_gen_qemu_ld_tl(dest, addr,
From: Paolo Bonzini
Signed-off-by: Paolo Bonzini
---
target-i386/cpu.h | 192 ++---
1 file changed, 96 insertions(+), 96 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 3a52f94..af4c0f7 100644
--- a/target-i386/cpu.h
+++ b/
On 2013-08-28 16:28, Lluís Vilanova wrote:
> Hi,
>
> I want to get the following setup, but don't know how (or if it's even
> possible):
>
> * A guest VM with two AHCI controllers, with one device each. One of the AHCI
> controllers provides the VM's disk ("system"), while the other provides
>
On Fri, Aug 23, 2013 at 03:57:18PM +0100, Yongbok Kim wrote:
> A parenthesis placed inappropriately caused displaying
> wrong memory size bigger than 4GB.
>
> Signed-off-by: Yongbok Kim
> ---
> hw/mips/mips_malta.c |2 +-
> hw/mips/mips_r4k.c|2 +-
> hw/ppc/mac_oldworld.c |2 +-
The pre-write overlap check function is now called before most of the
qcow2 writes (aborting it on collision or other error).
Signed-off-by: Max Reitz
---
block/qcow2-cache.c| 17 +
block/qcow2-cluster.c | 21 +
block/qcow2-snapshot.c | 22 +++
On Fri, Aug 23, 2013 at 04:09:46PM +0100, Yongbok Kim wrote:
> From: Paul Burton
>
> A Malta board can support up to 2GiB of RAM. Since the unmapped kseg0/1
> regions are only 512MiB large & the latter 256MiB of those are taken up
> by the IO region, access to RAM beyond 256MiB must be done throu
From: Marcelo Tosatti
maxcpus, which specifies the maximum number of hotpluggable CPUs,
should not exceed KVM's vcpu limit.
Signed-off-by: Marcelo Tosatti
[Reword message. - Paolo]
Signed-off-by: Paolo Bonzini
---
kvm-all.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/kvm-all
On 28 August 2013 16:26, Richard Henderson wrote:
> On 08/28/2013 07:34 AM, Peter Maydell wrote:
>> On 28 August 2013 15:31, Richard Henderson wrote:
>>> On 08/28/2013 01:15 AM, Peter Maydell wrote:
[*] not impossible, we already do something on the ppc
that's similar; however I'd reall
Bandan Das writes:
> Markus Armbruster writes:
>
>> Bandan Das writes:
>>
>>> Currently, hda-codec mixer emulation can only be enabled by using the
>>> "--enable-mixemu" option to configure at compile time. These patches add
>>> the option to make it configurable at runtime as well.
>>>
>>> A
Il 28/08/2013 18:02, Mike Day ha scritto:
> @@ -1102,15 +1110,15 @@ void qemu_ram_set_idstr(ram_addr_t addr, const char
> *name, DeviceState *dev)
> pstrcat(new_block->idstr, sizeof(new_block->idstr), name);
>
> /* This assumes the iothread lock is taken here too. */
> -qemu_mutex
On 08/27/2013 02:46 PM, Richard Henderson wrote:
> -{ INDEX_op_qemu_ld8u, { "r", "L" } },
> -{ INDEX_op_qemu_ld8s, { "r", "L" } },
> -{ INDEX_op_qemu_ld16u, { "r", "L" } },
> -{ INDEX_op_qemu_ld16s, { "r", "L" } },
> -{ INDEX_op_qemu_ld32, { "r", "L" } },
> -{ INDEX_op_qemu_
Il 28/08/2013 18:02, Mike Day ha scritto:
> @@ -457,8 +459,9 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
> MemoryRegion *mr;
> ram_addr_t current_addr;
>
> +rcu_read_lock();
> if (!block)
> -block = QTAILQ_FIRST(&ram_list.blocks);
> +block = QLIST
From: Arthur Chunqi Li
The recent KVM patch adds IA32_FEATURE_CONTROL support. QEMU needs
to clear this MSR when reset vCPU and keep the value of it when
migration. This patch add this feature.
Signed-off-by: Arthur Chunqi Li
Signed-off-by: Gleb Natapov
---
target-i386/cpu.h |2 ++
ta
Two new functions are added; the first one checks a given range in the
image file for overlaps with metadata (main header, L1 tables, L2
tables, refcount table and blocks).
The second one should be used immediately before writing to the image
file as it calls the first function and, upon collision
1 - 100 of 261 matches
Mail list logo
