On Tue, Mar 24, 2015 at 05:24:55PM +1100, Gavin Shan wrote:
> On Tue, Mar 24, 2015 at 04:41:21PM +1100, David Gibson wrote:
> >On Mon, Mar 23, 2015 at 04:25:10PM +1100, Gavin Shan wrote:
> >> On Mon, Mar 23, 2015 at 04:06:56PM +1100, David Gibson wrote:
> >> >On Fri, Mar 20, 2015 at 05:27:29PM +110
On Tue, Mar 24, 2015 at 04:41:21PM +1100, David Gibson wrote:
>On Mon, Mar 23, 2015 at 04:25:10PM +1100, Gavin Shan wrote:
>> On Mon, Mar 23, 2015 at 04:06:56PM +1100, David Gibson wrote:
>> >On Fri, Mar 20, 2015 at 05:27:29PM +1100, Gavin Shan wrote:
>> >> On Fri, Mar 20, 2015 at 05:04:01PM +1100,
On Tue, Mar 17, 2015 at 10:03:49PM +1100, Alexey Kardashevskiy wrote:
> On 03/10/2015 02:51 PM, Alexey Kardashevskiy wrote:
> >On 02/23/2015 07:33 PM, Alexey Kardashevskiy wrote:
> >>These I have in my DDW working tree for quite a while, while I am polishing
> >>others, there could go to some tree
On Mon, Mar 23, 2015 at 04:25:10PM +1100, Gavin Shan wrote:
> On Mon, Mar 23, 2015 at 04:06:56PM +1100, David Gibson wrote:
> >On Fri, Mar 20, 2015 at 05:27:29PM +1100, Gavin Shan wrote:
> >> On Fri, Mar 20, 2015 at 05:04:01PM +1100, David Gibson wrote:
> >> >On Tue, Mar 17, 2015 at 03:31:24AM +110
On Wed, Feb 25, 2015 at 04:52:03PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> userfaultfd is a Linux syscall that gives an fd that receives a stream
> of notifications of accesses to pages registered with it and allows
> the program to acknowledge those stalls
On Wed, Feb 25, 2015 at 04:52:02PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Prior to the start of postcopy, ensure that everything that will
> be transferred later is a whole host-page in size.
>
> This is accomplished by discarding partially transferred ho
On Wed, Feb 25, 2015 at 04:52:00PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Postcopy sends RAMBlock names and offsets over the wire (since it can't
> rely on the order of ramaddr being the same), and it starts out with
> HVA fault addresses from the kernel.
On Wed, Feb 25, 2015 at 04:52:01PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Once we're in postcopy the source processors are stopped and memory
> shouldn't change any more, so there's no need to look at the dirty
> map.
>
> There are two notes to this:
>
On Wed, Feb 25, 2015 at 04:51:59PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> In postcopy, the destination guest is running at the same time
> as it's receiving pages; as we receive new pages we must put
> them into the guests address space atomically to avoid
On Wed, Feb 25, 2015 at 04:51:58PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> postcopy_place_page (etc) provide a way for postcopy to place a page
> into guests memory atomically (using the copy ioctl on the ufd).
>
> Signed-off-by: Dr. David Alan Gilbert
>
On Sun, Mar 22, 2015 at 07:30:07AM -0700, Sergey Fedorov wrote:
> On 20.03.2015 21:49, Edgar E. Iglesias wrote:
> > Hi all,
> >
> > Sergey, that's good to hear!
> >
> > Peter, Yes I have quite a bit of patch material but unfortunately a lot of
> > it is not in a state for upstreaming. I know I've p
> -Original Message-
> From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
> Sent: Tuesday, March 24, 2015 4:01 AM
> To: Xu, Quan; Ian Campbell
> Cc: ke...@koconnor.net; qemu-devel@nongnu.org;
> stefano.stabell...@eu.citrix.com; xen-de...@lists.xen.org
> Subject: Re: [Qemu-devel] [Xen
On Wed, Feb 25, 2015 at 04:51:56PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> On receiving MIG_RPCOMM_REQ_PAGES look up the address and
> queue the page.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> arch_init.c | 55
> +++
On Wed, Feb 25, 2015 at 04:51:57PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> When transmitting RAM pages, consume pages that have been queued by
> MIG_RPCOMM_REQPAGE commands and send them ahead of normal page scanning.
>
> Note:
> a) After a queued page t
On Mon, Mar 23, 2015 at 12:21:50PM +, Dr. David Alan Gilbert wrote:
> * David Gibson (da...@gibson.dropbear.id.au) wrote:
> > On Wed, Feb 25, 2015 at 04:52:08PM +, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > The userfault mechanism used for po
This fixes a segfault when doing unaligned zero write to an image that is 4k
aligned.
v2: Don't drop the unset of UNMAP flag. [Stefan, Peter]
Reproducer:
$ (echo "open -o file.align=4k blkdebug::img"; echo "write -z 512 1024") |
qemu-io
Fam Zheng (2):
block: Fix unaligned zero write
qe
If the zero write is not aligned, bdrv_co_do_pwritev will segfault
because of accessing to the NULL qiov passed in by bdrv_co_write_zeroes.
Fix this by allocating a local qiov in bdrv_co_do_pwritev if the request
is not aligned. (In this case the padding iovs are necessary anyway, so
it doesn't hur
Signed-off-by: Fam Zheng
---
tests/qemu-iotests/033 | 47 +-
tests/qemu-iotests/033.out | 26 +
2 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/tests/qemu-iotests/033 b/tests/qemu-iotests/033
index ea3351c..4
On Mon, 03/23 14:14, Stefan Hajnoczi wrote:
> On Mon, Mar 23, 2015 at 12:46:09PM +0800, Fam Zheng wrote:
> > @@ -3435,6 +3446,10 @@ static int coroutine_fn
> > bdrv_co_do_pwritev(BlockDriverState *bs,
> > bytes = ROUND_UP(bytes, align);
> > }
> >
> > +if (use_local_qiov) {
> >
On Mon, 03/23 14:28, Stefan Hajnoczi wrote:
> On Mon, Mar 23, 2015 at 1:58 PM, Paolo Bonzini wrote:
> > On 23/03/2015 14:56, Stefan Hajnoczi wrote:
> >> On Mon, Mar 23, 2015 at 01:24:15PM +0800, Fam Zheng wrote:
> >>> Currently, throttle timers won't make any progress when VCPU is not
> >>> runnin
On 03/23/2015 02:42 PM, Stefan Weil wrote:
> Further optimizations are possible. TCGTemp can be reduced to 32 bytes as the
> output
> of pahole shows:
>
> struct TCGTemp {
> TCGTempVal val_type:8; /* 0:24 4 */
Need only be 2 bits.
> unsigned int
Thank you for the advice!
It will be grateful if someone can provide any guide how to config MegaSAS HBA
or how to use xen pvscsi in XEN.
There seems no option in XEN for these two driver emulation and no document
found online.
Thanks!
-Original Message-
From: Stefano Stabellini [mailt
On Mon, Mar 23, 2015 at 10:54:39AM +0100, BALATON Zoltan wrote:
> On Mon, 23 Mar 2015, David Gibson wrote:
> >If the guest programs a sufficiently large timeout value an integer
> >overflow can occur in i6300esb_restart_timer(). e.g. if the maximum
> >possible timer preload value of 0xf is pro
Am 22.03.2015 um 09:26 schrieb Paolo Bonzini:
> 32-bit PPC cannot do atomic operations on long long. Inside the loops,
> we are already using local counters that are summed at the end of
> the run---with some exceptions (rcu_stress_count for rcutorture,
> n_nodes for test-rcu-list): fix them to us
On 3/23/15 23:06, Richard Henderson wrote:
> On 03/21/2015 03:23 AM, Chen Gang wrote:
>> Add related configuration, make files for tilegx.
>>
>> Signed-off-by: Chen Gang
>> ---
>> configure | 3 +++
>> default-configs/tilegx-linux-user.mak | 1 +
>> target-tilegx/Make
The logic for decoding websocket frames wants to fully
decode the frame header and payload, before allowing the
VNC server to see any of the payload data. There is no
size limit on websocket payloads, so this allows a
malicious network client to consume 2^64 bytes in memory
in QEMU. It can trigger
The VNC server websockets decoder will read and buffer data from
websockets clients until it sees the end of the HTTP headers,
as indicated by \r\n\r\n. In theory this allows a malicious to
trick QEMU into consuming an arbitrary amount of RAM. In practice,
because QEMU runs g_strstr_len() across th
The VNC websockets protocol decoder has two places where it did
not correctly limit its resource usage when processing data from
the client. This can be abused by a malicious client to cause QEMU
to consume all system memory, unless it is otherwise limited by
ulimits and/or cgroups. These problems
On 23 March 2015 at 10:04, Markus Armbruster wrote:
> First of all, my apologies for being so late with this. I realized
> part way through the current development cycle that I couldn't do both
> the error work and my half of the block probing work we discussed back
> in November, so I punted the
On 03/23/2015 10:11 PM, Paolo Bonzini wrote:
On 23/03/2015 19:21, Alexander Graf wrote:
On 03/23/2015 07:20 PM, Marcel Apfelbaum wrote:
On 03/23/2015 07:05 PM, Paolo Bonzini wrote:
Capture the explicit setting of "usb=no" into a separate bool, and
use it to skip the update of machine->usb in
Am 21.03.2015 um 07:27 schrieb Emilio G. Cota:
This brings down the size of the struct from 56 to 48 bytes.
Signed-off-by: Emilio G. Cota
---
tcg/tcg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tcg/tcg.h b/tcg/tcg.h
index add7f75..3276924 100644
--- a/tcg/tcg.h
+++
Peter Maydell writes:
> On 23 March 2015 at 19:09, Markus Armbruster wrote:
>> Due to misuse of drive_get_next(), -device sdhci can connect to a
>> -drive if=sd,... If you can't see what's wrong here, check out the
>> FIXME in sdhci_initfn() and the commit that added it.
>>
>> We can't fix this
Paolo Bonzini writes:
> On 23/03/2015 11:04, Markus Armbruster wrote:
>> Probing is convenient, but probing untrusted raw images is insecure
>> (CVE-2008-2004). To avoid it, users should always specify raw format
>> explicitly. This isn't trivial, and even sophisticated users have
>> gotten it
Paolo Bonzini writes:
> On 23/03/2015 18:48, Eric Blake wrote:
>>> Why can't libvirt just add ,format=raw instead of leaving out the
>>> format key altogether?
>>
>> Libvirt DOES add format=raw. This patch is an extra insurance
>> policy to guarantee that libvirt does not have any code paths th
Hi Gerd,
This looks great, thanks for your work on this. Unfortunately, I'm seeing the
segfault below.
Alex, do you have any thoughts on how well this might be able to replace the
Goldfish Framebuffer on the Android Emulator?
On 03/13/2015 05:47 AM, Gerd Hoffmann wrote:
> Hi,
>
> Next round o
On 23/03/2015 19:21, Alexander Graf wrote:
> On 03/23/2015 07:20 PM, Marcel Apfelbaum wrote:
>> On 03/23/2015 07:05 PM, Paolo Bonzini wrote:
>>> Capture the explicit setting of "usb=no" into a separate bool, and
>>> use it to skip the update of machine->usb in the board init function.
>>>
>>> Sig
On 03/23/2015 08:44 AM, Xu, Quan wrote:
-Original Message-
From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
Sent: Thursday, March 19, 2015 3:17 AM
To: Xu, Quan; stefano.stabell...@eu.citrix.com; qemu-devel@nongnu.org;
arm...@redhat.com; lcapitul...@redhat.com; aligu...@amazon.com
On 03/23/2015 08:03 AM, Xu, Quan wrote:
-Original Message-
From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
Sent: Monday, March 23, 2015 6:57 PM
To: Xu, Quan; Ian Campbell
Cc: ke...@koconnor.net; xen-de...@lists.xen.org; qemu-devel@nongnu.org;
stefano.stabell...@eu.citrix.com
Sub
Am 23.03.2015 um 20:29 schrieb Joseph Hindin:
Hi
About a week ago I've submitted the revised patch for QEMU GA
Windows cross-compilation. Since then I've not got any responses.
Would you mind to look into the proposed patch?
Regards,
Joseph Hindin
http://lists.nongnu.org/arch
Add a test case to ensure reordering the feature handling code won't
make accelerator-specific defaults override explicit command-line
options. Explicit command-line options should always override the CPU
model defaults.
Signed-off-by: Eduardo Habkost
---
tests/test-x86-cpu.c | 31 ++
Signed-off-by: Eduardo Habkost
---
tests/test-x86-cpu.c | 84
1 file changed, 84 insertions(+)
diff --git a/tests/test-x86-cpu.c b/tests/test-x86-cpu.c
index a0923e7..b1b04ea 100644
--- a/tests/test-x86-cpu.c
+++ b/tests/test-x86-cpu.c
@@ -78,
The unit test includes target-i386/cpu.c instead of simply linking
against cpu.o because the test code will use static variables/functions
from cpu.c.
Reasoning for each object file included in the test binary:
* qom/cpu.o - for TYPE_CPU. Dependencies:
* qom/qom-qobject.o
* qom/qdev.o - for T
This will make it easier to write unit tests for the feature
initialization logic.
Signed-off-by: Eduardo Habkost
---
target-i386/cpu.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index b2d1c95..8557a98 100644
--- a/targe
Instead of using a test-specific hack to add -I$(SRC_PATH)/target-i386, add
test-x86-cpuid to $(test-obj-x86_64-softmmu-y).
Signed-off-by: Eduardo Habkost
---
tests/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/Makefile b/tests/Makefile
index 33b74a2..1a78
Signed-off-by: Eduardo Habkost
---
tests/test-x86-cpu.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/tests/test-x86-cpu.c b/tests/test-x86-cpu.c
index 1ce7e1d..a0923e7 100644
--- a/tests/test-x86-cpu.c
+++ b/tests/test-x86-cpu.c
@@ -54,6 +54,30 @@ static void tes
Changes v4 -> v5:
* Rewrite fake kvm_arch_get_supported_cpuid() code
* Add new test to ensure KVM defaults won't override explicit command-line
options
Changes v3 -> v4:
* Move target_words_bigendian() prototype back inside tests/x86-stub.c.
Changes v2 -> v3:
* Extra KVM "host" CPU model t
To make unit tests that depend on target-specific files, use
check-unit--y and test-obj--y.
Note that the qtest test cases were per-*arch* (e.g. i386, mips, ppc),
not per-*target* (e.g. i386-softmmu, x86_64-linux-user), because they
implicitly apply only to the -softmmu targets. Target-specific un
Cc'ing Kevin as fair punishment for is previous work on QAPI code
generation in general, and union types in particular.
Eric Blake writes:
> [revisiting this series, finally!]
>
> On 09/25/2014 10:19 AM, Markus Armbruster wrote:
>
>>> Return of an anon union isn't used yet, but _might_ make sens
On Wed, 11 Mar 2015, Alexander Graf wrote:
> > So if you know how to get working floppy disk with qemu-system-ppc64,
> > that would help me a lot in rejecting requests from libvirt folks :)
> > Thanks :)
>
> I don't think you want floppy disk emulation on -M pseries at all. In
> fact, you only ev
On 23 March 2015 at 19:09, Markus Armbruster wrote:
> Due to misuse of drive_get_next(), -device sdhci can connect to a
> -drive if=sd,... If you can't see what's wrong here, check out the
> FIXME in sdhci_initfn() and the commit that added it.
>
> We can't fix this in time for the release, but s
Due to misuse of drive_get_next(), -device sdhci can connect to a
-drive if=sd,... If you can't see what's wrong here, check out the
FIXME in sdhci_initfn() and the commit that added it.
We can't fix this in time for the release, but since the device is new
in 2.3, we can disable it before this m
A number of sysbus devices abuse drive_get_next(): sl-nand,
milkymist-memcard, pl181, generic-sdhci. If you can't see what's
wrong with their use of drive_get_next(), check out the FIXMEs in
their init() methods and the commit that added them.
We're in luck, though: only machines ppce500 and pser
Drives defined with if!=none are for board initialization to wire up.
Board code calls drive_get() or similar to find them, and creates
devices with their qdev drive properties set accordingly.
Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a drive prope
Drives defined with if!=none are for board initialization to wire up.
Board code calls drive_get() or similar to find them, and creates
devices with their qdev drive properties set accordingly.
Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a drive prope
On 03/23/2015 07:20 PM, Marcel Apfelbaum wrote:
On 03/23/2015 07:05 PM, Paolo Bonzini wrote:
Capture the explicit setting of "usb=no" into a separate bool, and
use it to skip the update of machine->usb in the board init function.
Signed-off-by: Paolo Bonzini
---
hw/core/machine.c | 1 +
On 03/23/2015 07:05 PM, Paolo Bonzini wrote:
Capture the explicit setting of "usb=no" into a separate bool, and
use it to skip the update of machine->usb in the board init function.
Signed-off-by: Paolo Bonzini
---
hw/core/machine.c | 1 +
hw/ppc/mac_newworld.c | 2 +-
hw/ppc/spapr.c
On Mon, 23 Mar 2015, Stefan Hajnoczi wrote:
> On Wed, Mar 18, 2015 at 02:16:47PM -0700, Yaoli Zheng wrote:
> > We have problem using qemu emulated scsi driver(the old lsi). Wonder if any
> > of other device model we can try for emulating scsi, and how we can get and
> > config it in Xen? Having b
On 23 March 2015 at 17:51, Andreas Färber wrote:
> Am 23.03.2015 um 15:39 schrieb Paolo Bonzini:
>> On 23/03/2015 13:24, Peter Maydell wrote:
>>> The point of indicating failure via MemTxResult is that at
>>> some point we need to correct the current broken handling of
>>> the CPUClass do_unassign
On 23 March 2015 at 16:56, John Snow wrote:
> The following changes since commit 3c6c9fe034c0c07b77f272e4a53d7735220a16a4:
>
> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into
> staging (2015-03-20 12:26:09 +)
>
> are available in the git repository at:
>
> https
Am 23.03.2015 um 15:39 schrieb Paolo Bonzini:
> On 23/03/2015 13:24, Peter Maydell wrote:
>> The point of indicating failure via MemTxResult is that at
>> some point we need to correct the current broken handling of
>> the CPUClass do_unassigned_access hook, because that should
>> only be invoked i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23/03/2015 18:48, Eric Blake wrote:
>> Why can't libvirt just add ,format=raw instead of leaving out the
>> format key altogether?
>
> Libvirt DOES add format=raw. This patch is an extra insurance
> policy to guarantee that libvirt does not ha
On 03/23/2015 11:23 AM, Paolo Bonzini wrote:
>
>
> On 20/03/2015 15:19, Markus Armbruster wrote:
>>> If (a working version of) this makes it in 2.3, libvirt WILL use it in
>>> the next release. It will take me less than 5 minutes to write up the
>>> libvirt patch, as long as the new option is ad
>From 9c4425d4145ac6b0a2d19a6fdf5803dd13f1fa93 Mon Sep 17 00:00:00 2001
From: Itamar Tal
Date: Mon, 23 Mar 2015 14:26:47 +0200
Subject: [PATCH] add 1394 support
This patch add 1394 (firewire) support to x86_64 and i386 qemu
softmmu. It allows one virtual machine to be the server side and the
othe
Short of generic recursive device realization, realize cores and threads
recursively.
Signed-off-by: Andreas Färber
---
hw/i386/Makefile.objs| 1 +
hw/i386/cpu-core.c | 45
hw/i386/cpu-socket.c | 45 +
Inline pc_new_cpu() for the initial setup.
Signed-off-by: Andreas Färber
---
hw/i386/pc.c | 39 ++-
include/hw/i386/cpu-core.h | 3 +++
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 492c262..ef
Signed-off-by: Andreas Färber
---
hw/cpu/Makefile.objs| 2 +-
hw/cpu/socket.c | 21 +
include/hw/cpu/socket.h | 14 ++
3 files changed, 36 insertions(+), 1 deletion(-)
create mode 100644 hw/cpu/socket.c
create mode 100644 include/hw/cpu/socket.h
dif
Hello,
This long-postponed series proposes a hierarchical QOM model of socket
and core objects for the x86 PC machines.
Background is that due to qdev limitations we had to introduce an ICC bus
to be able to hot-add CPUs and their APICs. By now this limitation could be
resolved via a QOM hotplug
Inline realized=true from pc_new_cpu() so that the realization can be
deferred, as it would otherwise create a device[n] node.
Signed-off-by: Andreas Färber
---
hw/i386/pc.c | 66
1 file changed, 58 insertions(+), 8 deletions(-)
diff
On 03/23/2015 06:05 PM, Paolo Bonzini wrote:
Capture the explicit setting of "usb=no" into a separate bool, and
use it to skip the update of machine->usb in the board init function.
Signed-off-by: Paolo Bonzini
Thanks, applied to ppc-next (for 2.3).
Alex
On 20/03/2015 15:19, Markus Armbruster wrote:
> > If (a working version of) this makes it in 2.3, libvirt WILL use it in
> > the next release. It will take me less than 5 minutes to write up the
> > libvirt patch, as long as the new option is advertised via
> > query-command-line-options (which
On 23/03/2015 11:04, Markus Armbruster wrote:
> Probing is convenient, but probing untrusted raw images is insecure
> (CVE-2008-2004). To avoid it, users should always specify raw format
> explicitly. This isn't trivial, and even sophisticated users have
> gotten it wrong (libvirt CVE-2010-2237
Capture the explicit setting of "usb=no" into a separate bool, and
use it to skip the update of machine->usb in the board init function.
Signed-off-by: Paolo Bonzini
---
hw/core/machine.c | 1 +
hw/ppc/mac_newworld.c | 2 +-
hw/ppc/spapr.c| 2 +-
include/hw/boards.h | 1 +
4 files
This adds the saving and restore of the current Multi-Processing state
of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of
potential states for x86 we only use two for ARM. Either the process is
running or not. We then save this state into the cpu_powered TCG state
to avoid chang
The current code was negatively indexing the cpu state array and not
synchronizing banked spsr register state with the current mode's spsr
state, causing occasional failures with migration.
Some munging is done to take care of the aarch64 mapping and also to
ensure the most current value of the sp
As there is logic to deal with the difference between edge and level
triggered interrupts in the kernel we must ensure it knows the
configuration of the IRQs before we restore the pending state.
Signed-off-by: Alex Bennée
Acked-by: Christoffer Dall
diff --git a/hw/intc/arm_gic_kvm.c b/hw/intc/a
For migration to work we need to sync all of the register state. This is
especially noticeable when GCC starts using FP registers as spill
registers even with integer programs.
Signed-off-by: Alex Bennée
---
v4:
- fixed merge conflicts
- rm superfluous reg.id++
v5:
- use interim float128
Hi,
Following some review comments (and a patch) from Peter I've re-spun
this series:
v5
- Added Peter's SPSR_EL1 state fix for architectural mapping
- As a result SPSR save/restore no longer does munge
- FP register save/restore re-done to deal float128 mapping
- Some minor [ spaces ] ad
From: Peter Maydell
The AArch64 SPSR_EL1 register is architecturally mandated to
be mapped to the AArch32 SPSR_svc register. This means its
state should live in QEMU's env->banked_spsr[1] field.
Correct the various places in the code that incorrectly
put it in banked_spsr[0].
Signed-off-by: Pete
I was getting very confused about the duplication of state so wanted to
make it explicit.
Signed-off-by: Alex Bennée
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 083211c..6dc1799 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -155,6 +155,11 @@ typedef struct CPUARMState {
re available in the git repository at:
>
> git://git.linaro.org/people/riku.voipio/qemu.git
> tags/pull-linux-user-20150323
>
> for you to fetch changes up to 61c7480fa36775cc2baa2f8141f0c64a15f827b5:
>
> linux
This does not bother DMA, because DMA generally transfers
the entire SGList in one shot if it can.
PIO, on the other hand, tries to transfer just one sector
at a time, and will make multiple visits to the sglist
to fetch memory addresses.
Fix the memory address calculaton when we have an offset
b
On 03/23/2015 12:56 PM, John Snow wrote:
The following changes since commit 3c6c9fe034c0c07b77f272e4a53d7735220a16a4:
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into
staging (2015-03-20 12:26:09 +)
are available in the git repository at:
https://github.c
Similar to the cmd_write_pio fix, update the nsector count and
ide sector before we invoke ide_transfer_start.
Signed-off-by: John Snow
Reviewed-by: Stefan Hajnoczi
Tested-by: Andreas Färber
Message-id: 1426811056-2202-3-git-send-email-js...@redhat.com
---
hw/ide/core.c | 8 +++-
1 file ch
My pattern was cyclical every 256 bytes, so it missed a fairly obvious
failure case. Add some rand() pepper into the test pattern, and for large
patterns that exceed 256 sectors, start writing an ID per-sector so that
we never generate identical sector patterns.
Signed-off-by: John Snow
Reviewed-
The following changes since commit 3c6c9fe034c0c07b77f272e4a53d7735220a16a4:
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into
staging (2015-03-20 12:26:09 +)
are available in the git repository at:
https://github.com/jnsnow/qemu.git tags/ide-pull-request
for y
We need to adjust the sector being written to
prior to calling ide_transfer_start, otherwise
we'll write to the same sector again.
Signed-off-by: John Snow
Reviewed-by: Stefan Hajnoczi
Tested-by: Andreas Färber
Message-id: 1426811056-2202-2-git-send-email-js...@redhat.com
---
hw/ide/core.c | 2
On 23 March 2015 at 16:30, Paolo Bonzini wrote:
> None of them does, uses of ld*_phys(cs->as, ...) are almost all in
> target-* already.
Oh good :-)
Regardless, I don't see why this means that ld*_phys should be
in cpu-common.h or cpu-all.h rather than memory.h ?
> There's just hw/ppc/spapr_hca
Hi Stefan,
On 03/23/2015 03:41 PM, Bastian Koppelmann wrote:
[snip]
The code for dvinit.b and dvinit.h is not correctly calculating the
overflow bit, but I can't figure out why, since the documentation of
the real hardware seems to be wrong. I will take your patch for now,
so the warning is
The TriCore documentation was wrong on how to calculate ovf bits for those two
instructions, which I confirmed with real hardware (TC1796 chip). An ovf
actually happens, if the result (without remainder) does not fit into 8/16 bits.
Signed-off-by: Bastian Koppelmann
---
target-tricore/op_helper.
On 03/23/2015 11:14 AM, Peter Maydell wrote:
On 23 March 2015 at 14:52, John Snow wrote:
On 03/23/2015 09:11 AM, Peter Maydell wrote:
This is really working around a bug in either ccache or
in the way Fedora has configured ccache, so I kind of
feel it ought to be dealt with there. However I
Am 23.03.2015 um 16:11 schrieb Peter Maydell:
> On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>> On 23/03/2015 13:24, Peter Maydell wrote:
>>> * cpu_physical_memory_rw are obsolete and should be replaced
>>>with uses of the as_* functions -- we should at least note
>>>this in the header
On 23/03/2015 17:00, Peter Maydell wrote:
> On 23 March 2015 at 15:47, Paolo Bonzini wrote:
>> Ok, so most ld*_phys users are already using cs->as.
>
> But this is only because when the AddressSpace* argument
> to ld*_phys was introduced we made it be cs->as for
> existing callers, to retain th
It is wrong to use address_space_memory directly, because there could be an
IOMMU in the middle. Passing the entire PVSCSIRingInfo to RS_GET_FIELD
and RS_SET_FIELD makes it easy to go back to the PVSCSIState.
Signed-off-by: Paolo Bonzini
---
hw/scsi/vmw_pvscsi.c | 42 +--
It is wrong to use address_space_memory directly, because there could be an
IOMMU in the middle.
Signed-off-by: Paolo Bonzini
---
hw/scsi/megasas.c | 51 ---
1 file changed, 24 insertions(+), 27 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scs
On 23 March 2015 at 15:47, Paolo Bonzini wrote:
> Ok, so most ld*_phys users are already using cs->as.
But this is only because when the AddressSpace* argument
to ld*_phys was introduced we made it be cs->as for
existing callers, to retain the existing behaviour.
That doesn't mean that callers us
On 23/03/2015 16:01, Peter Crosthwaite wrote:
> Note that SD has a SPI mode, every SD card is in theory a valid SSI
> device. We could unify SD under SSI to achieve both QOMification and
> busification.
That wouldn't really be the way most SD cards work, anyway. The
protocol doesn't do simultan
On 23/03/2015 15:11, Laszlo Ersek wrote:
> Depends on the exact maintainer picking up your series.
>
> ... Now good luck figuring out who that's going to be :)
>
> (I ran "scripts/get_maintainer.pl" on a squashed diff for this series.
> It named only Paolo, but for the wrong reason: "vl.c" matc
On 23/03/2015 16:29, Stefan Hajnoczi wrote:
> From: Paolo Bonzini
>
> The loop previously terminated on ffs(0) == 0, now it terminates on
> ctz32(0) + 1 == 33.
... now it terminates on level == 0.
Paolo
On 23/03/2015 16:39, Peter Maydell wrote:
> > Not necessarily, for example PCI devices can certainly
> > use the short name.
>
> PCI devices should all be using ld*_pci_dma and st*_pci_dma
> so they go through the correct address space for the PCIDevice.
> Any PCI device making direct calls to ld
在 2015年03月23日 20:06, Paolo Bonzini 写道:
On 23/03/2015 11:36, Peter Crosthwaite wrote:
I don't think TypeInfo is the right place for this. You can however
define function hooks for Object in ObjectClass. See the unparent
field of ObjectClass for a precedent.
In this case, the right place could
1 - 100 of 292 matches
Mail list logo
