From: Marc-André Lureau
This command is no longer needed, the schema has compile-time
configuration conditions.
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
Signed-off-by: Markus Armbruster
Message-Id: <20190214152251.2073-16-arm...@redhat.com>
---
include/qapi/qmp/dispatc
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
Acked-by: Cornelia Huck
Reviewed-by: Markus Armbruster
Signed-off-by: Markus Armbruster
Message-Id: <20190214152251.2073-12-arm...@redhat.com>
---
qapi/target.json | 6 ++
1 file changed, 6 insertions(+)
diff --git a/qapi/target.j
We generate code for built-ins and sub-modules into separate files
since commit cdb6610ae42 and 252dc3105fc (v2.12.0). Both commits
neglected to update documentation. Do that now.
Signed-off-by: Markus Armbruster
Reviewed-by: Marc-André Lureau
Message-Id: <20190214152251.2073-2-arm...@redhat.c
This reverts commit 7bd263490590ee6fcf34ecb6203437e22f6e5a9c.
The commit applied the events' conditions to the members of enum
QAPIEvent. Awkward, because it renders QAPIEvent unusable in
target-independent code as soon as we make an event target-dependent.
Reverting this has the following effect
The following changes since commit 1e36232994c8ad01774501d2e299deba3a2469af:
Merge remote-tracking branch 'remotes/mcayland/tags/qemu-openbios-20190215'
into staging (2019-02-15 11:12:14 +)
are available in the Git repository at:
git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2019-02-1
query-events doesn't reflect compile-time configuration. Instead of
fixing that, deprecate the command in favor of query-qmp-schema.
Libvirt prefers query-qmp-schema as of commit 22d7222ec0 "qemu: caps:
Don't call 'query-events' when we probe events from QMP schema".
It'll be in the next release.
Having to include qapi-events.h just for QAPIEvent is suboptimal, but
quite tolerable now. It'll become problematic when we have events
conditional on the target, because then qapi-events.h won't be usable
from target-independent code anymore. Avoid that by generating it
into separate files.
Sig
This function is useful to fix the endianness of struct
virtio_blk_discard_write_zeroes headers.
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/tests/virtio-blk-test.c b/tests/virtio-blk-t
Starting from DISABLE and WRITE_ZEROES features, we use an array of
VirtIOFeature (as virtio-net) to properly set the config size
depending on the features enabled.
Signed-off-by: Stefano Garzarella
---
hw/block/virtio-blk.c | 31 +--
include/hw/virtio/virtio
Signed-off-by: Markus Armbruster
Reviewed-by: Marc-André Lureau
Message-Id: <20190214152251.2073-3-arm...@redhat.com>
---
docs/devel/qapi-code-gen.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index b91bde647c..c9ba8ddb2e 10
We can't add appropriate target-specific conditionals to misc.json,
because that would make all of misc.json unusable in
target-independent code. To keep misc.json target-independent, we
need to split off target-dependent target.json.
This commit doesn't actually split off anything, it merely cre
This patch adds the support of DISCARD and WRITE_ZEROES commands,
that have been introduced in the virtio-blk protocol to have
better performance when using SSD backend.
We support only one segment per request since multiple segments
are not widely used and there are no userspace APIs that allow
a
In order to use VirtIOFeature also in other virtio devices, we move
its declaration and the endof() macro (renamed in virtio_endof())
in virtio.h.
We add virtio_feature_get_config_size() function to iterate the array
of VirtIOFeature and to return the config size depending on the
features enabled.
In order to avoid migration issues, we enable DISCARD and
WRITE_ZEROES features only for machine type >= 4.0
As discussed with Michael S. Tsirkin and Stefan Hajnoczi on the
list [1], DISCARD operation should not have security implications
(eg. page cache attacks), so we can enable it by default.
The size of data in the virtio_blk_request must be a multiple
of 512 bytes for IN and OUT requests, or a multiple of the size
of struct virtio_blk_discard_write_zeroes for DISCARD and
WRITE_ZEROES requests.
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Thomas Huth
Si
Since configurable features for virtio-blk are growing, this patch
adds host_features field in the struct VirtIOBlock. (as in virtio-net)
In this way, we can avoid to add new fields for new properties and
we can directly set VIRTIO_BLK_F* flags in the host_features.
We update "config-wce" and "scs
This series adds the support of DISCARD and WRITE_ZEROES commands
and extends the virtio-blk-test to test these new commands.
v5:
- rebased on master
- handled the config size for DISCARD and WRITE_ZEROES features as in
virtio-net (patches 4 and 5) [Michael, Stefan]
- fixed an endianness issues
We add acct_failed param in order to use virtio_blk_handle_rw_error()
also when is not required to call block_acct_failed(). (eg. a discard
operation is failed)
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
---
hw/block/virtio-blk.c | 10 ++-
14.02.2019 2:23, John Snow wrote:
> "Frozen" was a good description a long time ago, but it isn't adequate now.
> Rename the frozen predicate to has_successor to make the semantics of the
> predicate more clear to outside callers.
>
> In the process, remove some calls to frozen() that no longer se
On Mon, 18 Feb 2019 13:21:29 +
Wei Yang wrote:
> On Mon, Feb 18, 2019 at 01:56:02PM +0100, Igor Mammedov wrote:
> >On Mon, 18 Feb 2019 12:13:24 +
> >Wei Yang wrote:
> >
> >> On Mon, Feb 18, 2019 at 10:50:34AM +0100, Igor Mammedov wrote:
> >> >On Mon, 18 Feb 2019 09:13:33 +0800
> >> >Wei
On 18/02/2019 07.07, Stephen Checkoway wrote:
> Hi all,
>
> I've been working on some improvements to the pflash_cfi02 block device
> (interleaved flash devices similar to pflash_cfi01, multi-sector erase,
> nonuniform sector sizes, and some bug fixes and I'm planning on implementing
> sector e
On Thu 14 Feb 2019 04:52:52 PM CET, Kevin Wolf wrote:
> Am 14.02.2019 um 15:13 hat Alberto Garcia geschrieben:
>> On Tue 12 Feb 2019 03:47:47 PM CET, Kevin Wolf wrote:
>> > Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
>> >> @@ -3861,6 +3923,10 @@ int bdrv_drop_intermediate(BlockDriverStat
Patchew URL: https://patchew.org/QEMU/20190218125615.18970-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190218125615.18970-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH 00/10] pflash: Fixes and cleanups
T
Patchew URL: https://patchew.org/QEMU/2019021853.22681-1-coh...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 2019021853.22681-1-coh...@redhat.com
Subject: [Qemu-devel] [PULL 00/10] s390x update
Type: series
==
14.02.2019 2:23, John Snow wrote:
> The current API allows us to report a single status, which we've defined as:
>
> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
> Locked: no successor, qmp_locked. may or may not be enabled.
> Disabled: Not frozen or locked, disabled.
Thank you for replying.
The error was in the underlying filesystem. I had to setup new servers.
Alex
Am 18.02.19 um 10:51 schrieb Kevin Wolf:
> Am 17.02.2019 um 05:13 hat Alexander Marx geschrieben:
>> Dear List!
>>
>> I have a big problem and hope you can help me.
>> I built a new windows 2016
Hi all,
I've been working on some improvements to the pflash_cfi02 block device
(interleaved flash devices similar to pflash_cfi01, multi-sector erase,
nonuniform sector sizes, and some bug fixes and I'm planning on implementing
sector erase suspend/resume commands in the near future).
There a
On Mon, Feb 18, 2019 at 01:56:02PM +0100, Igor Mammedov wrote:
>On Mon, 18 Feb 2019 12:13:24 +
>Wei Yang wrote:
>
>> On Mon, Feb 18, 2019 at 10:50:34AM +0100, Igor Mammedov wrote:
>> >On Mon, 18 Feb 2019 09:13:33 +0800
>> >Wei Yang wrote:
>> >
>> >> Currently we do device realization like bel
Patchew URL: https://patchew.org/QEMU/2019021853.22681-1-coh...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 2019021853.22681-1-coh...@redhat.com
Subject: [Qemu-devel] [PULL 00/10] s390x update
Type: series
==
On Mon, 18 Feb 2019 11:52:18 +
Daniel P. Berrangé wrote:
> On Mon, Feb 18, 2019 at 12:38:11PM +0100, Greg Kurz wrote:
> > On Mon, 18 Feb 2019 15:42:18 +0530
> > P J P wrote:
> >
> > > From: Prasad J Pandit
> > >
> > > On ppc hosts, hypervisor shares following system attributes
> > >
>
QOMification left parameter @size unused in pflash_cfi01_register()
and pflash_cfi02_register(). register(). Obviously, @size should
match @sector_len and @nb_blocs, i.e. size == sector_len * nb_blocs.
All callers satisfy this.
Remove @nb_blocs and compute it from @size and @sector_len.
Signed-
pflash_cfi01_register() creates a TYPE_CFI_PFLASH01 device, sets
properties, realizes, and wires up.
We have three modified copies of it, because their users need to set
additional properties, or have the wiring done differently.
Factor out their common part into pflash_cfi01_create().
Signed-of
pflash_cfi02_register() takes a size in bytes, a block size in bytes
and a number of blocks. r2d_init() passes FLASH_SIZE, 16 * KiB,
FLASH_SIZE >> 16. Does not compute: size doesn't match block size *
number of blocks. The latter happens to win. I tried to find
documentation on the physcial har
QOMification left parameter @qdev unused in pflash_cfi01_register()
and pflash_cfi02_register(). All callers pass NULL. Remove.
Signed-off-by: Markus Armbruster
---
hw/arm/collie.c | 4 ++--
hw/arm/digic_boards.c| 2 +-
hw/arm/gumstix.c
We have two open-coded copies of macro CFI_PFLASH01(). Move the macro
to the header, so we can ditch the copies. Move CFI_PFLASH02() to the
header for symmetry.
We define macros TYPE_CFI_PFLASH01 and TYPE_CFI_PFLASH02 for type name
strings, then mostly use the strings. If the macros are worth
d
Machine "sam460ex" maps its flash memory at address 0xFFF0. When
no image is supplied, its size is 1MiB (0x10). Else, it's the
size of the image rounded up to the next multiple of 64KiB.
The rounding is actually useless: pflash_cfi01_realize() fails with
"failed to read the initial flash
Machine "ref405ep" maps its flash memory at address 2^32 - image size.
Image size is rounded up to the next multiple of 64KiB. Useless,
because pflash_cfi02_realize() fails with "failed to read the initial
flash content" unless the rounding is a no-op.
If the image size exceeds 0x8 Bytes, we
flash.h's incomplete struct pflash_t is completed both in
pflash_cfi01.c and in pflash_cfi02.c. The complete types are
incompatible. This can hide type errors, such as passing a pflash_t
created with pflash_cfi02_register() to pflash_cfi01_get_memory().
Furthermore, POSIX reserves typedef names
On Mon, 18 Feb 2019 12:13:24 +
Wei Yang wrote:
> On Mon, Feb 18, 2019 at 10:50:34AM +0100, Igor Mammedov wrote:
> >On Mon, 18 Feb 2019 09:13:33 +0800
> >Wei Yang wrote:
> >
> >> Currently we do device realization like below:
> >>
> >>hotplug_handler_pre_plug()
> >>dc->realize()
> >>
pflash_cfi01_register() takes a size in bytes, a block size in bytes
and a number of blocks. mips_malta_init() passes BIOS_SIZE, 65536,
FLASH_SIZE >> 16. Actually consistent only because BIOS_SIZE (defined
in include/hw/mips/bios.h as (4 * MiB)) matches FLASH_SIZE (defined
locally as 0x40).
Alex Bennée posted this patch to address an XXX comment in
pflash_cfi01_realize() the other day:
Subject: [PATCH v2] hw/block: report when pflash backing file isn't aligned
Message-Id: <20190215122808.22301-1-alex.ben...@linaro.org>
https://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg04166
PFLASH_BUG()'s lone use has a suspicious smell: it prints "Possible
BUG", which sounds like a warning, then calls exit(1), followed by
unreachable goto reset_flash. All this commit does is expanding the
macro, so the smell becomes more poignant, and the macro can be
deleted.
Signed-off-by: Markus
Patchew URL: https://patchew.org/QEMU/2019021853.22681-1-coh...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 2019021853.22681-1-coh...@redhat.com
Subject: [Qemu-devel] [PULL 00/10] s390x update
Type: series
==
Hi,
I don't think that len == 0 is a sufficient condition to eliminate integer
overflow. It only ensures that size - 1 is a positive quantity.
De : Laurent Vivier [laur...@vivier.eu]
Envoyé : jeudi 14 février 2019 11:22
À : Rémi Denis-Courmont; qemu-devel
Some instructions allow to suppress IEEE inexact exceptions.
z14 PoP, 9-23, "Suppression of Certain IEEE Exceptions"
IEEE-inexact-exception control (XxC): Bit 1 of
the M4 field is the XxC bit. If XxC is zero, recogni-
tion of IEEE-inexact exception is not suppressed;
if XxC is one,
We want to reuse this in the context of vector instructions. So use
better matching names and introduce s390_restore_bfp_rounding_mode().
While at it, add proper newlines.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/fpu_helper.c | 112 ++
We already forward the 3 bits correctly in the translation functions. We
also have to handle them properly and check for specification
exceptions.
Setting an invalid rounding mode (BFP only, all DFP rounding modes)
results in a specification exception. Setting unassigned bits in the
fpc, results i
The trap is triggered based on priority of the enabled signaling flags.
Only overflow and underflow allow a concurrent inexact exception.
z14 PoP, 9-33, Figure 9-21
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/fpu_helper.c | 13 +
1 file changed,
"round to nearest with ties away from 0" maps to float_round_ties_away.
"round to prepare for shorter precision" maps to float_round_to_odd.
As all instructions properly check for valid rounding modes in translate.c
we can add an assert. Fix one missing empty line.
Cc: Peter Maydell
Reviewed-by:
With the floating-point extension facility, LOAD ROUNDED has
a rounding mode specification and the inexact-exception control (XxC).
Handle them just like e.g. LOAD FP INTEGER.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/fpu_helper.c | 23 +-
We want to reuse that function in vector instruction context. While at it,
cleanup the code, using defines for magic values and avoiding the
handcrafted bit conversion.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/fpu_helper.c | 25 +
IEEE underflows are not reported when the mask bit is off and we don't
also have an inexact exception.
z14 PoP, 9-20, "IEEE Underflow":
An IEEE-underflow exception is recognized for an
IEEE target when the tininess condition exists and
either: (1) the IEEE-underflow mask bit in the FPC
The floating-point extension facility implemented certain changes to
BFP, HFP and DFP instructions.
As we don't implement HFP/DFP, we can ignore those completely. Related
to BFP, the changes include
- SET BFP ROUNDING MODE (SRNMB) instruction
- BFP-rounding-mode field in the FPC register is change
With the floating-point extension facility
- CONVERT FROM LOGICAL
- CONVERT TO LOGICAL
- CONVERT TO FIXED
- CONVERT FROM FIXED
- LOAD FP INTEGER
have both, a rounding mode specification and the inexact-exception control
(XxC). Other instructions will be handled separatly.
Check for valid rounding
Let's use the proper conversion functions now that we have them.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/fpu_helper.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/target/s390x/fpu_helper.c b/target/s390x/fpu_helper.c
index
Many things are wrong and some parts cannot be fixed yet. Fix what we
can fix easily and add two FIXMEs:
The fpc flags are not updated in case an exception is actually injected.
Inexact exceptions have to be handled separately, as they are the only
exceptions that can coexist with underflows and o
We can directly work on the uint64_t value, no need for a temporary
uint32_t value.
Also cleanup and shorten the comments.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/fpu_helper.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-
Let's split handling of BFP/DFP rounding mode configuration. Also,
let's not reuse the sfpc handler, use a separate handler so we can
properly check for specification exceptions for SRNMB.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/fpu_helper.c | 11 ++
Let's detect normal and denormal ("subnormal") numbers reliably. Also
test for quiet NaN's. As only one class is possible, test common cases
first.
While at it, use a better check to test for the mask bits in the data
class mask. The data class mask has 12 bits, whereby bit 0 is the
leftmost bit a
This series is based on the patches currently on the list:
- [PATCH v2] softfloat: add float128_is_{normal,denormal}
- [PATCH v1] softfloat: Implement float128_to_uint32
- [PATCH v2] softfloat: Support float_round_to_odd more places
For the KVM folks, only the last patch is of interest.
The floa
Patchew URL: https://patchew.org/QEMU/2019021853.22681-1-coh...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 2019021853.22681-1-coh...@redhat.com
Subject: [Qemu-devel] [PULL 00/10] s390x update
Type: series
==
Patchew URL: https://patchew.org/QEMU/2019021853.22681-1-coh...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 2019021853.22681-1-coh...@redhat.com
Subject: [Qemu-devel] [PULL 00/10] s390x update
Type: series
==
On Mon, Feb 18, 2019 at 10:50:34AM +0100, Igor Mammedov wrote:
>On Mon, 18 Feb 2019 09:13:33 +0800
>Wei Yang wrote:
>
>> Currently we do device realization like below:
>>
>>hotplug_handler_pre_plug()
>>dc->realize()
>>hotplug_handler_plug()
>>
>> Before we do device realization and p
Stop using system memory as PCI memory otherwise devices such as VGA
that have regions mapped to PCI memory clash with RAM. Use a separate
memory region for PCI memory and map it to the correct address in
system memory which allows PCI mem regions to show at the correct
address where clients expect
According to both the specifications on linux-mips.org referenced in a
comment at the beginning of the file and the flash chip part number
the bios size should be 512k not 1M.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
hw/mips/mips
The machine comes with 256M memory module by default but it's
upgradable so it could have different memory size. There was a TODO
comment to replace static SPD EEPROM data with dynamically generated
one to support this. Now that we have a function for that, it's easy
to do. Although this would allo
Add (partial) emulation of the on-board GPU of the machine. This
allows the PMON2000 firmware to run and should also work with Linux
console but probably not with X yet.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Based-on: 2019021803025
v2 of
http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg02477.html
Addressed review comments and removed last patch (sending it
separately) to make this series not depend on my ati-vga patch so it
can be applied independently.
BALATON Zoltan (3):
hw/pci-host/bonito.c: Add PCI mem region
On 02/16/19 12:21, Markus Armbruster wrote:
> Laszlo Ersek writes:
>> On 02/15/19 17:01, Markus Armbruster wrote:
>>> Using whatever size the image has is sloppy modelling.
>>
>> Maybe so, but it's also very convenient, and also quite important, right
>> now (given the multiple firmware image siz
Hi Jason,
Thanks for the quick reply.
My PV device (to be open sourced soon) uses the QEMU net backend interface,
in a way similar to virtio-net.
For example it uses qemu_set_offload(), qemu_has_vnet_hdr_len(),
qemu_using_vnet_hdr(), qemu_send_packet(), etc.
This means that the device itself doe
On Mon, Feb 18, 2019 at 12:38:11PM +0100, Greg Kurz wrote:
> On Mon, 18 Feb 2019 15:42:18 +0530
> P J P wrote:
>
> > From: Prasad J Pandit
> >
> > On ppc hosts, hypervisor shares following system attributes
> >
> > - /proc/device-tree/system-id
> > - /proc/device-tree/model
> >
> > with a
Patchew URL: https://patchew.org/QEMU/2019021853.22681-1-coh...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 2019021853.22681-1-coh...@redhat.com
Subject: [Qemu-devel] [PULL 00/10] s390x update
Type: series
==
Patchew URL: https://patchew.org/QEMU/2019021853.22681-1-coh...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 2019021853.22681-1-coh...@redhat.com
Subject: [Qemu-devel] [PULL 00/10] s390x update
Type: series
==
On Mon, 18 Feb 2019 15:42:18 +0530
P J P wrote:
> From: Prasad J Pandit
>
> On ppc hosts, hypervisor shares following system attributes
>
> - /proc/device-tree/system-id
> - /proc/device-tree/model
>
> with a guest. This could lead to information leakage and misuse.[*]
> Add machine attri
Trace when assigning/unassigning.
Message-Id: <20190212153025.25425-1-coh...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Cornelia Huck
---
target/s390x/kvm.c| 2 ++
target/s390x/trace-events | 1 +
2 files changed, 3 insertions(+)
diff --git a/target/s390x/kvm.c b/ta
From: Collin Walling
Latest systems and host kernels support mepoch, which is a
feature that was meant to be supported for z14 GA1 from the
get-go. Let's copy it to the z14 GA1 default CPU model.
Machines s390-ccw-virtio-3.1 and older will retain the old CPU
models and will not provide this bit
We are actually paid to look after this.
Message-Id: <20190213103519.32585-1-coh...@redhat.com>
Acked-by: Christian Borntraeger
Acked-by: Halil Pasic
Signed-off-by: Cornelia Huck
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index
From: David Hildenbrand
As we now always have PCI support, let's add it to the "qemu" CPU model,
taking care of backwards compatibility.
Signed-off-by: David Hildenbrand
Message-Id: <20190212112323.15904-1-da...@redhat.com>
Signed-off-by: Cornelia Huck
---
hw/s390x/s390-virtio-ccw.c | 3 +++
From: Collin Walling
Introduce the z14 GA2 cpu model for QEMU. There are no new features
introduced with this model, and will inherit the same feature set as
z14 GA1.
Signed-off-by: Collin Walling
Acked-by: Christian Borntraeger
Reviewed-by: David Hildenbrand
Message-Id: <20190212011657.18324
We tried to make pci support optional on s390x in the past;
unfortunately, we still require the s390 phb to be created
unconditionally due to backwards compatibility issues.
Instead of sinking more effort into this (including compat
handling for older machines etc.) for non-obvious gains, let's
ju
From: Richard Henderson
We will need these from CONFIG_USER_ONLY as well,
which cannot access include/hw/.
Reviewed-by: Thomas Huth
Reviewed-by: David Hildenbrand
Signed-off-by: Richard Henderson
Message-Id: <20190212053044.29015-2-richard.hender...@linaro.org>
Signed-off-by: Cornelia Huck
-
From: Collin Walling
The extended PTFF features (qsie, qtoue, stoe, stoue) are dependent
on the multiple-epoch facility (mepoch). Let's print a warning if these
features are enabled without mepoch.
While we're at it, let's move the FEAT_GROUP_INIT for mepochptff down
the s390_feature_groups list
The following changes since commit 1e36232994c8ad01774501d2e299deba3a2469af:
Merge remote-tracking branch 'remotes/mcayland/tags/qemu-openbios-20190215'
into staging (2019-02-15 11:12:14 +)
are available in the Git repository at:
https://github.com/cohuck/qemu tags/s390x-201
From: Richard Henderson
This is a non-privileged instruction that was only implemented
for system mode. However, the stck instruction is used by glibc,
so this was causing SIGILL for programs run under debian stretch.
Reviewed-by: Thomas Huth
Reviewed-by: David Hildenbrand
Signed-off-by: Rich
From: Thomas Huth
The license information in these files is rather confusing. The text
declares LGPL first, but then says that contributions after 2012 are
licensed under the GPL instead. How should the average user who just
downloaded the release tarball know which part is now GPL and which
is L
Am 18.02.2019 um 11:28 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 18 February 2019 10:09
> > To: Paul Durrant
> > Cc: 'Peter Maydell' ; QEMU Developers > de...@nongnu.org>; Anthony Perard
> > Subject: Re: [Qemu-devel] QEM
The previous patch includes the LUKS payload overhead into the qemu-img
measure calculation for qcow2. Update qemu-iotests 178 to exercise this
new code path.
Reviewed-by: Max Reitz
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Stefan Hajnoczi
---
tests/qemu-iotests/178 | 8 ++
LUKS encryption reserves clusters for its own payload data. The size of
this area must be included in the qemu-img measure calculation so that
we arrive at the correct minimum required image size.
(Ab)use the qcrypto_block_create() API to determine the payload
overhead. We discard the payload da
v3:
* Use encrypt.iter-time=10 to speed up qemu-iotests 178 [Max]
v2:
* Take into account all "encrypt." image creation options since the LUKS
payload size varies depending on the cipher [Max]
The LUKS payload has a significant size (>1 MB). It must be included in the
qemu-img measure calcul
On Fri, Feb 15, 2019 at 08:14:59PM +0100, Max Reitz wrote:
> On 23.01.19 11:33, Stefan Hajnoczi wrote:
> > diff --git a/tests/qemu-iotests/178 b/tests/qemu-iotests/178
> > index 3f4b4a4564..23eb017ea1 100755
> > --- a/tests/qemu-iotests/178
> > +++ b/tests/qemu-iotests/178
> > @@ -142,6 +142,14 @@
On Mon, Feb 18, 2019 at 03:42:18PM +0530, P J P wrote:
> From: Prasad J Pandit
>
> On ppc hosts, hypervisor shares following system attributes
>
> - /proc/device-tree/system-id
> - /proc/device-tree/model
>
> with a guest. This could lead to information leakage and misuse.[*]
> Add machine
On Tue, 5 Feb 2019 18:33:04 +0100
Eric Auger wrote:
> From: Kwangwoo Lee
>
> Pre-plug and plug handlers are prepared for NVDIMM support.
>
> Signed-off-by: Eric Auger
> Signed-off-by: Kwangwoo Lee
> ---
> default-configs/arm-softmmu.mak | 2 ++
> hw/arm/virt-acpi-build.c| 6 +
From: Xie Yongji
The vu_check_queue_msg_file() has checked the FD flag. So let's
delete the redundant check after it.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
contrib/libvhost-user/libvhost-user.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a
From: Xie Yongji
This patch adds support for VHOST_USER_GET_INFLIGHT_FD and
VHOST_USER_SET_INFLIGHT_FD message to set/get shared buffer
to/from qemu. Then backend can track inflight I/O in this buffer.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
Makefile
From: Xie Yongji
This patch enables inflight I/O tracking for
vhost-user-blk backend so that we could restart it safely.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
contrib/vhost-user-blk/vhost-user-blk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/
From: Xie Yongji
Introduce vu_queue_map_desc() which should be
independent with vu_queue_pop();
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
Reviewed-by: Marc-André Lureau
---
contrib/libvhost-user/libvhost-user.c | 88 ---
1 file changed, 51 insertions(+), 37 de
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 18 February 2019 10:09
> To: Paul Durrant
> Cc: 'Peter Maydell' ; QEMU Developers de...@nongnu.org>; Anthony Perard
> Subject: Re: [Qemu-devel] QEMU xen coverity issues
>
> Am 15.02.2019 um 17:20 hat Paul Durrant
From: Xie Yongji
This patch adds support for vhost-user-blk device to get/set
inflight buffer from/to backend.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
hw/block/vhost-user-blk.c | 28
include/hw/virtio/vhost-user-blk.h | 1 +
2 files changed
From: Xie Yongji
Since we now support the message VHOST_USER_GET_INFLIGHT_FD
and VHOST_USER_SET_INFLIGHT_FD. The backend is able to restart
safely because it can track inflight I/O in shared memory.
This patch allows qemu to reconnect the backend after
connection closed.
Signed-off-by: Xie Yongj
From: Xie Yongji
This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
buffer between qemu and backend.
Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
shared buffer from backend. Then qemu should send it back
t
301 - 400 of 438 matches
Mail list logo
