Am 20.11.2018 um 23:52 hat Eric Blake geschrieben:
> The use of TLS while building qemu is optional. While the
> 'certtool' binary should be available on every platform that
> supports building against TLS, that does not imply that the
> developer has installed it. Make the test gracefully skip
>
On Tue, Nov 20, 2018 at 04:52:41PM -0600, Eric Blake wrote:
> The use of TLS while building qemu is optional. While the
> 'certtool' binary should be available on every platform that
> supports building against TLS, that does not imply that the
> developer has installed it. Make the test
Am 19.11.2018 um 11:19 hat Max Reitz geschrieben:
> One of the amend error paths has two issues that are fixed by this
> series. Since they are relatively minor and have been present in 3.0
> already, I think there is no need to get them into 3.1. OTOH they are
> bug fixes, so they could go into
On Tue, Nov 20, 2018 at 12:22:39PM -0600, Eric Blake wrote:
> On 11/20/18 11:53 AM, Daniel P. Berrangé wrote:
>
> > > > > +echo
> > > > > +echo "== preparing TLS creds =="
> > > > > +
> > > > > +tls_x509_create_root_ca "ca1"
> > > > > +tls_x509_create_root_ca "ca2"
> > > > >
A Xen PV frontend communicates its state to the PV backend by writing to
the 'state' key in the frontend area in xenstore. It is therefore
necessary for a XenDevice implementation to be notified whenever the
value of this key changes.
This patch adds code to do this as follows:
- an 'fd handler'
This patch adds a new source module, xen-bus-helper.c, which builds on
basic libxenstore primitives to provide functions to create (setting
permissions appropriately) and destroy xenstore areas, and functions to
'printf' and 'scanf' nodes therein. The main xen-bus code then uses
these primitives
The legacy PV backend infrastructure provides functions to bind, unbind
and send notifications to event channnels. Similar functionality will be
required by XenDevice implementations so this patch adds the necessary
support.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony
This patch adds the basic boilerplate for a 'XenBus' object that will act
as a parent to 'XenDevice' PV backends.
A new 'XenBridge' object is also added to connect XenBus to the system bus.
The XenBus object is instantiated by a new xen_bus_init() function called
from the same sites as the legacy
This patch adds a new XenDevice: 'xen-qdisk' [1]. This will eventually
replace the 'xen_disk' legacy PV backend but it is illustrative to build
up the implementation incrementally, along with the XenBus/XenDevice
framework. Subsequent patches will therefore add to this device's
implementation as
This series introduces a new QOM compliant framework for Xen PV backends.
This is achieved by first moving the current non-compliant framework aside,
before building up a new framework incrementally.
This series was prompted by a thread [1] started by Kevin Wolf in response
to patches against
The legacy PV backend infrastructure provides functions to map, unmap and
copy pages granted by frontends. Similar functionality will be required
by XenDevice implementations so this patch adds the necessary support.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
---
...and xen_backend.h to xen-legacy-backend.h
Rather than attempting to convert the existing backend infrastructure to
be QOM compliant (which would be hard to do in an incremental fashion),
subsequent patches will introduce a completely new framework for Xen PV
backends. Hence it is necessary to
The new xen-qdisk XenDevice implementation requires the same core dataplane
as the legacy xen_disk implementation it will eventually replace. This
patch therefore copies the legacy xen_disk.c source module into a new
dataplane/xen-qdisk.c source module as the basis for the new dataplane and
Not all of the code duplicated from xen_disk.c is required as the basis for
the new dataplane implementation so this patch removes extraneous code,
along with the legacy #includes and calls to the legacy xen_pv_printf()
function. Error messages are changed to be reported using error_report().
This patch adds a creator function for XenQdiskDevice-s so that they can
be created automatically when the Xen toolstack instantiates a new
PV backend. When the XenQdiskDevice is created this way it is also
necessary to create a drive which matches the configuration that the Xen
toolstack has
This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev'
name with 'XenQdiskDataPlane' and 'blkdev' field/variable names with
'dataplane', and then does necessary fix-up to adhere to coding style.
No functional change.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
...and wire in the dataplane.
This patch adds the remaining code to make the xen-qdisk XenDevice
functional. The parameters that a block frontend expects to find are
populated in the backend xenstore area, and the 'ring-ref' and
'event-channel' values specified in the frontend xenstore area are
This backend has now been replaced by the 'xen-qdisk' XenDevice.
Signed-off-by: Paul Durrant
---
Cc: Kevin Wolf
Cc: Max Reitz
---
hw/block/Makefile.objs |1 -
hw/block/xen_disk.c| 1011
2 files changed, 1012 deletions(-)
delete mode
This is a purely cosmetic patch that purges the name 'ioreq' from struct,
variable and field names. (This name has been problematic for a long time
as 'ioreq' is the name used for generic I/O requests coming from Xen).
The patch replaces 'struct ioreq' with a new 'XenQdiskRequest' type and
'ioreq'
This is a purely cosmetic patch that purges remaining use of 'blk' and
'ioreq' in local function names.
No functional change.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Stefan Hajnoczi
Cc: Kevin Wolf
Cc: Max Reitz
---
hw/block/dataplane/xen-qdisk.c | 86
This patch adds the transformations necessary to get dataplane/xen-qdisk.c
to build against the new XenBus/XenDevice framework. MAINTAINERS is also
updated due to the introduction of dataplane/xen-qdisk.h.
NOTE: Existing data structure names are retained for the moment. These will
be
I have made many significant contributions to the Xen code in QEMU,
particularly the recent patches introducing a new PV device framework.
I intend to make further significant contributions, porting other PV back-
ends to the new framework with the intent of eventually removing the
legacy code. It
...that maintains compatibility with existing Xen toolstacks.
Xen toolstacks instantiate PV backends by simply writing information into
xenstore and expecting a backend implementation to be watching for this.
This patch adds a new 'xen-backend' module to allow individual XenDevice
Am 21.11.2018 um 13:47 hat Richard W.M. Jones geschrieben:
> Commit 40dce4ee6 "scsi-disk: fix rerror/werror=ignore" introduced a
> bug which causes qemu to crash with the assertion error below if the
> host file or disk returns an error:
>
> qemu-system-x86_64: hw/scsi/scsi-bus.c:1374:
Commit 40dce4ee6 "scsi-disk: fix rerror/werror=ignore" introduced a
bug which causes qemu to crash with the assertion error below if the
host file or disk returns an error:
qemu-system-x86_64: hw/scsi/scsi-bus.c:1374: scsi_req_complete:
Assertion `req->status == -1' failed.
Kevin Wolf
On 11/20/2018 08:52 PM, Eric Blake wrote:
The use of TLS while building qemu is optional. While the
'certtool' binary should be available on every platform that
supports building against TLS, that does not imply that the
developer has installed it. Make the test gracefully skip
in that case.
Hi Daniel!
After moving compression to threads in Qcow2 it's an obvious next step to
"threadyfy" encryption in Qcow2 too.
But it turned out to be not as simple as I assumed. If I call
qcrypto_block_encrypt
in parallel threads with the same first argument (block), it just produce wrong
things
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20181120184148.22501-1-pbonz...@redhat.com
Type: series
Subject: [Qemu-devel] [PATCH] nvme: fix out-of-bounds access to the CMB
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
When the submission and completion queues are being torn down
the IRQ will be asserted for the completion queue when the
submsission queue is deleted. Then when the completion queue
is deleted it stays asserted. Thus, on systems that do
not use MSI, no further interrupts can be triggered on the
On 21/11/18 13:47, Richard W.M. Jones wrote:
> Commit 40dce4ee6 "scsi-disk: fix rerror/werror=ignore" introduced a
> bug which causes qemu to crash with the assertion error below if the
> host file or disk returns an error:
>
> qemu-system-x86_64: hw/scsi/scsi-bus.c:1374: scsi_req_complete:
>
Am 12.11.2018 um 15:00 hat Alberto Garcia geschrieben:
> Hi all,
>
> when reopening a BlockDriverState using bdrv_reopen() and friends the
> new options can be specified either with a QDict or with flags. Both
> methods overlap and that makes the semantics and the implementation
> unnecessarily
[ Cc: qemu-block ]
Am 20.11.2018 um 18:56 hat Daniel P. Berrangé geschrieben:
> The first qemu-io command must honour the $IMGFMT that is set rather
> than hardcoding qcow2. The qemu-nbd commands should also set $IMGFMT
> to avoid the insecure format probe warning.
>
> Signed-off-by: Daniel P.
32 matches
Mail list logo
