Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN,
but there is 0 bytes available and recvfrom could be blocking indefinitely.
This is likely due to 0-length udp payload. This also adds an error
checking for ioctlsocket.
Signed-off-by: Vic Lee
---
slirp/socket.c | 10 +
On Mon, 28 Jan 2019 11:05:45 +
Shameer Kolothum wrote:
> pc-dimm memory hotplug is enabled using GPIO(Pin 2) based ACPI
> event. Hot removal functionality is not yet supported.
>
> Signed-off-by: Shameer Kolothum
> ---
> hw/arm/virt.c | 57 ++
Philippe Mathieu-Daudé writes:
> Hi Alex,
>
> On 2/28/19 9:25 PM, Alex Bennée wrote:
>> The compilation flags for proper building are in the source tree. We
>> also fix exit to 0 so the result is counted as a success.
>>
>> Signed-off-by: Alex Bennée
>> ---
>> tests/tcg/mips/Makefile.target |
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: 01 March 2019 09:12
> To: Shameerali Kolothum Thodi
> Cc: eric.au...@redhat.com; shannon.zha...@gmail.com;
> peter.mayd...@linaro.org; qemu-devel@nongnu.org; qemu-...@nongnu.org;
> Linuxarm ; xuwei (O)
> Su
On Fri, 1 Mar 2019 15:44:48 +0800
Wei Yang wrote:
> Here is the abstraction of current call flow of object_new_with_type()
>
> object_initialize_with_type
> type_initialize
> object_initialize_with_type
> type_initialize
>
> This is not necessary to spread type_init
[This is the Linux kernel part, git tree is available at
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git
vfio-ccw-eagain-caps-v3
The companion QEMU patches are available at
https://github.com/cohuck/qemu vfio-ccw-caps]
Currently, vfio-ccw only relays START SUBCHANNEL request
Introduce a mutex to disallow concurrent reads or writes to the
I/O region. This makes sure that the data the kernel or user
space see is always consistent.
The same mutex will be used to protect the async region as well.
Reviewed-by: Eric Farman
Signed-off-by: Cornelia Huck
---
drivers/s390/c
When we get a solicited interrupt, the start function may have
been cleared by a csch, but we still have a channel program
structure allocated. Make it safe to call the cp accessors in
any case, so we can call them unconditionally.
While at it, also make sure that functions called from other parts
The vfio-ccw code will need this, and it matches treatment of ssch
and csch.
Reviewed-by: Pierre Morel
Reviewed-by: Halil Pasic
Signed-off-by: Cornelia Huck
---
drivers/s390/cio/ioasm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/s390/cio/ioasm.c b/drivers/s390/cio/ioasm.c
inde
Add a region to the vfio-ccw device that can be used to submit
asynchronous I/O instructions. ssch continues to be handled by the
existing I/O region; the new region handles hsch and csch.
Interrupt status continues to be reported through the same channels
as for ssch.
Signed-off-by: Cornelia Huc
The flow for processing ssch requests can be improved by splitting
the BUSY state:
- CP_PROCESSING: We reject any user space requests while we are in
the process of translating a channel program and submitting it to
the hardware. Use -EAGAIN to signal user space that it should
retry the requ
Build fails with gcc 9:
CC slirp/ndp_table.o
slirp/ndp_table.c: In function ‘ndp_table_add’:
slirp/ndp_table.c:31:23: error: taking address of packed member of ‘struct
ndpentry’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
31 | if (in6_equal(&ndp_
[This is the QEMU part, git tree is available at
https://github.com/cohuck/qemu vfio-ccw-caps
The companion Linux kernel patches are available at
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git
vfio-ccw-eagain-caps-v4]
Currently, vfio-ccw only relays START SUBCHANNEL request
To be replaced with a real linux-headers update.
Signed-off-by: Cornelia Huck
---
linux-headers/linux/vfio.h | 4
linux-headers/linux/vfio_ccw.h | 12
2 files changed, 16 insertions(+)
diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index 12a7b1dc53c8
Allow to extend the regions used by vfio-ccw. The first user will be
handling of halt and clear subchannel.
Signed-off-by: Cornelia Huck
---
drivers/s390/cio/vfio_ccw_ops.c | 186
drivers/s390/cio/vfio_ccw_private.h | 38 ++
include/uapi/linux/vfio.h
Hi Igor,
On 2/28/19 5:19 PM, Igor Mammedov wrote:
> On Thu, 28 Feb 2019 16:03:22 +0100
> Eric Auger wrote:
>
>> This patch implements the machine class kvm_type() callback.
>> It returns the number of bits requested to implement the whole GPA
>> range including the RAM and IO regions located bey
A vfio-ccw device may provide an async command subregion for
issuing halt/clear subchannel requests. If it is present, use
it for sending halt/clear request to the device; if not, fall
back to emulation (as done today).
Signed-off-by: Cornelia Huck
---
hw/s390x/css.c | 27 +++--
On Thu, 28 Feb 2019 at 21:53, G 3 wrote:
> On Mon, Feb 25, 2019 at 5:24 AM Peter Maydell
> wrote:
>> +// Utility function to run specified code block with iothread lock held
>> +typedef void (^CodeBlock)(void);
>
>
> Please don't use blocks. It would lock Mac OS X users into having to use
> CLa
On Fri, 1 Mar 2019 at 09:39, Greg Kurz wrote:
>
> Build fails with gcc 9:
>
> CC slirp/ndp_table.o
> slirp/ndp_table.c: In function ‘ndp_table_add’:
> slirp/ndp_table.c:31:23: error: taking address of packed member of ‘struct
> ndpentry’ may result in an unaligned pointer value
> [-Werror
On Thu, 28 Feb 2019 at 22:10, Max Filippov wrote:
>
> Hi Peter,
>
> please pull the following batch of target/xtensa updates.
> Changes v1->v2:
> - fix build with clang.
>
> The following changes since commit 1c3d45df5e94042d5fb2bb31416072563ab30e49:
>
> Merge remote-tracking branch 'remotes/eri
On Fri, Mar 01, 2019 at 10:01:46AM +0800, Wei Yang wrote:
> We didn't specify the indent rule for multiline code here, which may
> mislead users. And in current code, the code use various styles.
>
> Add this rule in CODING_STYLE to make sure this is clear to every one.
>
> Signed-off-by: Wei Yan
From: Aleksandar Markovic
Add Citrix, Huawei, Intel, and Microsoft to domain-map.
Signed-off-by: Aleksandar Markovic
[AJB: sorted, added Fujitsu]
Signed-off-by: Alex Bennée
---
contrib/gitdm/domain-map | 5 +
1 file changed, 5 insertions(+)
diff --git a/contrib/gitdm/domain-map b/contrib
Hi,
I misidentified a bunch of individual contributors as academics in the
last series so I've fixed that now. I've also added Janus Technologies
for Marcus. If everyone is happy with these changes I'll send in the
PR.
The following patches need review
patch 0003/contrib gitdm add more individua
Currently this just includes Marcel who is a fairly prolific
contributor.
Cc: Marcel Apfelbaum
Signed-off-by: Alex Bennée
---
contrib/gitdm/group-map-janustech | 5 +
gitdm.config | 1 +
2 files changed, 6 insertions(+)
create mode 100644 contrib/gitdm/group-map-janust
Based on Tom's LinkedIn profile his QEMU work was while in IBM's
virtualisation group.
Reviewed-by: Tom Musta
Signed-off-by: Alex Bennée
---
contrib/gitdm/group-map-ibm | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/gitdm/group-map-ibm b/contrib/gitdm/group-map-ibm
index 22727319b3
From: Aleksandar Markovic
Add all missing MIPS/Imgtec/Wave contributors (from the inception of
QEMU).
Signed-off-by: Aleksandar Markovic
Signed-off-by: Alex Bennée
---
contrib/gitdm/group-map-wavecomp | 12
1 file changed, 12 insertions(+)
diff --git a/contrib/gitdm/group-map-wa
I know Richard's is right because I asked him in the pub. I'm guessing
Fredrik's based on the fact I vaguely remember an Atari demo. The
others I attributed to academic institutions last time I posted so
have moved them to individuals as requested.
Cc: Richard Henderson
Cc: Fredrik Noring
Cc: Sa
Hi Igor,
On 2/28/19 5:29 PM, Igor Mammedov wrote:
> On Thu, 28 Feb 2019 16:03:24 +0100
> Eric Auger wrote:
>
>> Now we have the extended memory map (high IO regions beyond the
>> scalable RAM) and dynamic IPA range support at KVM/ARM level
>> we can bump the legacy 255GB initial RAM limit. The a
* Peter Xu (pet...@redhat.com) wrote:
> On Thu, Feb 28, 2019 at 12:28:22PM +, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Thu, Feb 28, 2019 at 11:40:19AM +, Dr. David Alan Gilbert wrote:
> > > > * Peter Xu (pet...@redhat.com) wrote:
> > > > >
On Wed, 20 Feb 2019 19:57:34 -0500
Cleber Rosa wrote:
> Even when the launch of QEMU succeeds, it's useful to have the command
> line recorded.
>
> Signed-off-by: Cleber Rosa
> Reviewed-by: Caio Carrara
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Alex Bennée
> ---
> scripts/qemu.py
On Wed, 20 Feb 2019 19:57:35 -0500
Cleber Rosa wrote:
> The current version of the "check-acceptance" target will only show
> one line for execution of all tests. That's probably OK if the tests
> to be run are quick enough and they're always the same.
>
> But, there's already one test alone th
On Wed, 20 Feb 2019 19:57:36 -0500
Cleber Rosa wrote:
> Making it clear what is returned by this utility function.
>
> Signed-off-by: Cleber Rosa
> Reviewed-by: Caio Carrara
> Reviewed-by: Philippe Mathieu-Daudé
> ---
> tests/acceptance/avocado_qemu/__init__.py | 4
> 1 file changed, 4
On Wed, 20 Feb 2019 19:57:37 -0500
Cleber Rosa wrote:
> The "this directory" reference is misleading and confusing, it's a
> leftover from when this text was proposed in a README file inside
> the "tests/acceptance/avocado_qemu" directory.
>
> When that text was moved to the top level docs direc
Public bug reported:
The issue is observed on aarch64 (I didn't check x86) with latest
upstream QEMU bits.
Steps to reproduce:
1) start guest
2) suspend guest with this command:
# echo mem > /sys/power/state
Check console messages, which should indicate that guest has been
suspended.
3) ch
On Fri, 1 Mar 2019 09:23:11 +
Shameerali Kolothum Thodi wrote:
> > -Original Message-
> > From: Igor Mammedov [mailto:imamm...@redhat.com]
> > Sent: 01 March 2019 09:12
> > To: Shameerali Kolothum Thodi
> > Cc: eric.au...@redhat.com; shannon.zha...@gmail.com;
> > peter.mayd...@linaro
On Wed, 20 Feb 2019 19:57:38 -0500
Cleber Rosa wrote:
> It's useful to define the architecture that should be used in
> situations such as:
> * the intended target of the QEMU binary to be used on tests
> * the architecture of code to be run within the QEMU binary, such
>as a kernel image o
On Fri, 1 Mar 2019 11:08:17 +0100
Auger Eric wrote:
> Hi Igor,
>
> On 2/28/19 5:29 PM, Igor Mammedov wrote:
> > On Thu, 28 Feb 2019 16:03:24 +0100
> > Eric Auger wrote:
> >
> >> Now we have the extended memory map (high IO regions beyond the
> >> scalable RAM) and dynamic IPA range support a
On 01.03.19 02:31, Michael Roth wrote:
> Quoting Thomas Huth (2019-02-28 12:40:52)
>> On 26/02/2019 05.52, David Gibson wrote:
>>> From: Michael Roth
>>>
>>> Extend the existing EPOW event format we use for PCI
>>> devices to emit PHB plug/unplug events.
>>>
>>> Signed-off-by: Michael Roth
>>> Re
On Wed, 20 Feb 2019 19:57:39 -0500
Cleber Rosa wrote:
> Currently, the only test that contains some target architecture
> information is "boot_linux_console.py" which test contains a "x86_64"
But there are two others changed by you here, aren't there?
> tag. But that tag is not respected in th
On Fri, 1 Mar 2019 11:26:35 +0100
Igor Mammedov wrote:
> On Fri, 1 Mar 2019 09:23:11 +
> Shameerali Kolothum Thodi wrote:
>
> > > -Original Message-
> > > From: Igor Mammedov [mailto:imamm...@redhat.com]
> > > Sent: 01 March 2019 09:12
> > > To: Shameerali Kolothum Thodi
> > > Cc:
On Wed, 20 Feb 2019 19:57:40 -0500
Cleber Rosa wrote:
> A test can, optionally, be tagged for one or many architectures. If a
> test has been tagged for a single architecture, there's a high chance
> that the test won't run on other architectures. This changes the
> default order of choosing a
On Thu, 28 Feb 2019 at 12:28, Thomas Huth wrote:
>
> Hi Peter,
>
> the following changes since commit adf2e451f357e993f173ba9b4176dbf3e65fee7e:
>
> Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
> (2019-02-26 19:04:47 +)
>
> are available in the git repository
On Wed, 20 Feb 2019 19:57:41 -0500
Cleber Rosa wrote:
> Given that the test is specific to x86_64 and pc, and new tests are
> going to be added to the same class, let's rename it accordingly.
> Also, let's make the class documentation not architecture specific.
>
> Signed-off-by: Cleber Rosa
>
On Thu, 14 Feb 2019 16:16:19 +0800
Stefan Hajnoczi wrote:
> On Thu, Feb 14, 2019 at 03:26:29PM +0800, Wei Yang wrote:
> > Maybe change the title
> >
> >s/hotmem/hostmem-file/
> >
> > would be more proper.
> >
> > I missed this in previous review.
>
> You're right. This can be fixed wh
On Wed, 20 Feb 2019 19:57:42 -0500
Cleber Rosa wrote:
> To the stock Fedora 29 kernel, from the Fedora 28. New tests will be
> added using the 29 kernel, so for consistency, let's also update it
> here.
>
> Signed-off-by: Cleber Rosa
> Reviewed-by: Caio Carrara
> ---
> tests/acceptance/boot_
On Wed, 20 Feb 2019 19:57:43 -0500
Cleber Rosa wrote:
> The 'printk.time=0' option makes it easier to parse the console
> output. Let's set it as a default, and reusable, kernel command line
> options for this and future similar tests.
>
> Signed-off-by: Cleber Rosa
> Reviewed-by: Philippe Mat
On Fri, 1 Mar 2019 10:28:30 +0800
Heyi Guo wrote:
> After the introduction of generic PCIe root port and PCIe-PCI bridge,
> we will also have SHPC controller on ARM, so just enalbe SHPC native
> hot plug.
Just out of curiosity,
An understand the need for SHPC on plain PCI but in case of PCIe
why
On Wed, 20 Feb 2019 19:57:44 -0500
Cleber Rosa wrote:
> When running on very low powered environments, some tests may time out
> causing false negatives. As a conservative change, and for
> considering that human time (investigating false negatives) is worth
> more than some extra machine cycles
On Wed, 20 Feb 2019 19:57:45 -0500
Cleber Rosa wrote:
> This introduces a utility method that monitors the console device and
> looks for either a message that signals the test success or failure.
>
> Signed-off-by: Cleber Rosa
> Reviewed-by: Caio Carrara
> Reviewed-by: Philippe Mathieu-Daudé
On Fri, 1 Mar 2019 11:30:18 +0100
David Hildenbrand wrote:
> On 01.03.19 02:31, Michael Roth wrote:
> > Quoting Thomas Huth (2019-02-28 12:40:52)
> >> On 26/02/2019 05.52, David Gibson wrote:
> >>> From: Michael Roth
> >>>
> >>> Extend the existing EPOW event format we use for PCI
> >>> devi
On 01/03/2019 11.48, Greg Kurz wrote:
> On Fri, 1 Mar 2019 11:30:18 +0100
> David Hildenbrand wrote:
>
>> On 01.03.19 02:31, Michael Roth wrote:
>>> Quoting Thomas Huth (2019-02-28 12:40:52)
On 26/02/2019 05.52, David Gibson wrote:
> From: Michael Roth
>
> Extend the existin
> -Original Message-
> From: Qemu-devel
> [mailto:qemu-devel-bounces+shameerali.kolothum.thodi=huawei.com@nongn
> u.org] On Behalf Of Igor Mammedov
> Sent: 01 March 2019 10:34
> To: Shameerali Kolothum Thodi
> Cc: peter.mayd...@linaro.org; shannon.zha...@gmail.com;
> qemu-devel@nongnu.o
On Wed, 20 Feb 2019 19:57:46 -0500
Cleber Rosa wrote:
> The set_console() utility function traditionally adds a device either
> based on the explicitly given device type, or based on the machine type,
> a known good type of device.
Hm, I find this sentence hard to parse... maybe it should be "ei
On Thu, 28 Feb 2019 at 17:34, Anthony PERARD wrote:
>
> The following changes since commit 711d13d5e2e160c1c3bcbd302af6df3980a99469:
>
> Merge remote-tracking branch
> 'remotes/amarkovic/tags/mips-queue-feb-27-2019' into staging (2019-02-28
> 12:59:49 +)
>
> are available in the Git reposi
On 25/02/2019 19.31, Laszlo Ersek wrote:
> Hi Thomas,
>
> On 02/25/19 17:14, Thomas Huth wrote:
>> The global boot_splash_filedata and boot_splash_filedata_size variables
>> are only used in fw_cfg.c. So there is really no need that these need
>> to be global and reside in vl.c. Move them to fw_cf
On 2019/3/1 18:44, Igor Mammedov wrote:
On Fri, 1 Mar 2019 10:28:30 +0800
Heyi Guo wrote:
After the introduction of generic PCIe root port and PCIe-PCI bridge,
we will also have SHPC controller on ARM, so just enalbe SHPC native
hot plug.
Just out of curiosity,
An understand the need for S
On Mon, 25 Feb 2019 at 10:49, Damien Hedde wrote:
> I had more thought about the reset problem and what we want to achieve
> (add power gating and clock support).
> Feel free to comment. I'll start to implement this and send a first
> version with a reroll of everything when it's ready.
I general
Am 28.02.2019 um 19:36 hat Sergio Lopez geschrieben:
> On Thu, Feb 28, 2019 at 06:22:02PM +0100, Kevin Wolf wrote:
> > Am 28.02.2019 um 18:04 hat Sergio Lopez geschrieben:
> > > On Thu, Feb 28, 2019 at 04:50:53PM +0100, Kevin Wolf wrote:
> > > > Am 28.02.2019 um 16:01 hat Sergio Lopez geschrieben:
This is the first part of vector instruction support for s390x. Parts
will be sent and reviewed piece by piece.
Part 1: Vector Support Instructions
Part 2: Vector Integer Instructions
Part 3: Vector String Instructions
Part 4: Vector Floating-Point Instructions
The current state can be found at (
These are the new instruction formats related to vector instructions as
up to the z14 (a.k.a. latest PoP).
As v2 appeares (like x2 in VRX) with d2/b2 in VRV, we have to assign it a
higher field number to avoid collisions.
Properly take care of the MSB (to be able to address 32 registers) for
each
Check them at a central point. We'll use a new instruction flag to
flag all vector instructions (IF_VEC) and handle it very similar to
AFP, whereby we use another unused position in the PSW mask to store
the state of vector register enablement per translation block.
Reviewed-by: Richard Henderson
Let's optimize it for the common cases (setting a vector to zero or all
ones) - courtesy of Richard.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate.c| 1 +
target/s390x/translate_vx.inc.c | 39 +
3 fil
When loading from memory, load both elements into temps first before
modifying the target vector
Loading with strange alingment from the end of the address space will
not properly wrap, we can ignore that for now.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 3 +++
ta
Fairly easy, load with desired size and store it into the right element.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 5 +
target/s390x/translate_vx.inc.c | 18 ++
2 files changed, 23 insertions(+)
diff --git a/targe
Let's start with a more involved one, but it is the first in the list
of vector support instructions (introduced with the vector facility).
Good thing is, we need a lot of basic infrastructure for this. Reading
and writing vector elements as well as checking element validity.
All vector instructi
Add gen_gvec_dupi() for handling duplication of immediates, so it can
be reused later.
Reviewed-by: Richard Henderson
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 47 +
2 files changed, 49 insertions(+)
diff --git a/target/s390x/
We'll have to read/write vector elements quite frequently from helpers.
The tricky bit is properly taking care of endianess. Handle it similar
to aarch64.
target/s390x/vec_helper.c will later also contain vector support
instruction helpers.
Signed-off-by: David Hildenbrand
---
target/s390x/Make
Take care of properly sign-extending the immediate.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 5 +
target/s390x/translate_vx.inc.c | 17 +
2 files changed, 22 insertions(+)
diff --git a/target/s390x/insn-data.def
Fairly easy, just load from to gprs into a single vector.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s
Fairly easy, zero out the vector before we load the desired element.
Load the element before touching the vector.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 46 +
2 files changed, 48 insertions(+
To avoid an helper, we have to do the actual calculation of the element
address (offset in cpu_env + cpu_env) manually. Factor that out into
get_vec_element_ptr_i64(). The same logic will be reused for "VECTOR
LOAD VR ELEMENT FROM GR".
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.
We cannot use gvec expansion as source and destination elements are
have different element numbers. So we'll expand using a fancy loop.
Also, we have to take care of overlapping source and destination
registers, therefore use a safe evaluation irder depending on the
operation.
Signed-off-by: David
Try to load the last element first. Access to the first element will
be checked afterwards. This way, we can guarantee that the vector is
not modified before we checked for all possible exceptions. (16 vectors
cannot cross more than two pages)
Reviewed-by: Richard Henderson
Signed-off-by: David H
We can use tcg_gen_gvec_dup_i64() to carry out the duplication.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 19 +++
2 files changed, 21 insertions(+)
diff --git a/target/s390x/ins
Take care of overlying inputs and outputs by using a temporary vector.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 1 +
target/s390x/translate_vx.inc.c | 12
target/s390x/vec_helper.c
Very similar to VECTOR LOAD GR FROM VR ELEMENT, just the opposite
direction. Also provide a fast path in case we don't care about the
register content.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c |
Very similar to LOAD COUNT TO BLOCK BOUNDARY, but instead of only
calculating, the actual vector is loaded. Use a temporary vector to
not modify the real vector on exceptions. Initialize that one to zero,
to not leak any data. Provide a fast path if we're loading a full
vector.
As we don't have gv
We can reuse the helper introduced along with VECTOR LOAD TO BLOCK
BOUNDARY. We just have to take care of converting the highest index into
a length.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate.c| 7
Read the whole input before modifying the destination vector.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 16
2 files changed, 18 insertions(+)
diff --git a/target/s390x/insn-dat
Provide an implementation based on i64 and on real host vectors.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 41 +
2 files changed, 43 insertions(+)
diff --git a/target/s390x/insn-data.def b/targ
Similar to VECTOR LOAD MULTIPLE, just the opposite direction. Probe
write access first.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 30 ++
2 files changed, 32 insertion
This is a big one. Luckily we only have a limited set of such nasty
instructions.
We'll implement all variants with helpers, except when sorces and
destinations don't overlap for VECTOR PACK. Provide different helpers
when the cc is to be modified. We'll return the cc then via env->cc_op.
Signed-
Load the element and replicate it using gvec_dup.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 18 ++
2 files changed, 20 insertions(+)
diff --git a/target/s390x/insn-data.def b/ta
Instead of checking e.g. the first access on every touched page, we should
check the actual access, otherwise we might get false positives when Low
Address Protection (LAP) is active. As probe_write() can only deal with
accesses to one page, we have to loop.
Use i64 for the length, although not ne
Like VECTOR REPLICATE, but the element to be replicated comes from an
immediate.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 14 ++
2 files changed, 16 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/
Properly probe the whole access first.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 17 +
2 files changed, 19 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s390x/i
As we only store one element, there is nothing to consider regarding
exceptions.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 5 +
target/s390x/translate_vx.inc.c | 18 ++
2 files changed, 23 insertions(+)
diff --git
Similar to VECTOR GATHER ELEMENT, but the other direction.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 3 +++
target/s390x/translate_vx.inc.c | 22 ++
2 files changed, 25 insertions(+)
diff --git a/target/s390x/insn
Very similar to VECTOR LOAD WITH LENGTH, just the opposite direction.
Properly probe write access before modifying memory.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 2 ++
target/s390x/translate_
Load both elements signed and store them into the two 64 bit elements.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 33 +
2 files changed, 35 insertions(+)
diff --g
Combine all variant in a single handler. As source and destination
have different element sizes, we can't use gvec expansion. Expand
manually. Also watch out for overlapping source and destination
registers. Use a safe evaluation order depending on the operation.
Reviewed-by: Richard Henderson
Si
On Fri, 1 Mar 2019 11:49:30 +0100
Thomas Huth wrote:
> On 01/03/2019 11.48, Greg Kurz wrote:
> > On Fri, 1 Mar 2019 11:30:18 +0100
> > David Hildenbrand wrote:
> >
> >> On 01.03.19 02:31, Michael Roth wrote:
> >>> Quoting Thomas Huth (2019-02-28 12:40:52)
> On 26/02/2019 05.52, Dav
On Tue 12 Feb 2019 07:02:31 PM CET, Kevin Wolf wrote:
>> diff --git a/include/block/block_int.h b/include/block/block_int.h
>> index fd0e88d17a..e680dda86b 100644
>> --- a/include/block/block_int.h
>> +++ b/include/block/block_int.h
>> @@ -345,6 +345,13 @@ struct BlockDriver {
>>
>> /* List
iotest 235 currently only works with KVM - this is bad for systems where
it is not available, e.g. CI pipelines. The test also works when using
"tcg" as accelerator, so we can simply add that to the list of accelerators,
too. But still, there might be the case that someone compiled their
QEMU with
Am 01.03.2019 um 13:12 hat Alberto Garcia geschrieben:
> On Tue 12 Feb 2019 07:02:31 PM CET, Kevin Wolf wrote:
> >> diff --git a/include/block/block_int.h b/include/block/block_int.h
> >> index fd0e88d17a..e680dda86b 100644
> >> --- a/include/block/block_int.h
> >> +++ b/include/block/block_int.h
>
Patchew URL: https://patchew.org/QEMU/20190301115413.27153-1-da...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190301115413.27153-1-da...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/32] s390x/tcg: Vector Instructi
On Fri 01 Mar 2019 01:36:08 PM CET, Kevin Wolf wrote:
> Am 01.03.2019 um 13:12 hat Alberto Garcia geschrieben:
>> On Tue 12 Feb 2019 07:02:31 PM CET, Kevin Wolf wrote:
>> >> diff --git a/include/block/block_int.h b/include/block/block_int.h
>> >> index fd0e88d17a..e680dda86b 100644
>> >> --- a/incl
Hi Thomas,
On 3/1/19 12:28 PM, Thomas Huth wrote:
> On 25/02/2019 19.31, Laszlo Ersek wrote:
>> Hi Thomas,
>>
>> On 02/25/19 17:14, Thomas Huth wrote:
>>> The global boot_splash_filedata and boot_splash_filedata_size variables
>>> are only used in fw_cfg.c. So there is really no need that these ne
On 01/03/2019 13.32, Philippe Mathieu-Daudé wrote:
> Hi Thomas,
>
> On 3/1/19 12:28 PM, Thomas Huth wrote:
>> On 25/02/2019 19.31, Laszlo Ersek wrote:
>>> Hi Thomas,
>>>
>>> On 02/25/19 17:14, Thomas Huth wrote:
The global boot_splash_filedata and boot_splash_filedata_size variables
are
On Fri, Mar 01, 2019 at 08:17:02AM +0100, Markus Armbruster wrote:
> Marcel Apfelbaum writes:
>
> > Hi Yuval,
> >
> > On 2/27/19 4:06 PM, Yuval Shaia wrote:
> >> Allow interrogating device internals through HMP interface.
> >> The exposed indicators can be used for troubleshooting by developers o
1 - 100 of 366 matches
Mail list logo
