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 els
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
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
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
> -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) ; Wei
> -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 Rzeszu
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
op
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: Pa
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 prev
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 dev
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 che
>>> 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 wil
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 t
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
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 w
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
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. Igl
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 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
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
adjusts
...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 r
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
th
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: Stefano
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 Stabell
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().
NOTE
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 [1
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 xen_
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 modifie
...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
ma
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
2
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
C
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 the
...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
implementations
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 xen
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 1
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
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
> > > wrote
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()
> function.
> -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
> Subje
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 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 t
> -Original Message-
> From: Roger Pau Monne
> Sent: 17 December 2018 13:06
> To: Marek Marczykowski-Górecki
> Cc: xen-devel ; Wei Liu
> ; Paul Durrant
> Subject: Re: [Xen-devel] Race condition on device add hanling in xl devd
>
> On Mon, Dec 17, 2018 at 01:23:15PM +0100, Marek Marczykow
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 gues
On 14.12.18 19:48, Julien Grall wrote:
Please try to reference the documentation (or code if lack of documentation)
when making such statement.
Ah, yes, sure.
AFAICT, Linux 32-bit [1] imposes the kernel to be loaded in the first 128MB of
RAM. Nothing about the 128MB aligned RAM.
Right,
On 17/12/2018 11:09, Marek Marczykowski-Górecki wrote:
> 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 fe
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
> > > wrote
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
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
adjusts
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 Stabell
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
th
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().
NOTE
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: Stefano
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 xen_
...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 r
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 [1
Hi,
On 17/12/2018 13:14, Andrii Anisov wrote:
On 14.12.18 19:48, Julien Grall wrote:
Please try to reference the documentation (or code if lack of documentation)
when making such statement.
Ah, yes, sure.
AFAICT, Linux 32-bit [1] imposes the kernel to be loaded in the first 128MB of
RAM.
...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
implementations
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
2 files c
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
---
...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
ma
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 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 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
C
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 the
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 modifie
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 fixed
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 value 0xd01 (NXE, LMA, LME, SCE), the value loaded
> into hardware is 0xd00 (NXE, LMA, LME).
>
> I.e. wh
On Mon, Dec 17, 2018 at 01:11:11PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 17 December 2018 13:06
> > To: Marek Marczykowski-Górecki
> > Cc: xen-devel ; Wei Liu
> > ; Paul Durrant
> > Subject: Re: [Xen-devel] Race condition on device add hanli
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 accordingly.
>
> You're welcome to provide description and use cases of the fe
> -Original Message-
> From: Roger Pau Monne
> Sent: 17 December 2018 14:32
> To: Paul Durrant
> Cc: Marek Marczykowski-Górecki ; xen-
> devel ; Wei Liu
> Subject: Re: [Xen-devel] Race condition on device add hanling in xl devd
>
> On Mon, Dec 17, 2018 at 01:11:11PM +, Paul Durrant w
On Mon, Dec 17, 2018 at 02:23:41PM +0100, Marek Marczykowski-Górecki 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 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
> 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?
>
TBH I am not sur
On Monday, December 17, 2018 9:19 PM, Andrew Cooper wrote:
> On 17/12/2018 11:09, Marek Marczykowski-Górecki wrote:
> > 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_psta
On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
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
On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote:
> On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
>> On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
>>> 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
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 using a paging caller
> >> > domain is goin
On 14/12/2018 10:16, Jan Beulich wrote:
On 13.12.18 at 21:22, wrote:
>> --- a/xen/arch/x86/hvm/svm/emulate.c
>> +++ b/xen/arch/x86/hvm/svm/emulate.c
>> @@ -143,8 +143,17 @@ int svm_get_insn_len(struct vcpu *v, enum
>> instruction_index insn)
>> }
>>
>> gdprintk(XENLOG_WARNING,
>>
On 14/12/2018 08:50, Jan Beulich wrote:
> Now that we require use of the {evex} pseudo-prefix, we can also use
> the q-suffixed encoding of VPCMPESTRI, which is available as of 2.29
> just like {evex} is.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
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.
But I would like to align on the algorithm first.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailin
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 required.
It can be changed on kernel side by setting
On 14/12/2018 08:49, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds.
> Putting the make invocation to produce the header tog
On 12/10/18 10:12 AM, Andrea Righi wrote:
> Blacklist symbols in Xen probe-prohibited areas, so that user can see
> these prohibited symbols in debugfs.
>
> See also: a50480cb6d61.
>
> Signed-off-by: Andrea Righi
Applied to for-linus-4.21
-boris
___
On 12/14/18 7:55 AM, Ross Lagerwall wrote:
> If pcistub_init_device fails, the release function will be called with
> dev_data set to NULL. Check it before using it to avoid a NULL pointer
> dereference.
>
> Signed-off-by: Ross Lagerwall
I think this should go to stable trees too (copying them)
>>> On 17.12.18 at 16:43, wrote:
> On 14/12/2018 10:16, Jan Beulich wrote:
> On 13.12.18 at 21:22, wrote:
>>> --- a/xen/arch/x86/hvm/svm/emulate.c
>>> +++ b/xen/arch/x86/hvm/svm/emulate.c
>>> @@ -143,8 +143,17 @@ int svm_get_insn_len(struct vcpu *v, enum
> instruction_index insn)
>>> }
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 more compliance with the Arm Arm.
BTW, I hope you alr
On Mon, Dec 17, 2018 at 02:42:23PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 17 December 2018 14:32
> > To: Paul Durrant
> > Cc: Marek Marczykowski-Górecki ; xen-
> > devel ; Wei Liu
> > Subject: Re: [Xen-devel] Race condition on device add hanl
flight 131358 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131358/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131332
test-armhf-armhf-libvirt 14 sav
>>> 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 usi
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 m
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 11:
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 requir
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 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,
1 - 100 of 134 matches
Mail list logo
