flight 131367 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131367/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898
The xenstore 'ring-page-order' is used globally for each blkback queue and
therefore should be read from xenstore only once. However, it is obtained
in read_per_ring_refs() which might be called multiple times during the
initialization of each blkback queue.
If the blkfront is malicious and the
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, December 17, 2018 10:21 PM
>
> On 17/12/2018 13:09, Andrew Cooper wrote:
> > On 17/12/2018 02:39, Tian, Kevin wrote:
> > After some investigation, it turns out that after vmentry, while the
> > load list has the
flight 131374 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131374/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
Tests which are
flight 131388 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131388/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 3e1a7746aea6fdb1e8d2c05b498bea3d1dc400b3
baseline version:
freebsd
flight 131370 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131370/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
On Mon, 17 Dec 2018, Julien Grall wrote:
> Hi,
>
> On 14/12/2018 17:48, Julien Grall wrote:
> > On 14/12/2018 17:24, Andrii Anisov wrote:
> > > On 14.12.18 18:26, Julien Grall wrote:
> > > > I don't understand how you came up with the conclusion that 128MB will
> > > > be
> > > > removed from
On 17.12.18 19:02, Julien Grall wrote:
I didn't get you wrong. We are saying the same things :).
Great!
Similarly, some version on Linux (i.e prior to 4.2) requires the DTB to within
512MB from the kernel.
I've seen that restriction in the Linux for ARM64 documentation.
in
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
Hi,
On 17/12/2018 17:57, Stefano Stabellini wrote:
On Mon, 17 Dec 2018, Julien Grall wrote:
Hi,
On 14/12/2018 17:48, Julien Grall wrote:
On 14/12/2018 17:24, Andrii Anisov wrote:
On 14.12.18 18:26, Julien Grall wrote:
I don't understand how you came up with the conclusion that 128MB will
On Mon, Dec 17, 2018 at 7:41 AM Razvan Cojocaru
wrote:
>
> Hello,
>
> On 12/17/18 4:14 PM, Juergen Gross wrote:
> > This email only tracks big items for xen.git tree. Please reply for items
> > you
> > would like to see in 4.12 so that people have an idea what is going on and
> > prioritise
On Mon, 17 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 17/12/2018 18:50, Stefano Stabellini wrote:
> > On Mon, 17 Dec 2018, Julien Grall wrote:
> >> On 14/12/2018 19:11, Stefano Stabellini wrote:
> >>> +forward_to_fw:
> >>
> >> On the previous version, I have requested a comment in the
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp_eemi: a function responsible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
On 12/12/18 4:17 PM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v2 08/10] libxl: Kill QEMU by uid when
> possible"):
>> The privcmd fd that a dm_restrict'ed QEMU has gives it permission to
>> one specific domain ID. This domain ID will probably eventually be
>> used again. It is
Hi Stefano,
On 17/12/2018 18:17, Stefano Stabellini wrote:
> On Mon, 17 Dec 2018, Julien Grall wrote:
>> Hi,
>>
>> On 14/12/2018 19:11, Stefano Stabellini wrote:
>>> From: "Edgar E. Iglesias"
>>>
>>> From: Edgar E. Iglesias
>>>
>>> Introduce zynqmp_eemi: a function responsible for implementing
On Mon, 17 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 17/12/2018 18:17, Stefano Stabellini wrote:
> > On Mon, 17 Dec 2018, Julien Grall wrote:
> >> Hi,
> >>
> >> On 14/12/2018 19:11, Stefano Stabellini wrote:
> >>> From: "Edgar E. Iglesias"
> >>>
> >>> From: Edgar E. Iglesias
> >>>
>
ZynqMP IPI mailbox calls are a small set of EEMI sister calls, often
used in conjunction with EEMI related functionalities.
Unfortunately they are not part of the EEMI spec, or any other public
spec, but the implementation is upstream in ATF:
Hi all,
Only minor changes in this patch, mainly:
- add comments
- add a warning
- use full fid to check for action
Cheers,
Stefano
The following changes since commit 82855aba5bf91e50c81526167c11d4aeaf665e66:
tools/libxc: Fix error handling in get_cpuid_domain_info() (2018-11-30
14:21:12
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementation specific) service calls.
Signed-off-by: Edgar E.
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- add in-code
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under XIlPM Error Codes:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Boris Ostrovsky
---
drivers/xen/privcmd-buf.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Boris Ostrovsky
---
drivers/xen/gntdev.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/gntdev.c
flight 131383 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131383/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On Mon, 17 Dec 2018, Julien Grall wrote:
> Hi,
>
> On 14/12/2018 19:11, Stefano Stabellini wrote:
> > From: "Edgar E. Iglesias"
> >
> > From: Edgar E. Iglesias
> >
> > Introduce zynqmp_eemi: a function responsible for implementing access
> > controls over the firmware calls. Only calls that
On Mon, 17 Dec 2018, Julien Grall wrote:
> Hi,
>
> On 14/12/2018 19:11, Stefano Stabellini wrote:
> > From: "Edgar E. Iglesias"
> >
> > From: Edgar E. Iglesias
> >
> > zynqmp_eemi uses the defined functions and structs to decide whether to
> > make a call to the firmware, or to simply return
flight 131400 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131400/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Mon, 17 Dec 2018, Julien Grall wrote:
> Hi,
>
> On 14/12/2018 21:22, Stefano Stabellini wrote:
> > On Fri, 14 Dec 2018, Julien Grall wrote:
> > > +
> > > +/*
> > > + * The full P2M may require some cleaning (e.g when emulation
> > > + * set/way). As the action can take a long time,
Hi Stefano,
On 17/12/2018 18:50, Stefano Stabellini wrote:
> On Mon, 17 Dec 2018, Julien Grall wrote:
>> On 14/12/2018 19:11, Stefano Stabellini wrote:
>>> +forward_to_fw:
>>
>> On the previous version, I have requested a comment in the code explaining
>> why
>> forward the commands without
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
flight 131382 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
Hello,
When PV DRM is enabled and Domain-U is started xen is not able to converted
virtual address to physical. Please provide input on resolving this issue.
Please find the details below.
- We are using 64 bit arm platform.
- Linux 4.20 Kernel in DomU with PV DRM front-end drivers.
-
Hello, Vikram!
First of all what makes you think this is related to PV DRM?
Please see inline for more comments
Thank you,
Oleksandr
On 12/18/18 7:26 AM, Vikram K wrote:
Hello,
When PV DRM is enabled and Domain-U is started xen is not able to
converted virtual address to physical. Please
>>> On 17.12.18 at 16:42, wrote:
> On Fri, Dec 14, 2018 at 04:52:00AM -0700, Jan Beulich wrote:
>> >>> On 14.12.18 at 12:45, wrote:
>> > On Fri, Dec 14, 2018 at 03:45:21AM -0700, Jan Beulich wrote:
>> >> >>> On 14.12.18 at 11:03, wrote:
>> >> > I expect the interdomain locking as a result of
Hi Andrii,
On 17/12/2018 16:02, Andrii Anisov wrote:
On 17.12.18 13:11, Julien Grall wrote:
So, to be honest, I think this is a non-issue. I am not saying this should not
be fixed. I am saying that the price is minimal compare to allow Xen booting
on platform such as the Hikey and bringing
On Mon, Dec 17, 2018 at 09:47:30AM -0700, Jan Beulich wrote:
> >>> On 17.12.18 at 16:42, wrote:
> > On Fri, Dec 14, 2018 at 04:52:00AM -0700, Jan Beulich wrote:
> >> >>> On 14.12.18 at 12:45, wrote:
> >> > On Fri, Dec 14, 2018 at 03:45:21AM -0700, Jan Beulich wrote:
> >> >> >>> On 14.12.18 at
Hi,
On 17/12/2018 15:55, Andrii Anisov wrote:
On 17.12.18 15:38, Julien Grall wrote:
So technically allocating the RAM using a 2MB alignment should be enough.
For 64-bit and, maybe, raw 32-bit Linux kernel images.
For 32-bit compressed Linux kernel - still 128MB aligned first bank is
Hi Andrii,
On 17/12/2018 15:54, Andrii Anisov wrote:
On 14.12.18 20:04, Julien Grall wrote:
Then the code needs to be fixed... It would be nice to get some helps here as
I can't scale.
I can take this.
Thank you.
But I would like to align on the algorithm first.
It is probably worth to
On 12/14/18 10:35 AM, Daniel Vetter wrote:
On Fri, Dec 14, 2018 at 09:09:45AM +0200, Oleksandr Andrushchenko wrote:
On 12/13/18 5:48 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 12:17:54PM +0200, Oleksandr Andrushchenko wrote:
Daniel, could you please comment?
Cross-revieweing someone
On 12/14/2018 10:16 PM, Marek Marczykowski-Górecki wrote:
Hi,
I wonder what happened to intel_pstate patch series[1] back in 2015?
I've seen there was some review feedback[2][3][4][5][6][7] on v6,
patches 4/6 and 6/6 were acked. Were the review comments ever addressed
(can't find it)? Or maybe
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 14 December 2018 15:18
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Tim (Xen.org) ;
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 17 December 2018 08:57
> To: 'Julien Grall' ; xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; Suravee
> Suthikulpanit ; Konrad
This patch removes any implicit flushing that occurs in the implementation
of map and unmap operations and adds new iommu_map/unmap() wrapper
functions. To maintain semantics of the iommu_legacy_map/unmap() wrapper
functions, these are modified to call the new wrapper functions and then
perform an
Paul Durrant (4):
amd-iommu: add flush iommu_ops
iommu: rename wrapper functions
iommu: elide flushing for higher order map/unmap operations
x86/mm/p2m: stop checking for IOMMU shared page tables in mmio_order()
xen/arch/arm/p2m.c| 11 ++-
xen/arch/x86/mm.c
A subsequent patch will add semantically different versions of
iommu_map/unmap() so, in advance of that change, this patch renames the
existing functions to iommu_legacy_map/unmap() and modifies all call-sites.
It also adjusts a comment that refers to iommu_map_page(), which was re-
named by a
flight 131362 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131362/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
flight 131350 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131350/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amdbroken in 131292
Tests which
The iommu_ops structure contains two methods for flushing: 'iotlb_flush' and
'iotlb_flush_all'. This patch adds implementations of these for AMD IOMMUs.
The iotlb_flush method takes a base DFN and a (4k) page count, but the
flush needs to be done by page order (i.e. 0, 9 or 18). Because a flush
Now that the iommu_map() and iommu_unmap() operations take an order
parameter and elide flushing there's no strong reason why modifying MMIO
ranges in the p2m should be restricted to a 4k granularity simply because
the IOMMU is enabled but shared page tables are not in operation.
Signed-off-by:
On Sun, Dec 16, 2018 at 02:47:43AM +0100, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I've found a race condition with handling new devices in driver domain.
> xl devd calls hotplug script when new device is detected in xenstore. At
> the same time, asynchronously, kernel create actual backend
On 13.12.18. 23:37, Paolo Bonzini wrote:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be exempted from the
Hi,
On 14/12/2018 19:11, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp_eemi: a function responsible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edgar E.
On Mon, Dec 17, 2018 at 04:42:40PM +0800, Wei Wang wrote:
> On 12/14/2018 10:16 PM, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I wonder what happened to intel_pstate patch series[1] back in 2015?
> > I've seen there was some review feedback[2][3][4][5][6][7] on v6,
> > patches 4/6 and 6/6
Hi,
On 14/12/2018 19:11, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-off-by:
This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev'
name with 'XenBlockDataPlane' 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
Acked-by: Anthony Perard
---
This is a purely cosmetic patch that purges remaining use of 'blk' and
'ioreq' in local function names, and then makes sure all functions are
prefixed with 'xen_block_'.
No functional change.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
Cc: Stefano Stabellini
Cc: Stefan Hajnoczi
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
This patch adds create and destroy function for XenBlockDevice-s so that
they can be created automatically when the Xen toolstack instantiates a new
PV backend via xenstore. When the XenBlockDevice is created this way it is
also necessary to create a 'drive' which matches the configuration that
...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
On Mon, Dec 17, 2018 at 10:40:59AM +0100, Roger Pau Monné wrote:
> On Sun, Dec 16, 2018 at 02:47:43AM +0100, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I've found a race condition with handling new devices in driver domain.
> > xl devd calls hotplug script when new device is detected in
>>> On 14.12.18 at 14:34, wrote:
> Add a new test to verify if XEN can correctly handle the
> X86EMUL_UNIMPLEMENTED event.
>
> The XTF DomU test image just executes a instruction not implemented by
> the XEN X86 emulator (fstenv) and checks if the execution was
> successfull. This instruction
Hi,
On 14/12/2018 17:48, Julien Grall wrote:
On 14/12/2018 17:24, Andrii Anisov wrote:
On 14.12.18 18:26, Julien Grall wrote:
I don't understand how you came up with the conclusion that 128MB will be
removed from Dom0. We only have the requirement that the first bank is at least
128MB. So can
On Mon, Dec 17, 2018 at 01:18:55PM +0100, Roger Pau Monné wrote:
> On Mon, Dec 17, 2018 at 01:00:01PM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Dec 17, 2018 at 10:40:59AM +0100, Roger Pau Monné wrote:
> > > On Sun, Dec 16, 2018 at 02:47:43AM +0100, Marek Marczykowski-Górecki
> > >
On Mon, Dec 17, 2018 at 11:40:39AM +, Paul Durrant wrote:
> 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()
>
The new xen-block 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-block.c source module as the basis for the new dataplane and
...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 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
Reviewed-by: Anthony Perard
---
Cc:
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
Reviewed-by: Anthony Perard
---
Cc: Stefano
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 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
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
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 new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation incrementally, along with
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'
flight 131389 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131389/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Mon, Dec 17, 2018 at 01:00:01PM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Dec 17, 2018 at 10:40:59AM +0100, Roger Pau Monné wrote:
> > On Sun, Dec 16, 2018 at 02:47:43AM +0100, Marek Marczykowski-Górecki wrote:
> > > A workaround could be implemented in hotplug script itself - wait for
Hello, Juergen, Boris!
As this DRM part of the series is the only one which needs ack/nack
(and it might take quite some time to complete) could we please
merge the patches 1 and 3 now that already have ack/r-b?
Thank you,
Oleksandr
On 12/13/18 12:16 PM, Oleksandr Andrushchenko wrote:
bump
Hi,
On 14/12/2018 21:22, Stefano Stabellini wrote:
On Fri, 14 Dec 2018, Julien Grall wrote:
+
+/*
+ * The full P2M may require some cleaning (e.g when emulation
+ * set/way). As the action can take a long time, it requires
+ * preemption. So this is deferred until we return to
This patch adds the transformations necessary to get dataplane/xen-block.c
to build against the new XenBus/XenDevice framework. MAINTAINERS is also
updated due to the introduction of dataplane/xen-block.h.
NOTE: Existing data structure names are retained for the moment. These will
be
...and wire in the dataplane.
This patch adds the remaining code to make the xen-block 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 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 'XenBlockRequest' type and
'ioreq'
This backend has now been replaced by the 'xen-qdisk' XenDevice.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
Cc: Kevin Wolf
Cc: Max Reitz
Cc: Stefano Stabellini
---
hw/block/Makefile.objs |1 -
hw/block/xen_disk.c| 1011
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 17 December 2018 12:28
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Stefano
> Stabellini ; Stefan Hajnoczi
> ; Max Reitz
>
On 17/12/2018 02:39, Tian, Kevin wrote:
After some investigation, it turns out that after vmentry, while the
load list has the value 0xd01 (NXE, LMA, LME, SCE), the value loaded
into hardware is 0xd00 (NXE, LMA, LME).
I.e. when an MSR load list is used for EFER, we resume
flight 131364 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131364/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 5 host-ping-check-native fail in 131338 pass in 131364
test-amd64-amd64-libvirt-vhd 17
This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.12 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a
On Mon, Dec 17, 2018 at 01:23:15PM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Dec 17, 2018 at 01:18:55PM +0100, Roger Pau Monné wrote:
> > On Mon, Dec 17, 2018 at 01:00:01PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Mon, Dec 17, 2018 at 10:40:59AM +0100, Roger Pau Monné wrote:
> >
On Mon, Dec 17, 2018 at 02:05:34PM +0100, Roger Pau Monné wrote:
> On Mon, Dec 17, 2018 at 01:23:15PM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Dec 17, 2018 at 01:18:55PM +0100, Roger Pau Monné wrote:
> > > On Mon, Dec 17, 2018 at 01:00:01PM +0100, Marek Marczykowski-Górecki
> > >
The new xen-block 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-block.c source module as the basis for the new dataplane and
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
Reviewed-by: Anthony Perard
---
Cc: Stefano
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 new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation incrementally, along with
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().
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
Reviewed-by: Anthony Perard
---
Cc:
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
...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
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
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
1 - 100 of 134 matches
Mail list logo
