On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
> Not for me, I fail to boot with
>
> [ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
> total 0 (slots), used 0 (slots)
>
> (this is iscsi root so I need the NIC).
>
>
> I bisected it to "x86: remove the
From: Luca Miccio
Introduce a new memory page allocator that implement the cache coloring
mechanism. The allocation algorithm follows the given coloring scheme
specified for each guest, and maximizes contiguity in the page
selection.
Pages are stored by color in separated and address-ordered
From: Luca Miccio
Four additional parameters in the Xen command line are used to define
the underlying coloring policy, which is not directly configurable
otherwise.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
docs/misc/xen-command-line.pandoc | 51
From: Luca Miccio
Print the color assignment for each domain when requested.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
xen/arch/arm/coloring.c | 12
xen/arch/arm/domain.c | 1 +
xen/arch/arm/include/asm/coloring.h | 7 +++
3
From: Luca Miccio
Currently coloring supports breaks assertion in domctl.c:892 because of
the data structure used for color configuration. Currently the array is
set to support up to 128 colors.
Lower the number of supported colors to 64 until a better solution is
found.
Signed-off-by: Luca
From: Luca Miccio
Signed-off-by: Luca Miccio
---
xen/include/xen/mm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 3be754da92..f0861ed5bb 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -488,6 +488,8 @@
From: Luca Miccio
In order to efficiently coloring Xen, we need to relocate it and move
the xen code to a unique memory region that will be marked as colored
for Xen itself. This region will be out target region and it will be
placed as high as possibile in RAM. To do that we need to use the old
From: Luca Miccio
When cache coloring is enabled, a certain amount of memory is reserved
for buddy allocation because current coloring implementation does not
support Xen heap memory. As of this commit, the colored allocator is used
for dom0, domUs, while the buddy manages only Xen memory. The
From: Luca Miccio
Based on the intrinsic nature of cache coloring, it is trivial to state
that each domain that is colored is also not direct mapped.
Set the directmap variable to false when coloring is enabled.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
From: Luca Miccio
Introduce two new arm specific functions to temporarily map/unmap the
Xen text read-write (the Xen text is mapped read-only by default by
setup_pagetables): xen_map_text_rw and xen_unmap_text_rw.
There is only one caller in the alternative framework.
The non-colored
From: Luca Miccio
Add initialization for Xen coloring data. By default, use the lowest
color index available.
Benchmarking the VM interrupt response time provides an estimation of
LLC usage by Xen's most latency-critical runtime task. Results on Arm
Cortex-A53 on Xilinx Zynq UltraScale+
From: Luca Miccio
The color selection has to be specified in the configuration file of the
virtual machine with the new parameter 'colors'. This parameter
defines the colors to be assigned to that particular VM, expressed as a
list of ranges.
Add documentation for the new 'colors' parameter.
From: Luca Miccio
Display general information about coloring support both during boot and
when requested by the user.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/coloring.c | 24
1 file changed, 24
From: Luca Miccio
Dom0less uses device tree for DomUs when booting them without using
Dom0. Add a new device tree property 'colors' that specifies the
coloring configuration for DomUs when using Dom0less.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
Hi Marco,
On 04/03/2022 17:46, Marco Solieri wrote:
From: Luca Miccio
This reverts commit 48fb2a9deba11ee48dde21c5c1aa93b4d4e1043b.
Can you explain why you need to revert this patch?
Also, there is a missing signed-off-by for both Luca and you.
Cheers,
--
Julien Grall
Hi,
On 04/03/2022 17:46, Marco Solieri wrote:
From: Luca Miccio
Introduce a new implementation of setup_pagetables that uses coloring
logic in order to isolate Xen code using its color selection.
Page tables construction is essentially copied, except for the xenmap
table, where coloring logic
On Thu, Mar 03, 2022 at 02:49:29PM -0800, Stefano Stabellini wrote:
> On Thu, 3 Mar 2022, Christoph Hellwig wrote:
> > On Wed, Mar 02, 2022 at 05:25:10PM -0800, Stefano Stabellini wrote:
> > > Thinking more about it we actually need to drop the xen_initial_domain()
> > > check otherwise some cases
On 04/03/2022 14:40, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
I have a question.
On 04/03/2022 12:49, Julien Grall wrote:
On 04/03/2022 12:13, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
On 04/03/2022 10:46, Julien Grall wrote:
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
flight 168394 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168394/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168383
test-amd64-amd64-xl-qemuu-ws16-amd64
Hi Michael,
On 3/4/22 10:12 AM, Michael Kelley (LINUX) wrote:
> From: Christoph Hellwig Sent: Tuesday, March 1, 2022 2:53 AM
>>
>> Power SVM wants to allocate a swiotlb buffer that is not restricted to low
>> memory for
>> the trusted hypervisor scheme. Consolidate the support for this into
Hi Stefano,
On 04/03/2022 01:43, Stefano Stabellini wrote:
On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
If the abort was caused due to access to stage1 translation table, Xen
will assume that the stage1 translation table is in the non MMIO region.
It will try to resolve the translation fault.
From: Christoph Hellwig Sent: Tuesday, March 1, 2022 2:53 AM
>
> Power SVM wants to allocate a swiotlb buffer that is not restricted to low
> memory for
> the trusted hypervisor scheme. Consolidate the support for this into the
> swiotlb_init
> interface by adding a new flag.
Hyper-V
flight 168401 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168401/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Fri, Mar 04, 2022 at 12:36:17PM -0500, Boris Ostrovsky wrote:
>>> I bisected it to "x86: remove the IOMMU table infrastructure" but haven't
>>> actually looked at the code yet.
>> That looks like the swiotlb buffer did not get initialized at all, but I
>> can't really explain why.
>>
>> Can
flight 168399 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168399/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 3/4/22 12:28 PM, Christoph Hellwig wrote:
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
Not for me, I fail to boot with
[ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
total 0 (slots), used 0 (slots)
(this is iscsi root so I need the NIC).
From: Luca Miccio
Add basic documentation that shows how cache coloring support can be
used in Xen. It introduces the basic concepts behind cache coloring,
defines the cache selection format, and explains how to assign colors to
the supported domains: Dom0, DomUs and Xen itself. Known issues are
From: Luca Miccio
The size of the LLC way is a crucial parameter for the cache coloring
support, since it determines the maximum number of available colors on
the platform. This parameter can currently be retrieved only from
the way_size bootarg and it is prone to misconfiguration nullifying
From: Luca Miccio
This reverts commit 3a5d341681af650825bbe3bee9be5d187da35080.
The coloring support will be configurable within the Xen command line
but it will be initialized before the page-tables; this is necessary
for coloring the hypervisor itself beacuse we will create a specific
From: Luca Miccio
Add three new bootargs allowing configuration of cache coloring support
for Xen:
- way_size: The size of a LLC way in bytes. This value is mainly used
to calculate the maximum available colors on the platform.
- dom0_colors: The coloring configuration for Dom0, which also
From: Luca Miccio
Introduce a first and simple initialization function for the cache
coloring support. A helper function computes 'addr_col_mask', the
platform-dependent bitmask asserting the bits in memory addresses that
can be used for the coloring mechanism. This, in turn is used to
determine
From: Luca Miccio
During Xen coloring procedure, we need to manually calculate consecutive
physical addresses that conform to the color selection. Add an helper
function that does this operation. The latter will return the next
address that conforms to Xen color selection.
The next_colored
Shared caches in multi-core CPU architectures represent a problem for
predictability of memory access latency. This jeopardizes applicability
of many Arm platform in real-time critical and mixed-criticality
scenarios. We introduce support for cache partitioning with page
coloring, a transparent
From: Luca Miccio
Upcoming patches will need to remove temporary mappings created during
Xen coloring process. The function remove_early_mappings does what we
need but it is case-specific. Parametrize the function to avoid code
replication.
Signed-off-by: Luca Miccio
Signed-off-by: Marco
From: Luca Miccio
Introduce a new implementation of setup_pagetables that uses coloring
logic in order to isolate Xen code using its color selection.
Page tables construction is essentially copied, except for the xenmap
table, where coloring logic is needed. Given the absence of a contiguous
From: Luca Miccio
Static memory assumes to have physically contiguous memory mapped to
domains. This assumption cannot be made when coloring is enabled.
These two features have to be mutually exclusive.
Signed-off-by: Luca Miccio
---
xen/arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
From: Luca Miccio
In order to relocate Xen the function get_xen_paddr will be used in the
following patches. The method has "consider_modules" as a prerequisite
so it has to be enabled both for ARM32 and coloring.
Signed-off-by: Luca Miccio
---
xen/arch/arm/setup.c | 2 +-
1 file changed, 1
From: Luca Miccio
Dom0less color assignment is performed via Device Tree with a new
attribute "colors". In this case the color assignment is represented by
a bitmask where it suffices to set all and only the bits having a
position equal to the chosen colors, leaving unset all the others.
From: Luca Miccio
We want to be able to associate an assignment of cache colors to each
domain. Add a configurable-length array containing a set of color
indices in the domain data.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
xen/include/xen/sched.h | 4
1 file changed,
From: Luca Miccio
This reverts commit 48fb2a9deba11ee48dde21c5c1aa93b4d4e1043b.
---
xen/arch/arm/setup.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d5d0792ed4..c5a556855e 100644
--- a/xen/arch/arm/setup.c
From: Luca Miccio
Initialize cache coloring configuration during domain creation. If no
colors assignment is provided by the user, use the default one.
The default configuration is the one assigned to Dom0. The latter is
configured as a standard domain with default configuration.
Signed-off-by:
From: Luca Miccio
Coloring support will re-enable part of the Xen relocation since the
underlying idea is to "relocate using coloring" for the hypervisors
itself.
We setup a target region that will be used exclusively from Xen and
it will be mapped using the coloring configuration of the
From: Luca Miccio
During domU creation process the colors selection has to be passed to
the Xen hypercall.
This is generally done using what Xen calls GUEST_HANDLE_PARAMS. In this
case a simple bitmask for the coloring configuration suffices.
Currently the maximum amount of supported colors is
From: Luca Miccio
A new allocator enforcing a cache-coloring configuration is going to be
introduced. We thus need to distinguish the memory pages assigned to,
and managed by, such colored allocator from the ordinary buddy
allocator's ones. Add a color flag to the page structure.
From: Luca Miccio
When cache coloring support is enabled, a color assignment is needed for
every domain. Introduce a function computing a default configuration
with a safe and common value -- the dom0 color selection.
Do not access directly the array of color indices of dom0. Instead make
use
From: Luca Miccio
Dom0 color configuration is parsed in the Xen command line. Add an
helper function to check the user selection. If no configuration is
provided by the user, all the available colors supported by the
hardware will be assigned to dom0.
Signed-off-by: Luca Miccio
Signed-off-by:
From: Luca Miccio
Add a new "colors" parameter that defines the color assignment for a
domain. The user can specify one or more color ranges using the same
syntax as the command line color selection (e.g. 0-4).
The parameter is defined as a list of strings that represent the
color ranges.
From: Luca Miccio
The colored allocator should not make any assumptions on how a color is
defined, since the definition may change depending on the architecture.
Use a generic function "color_from_page" that returns the color id based
on the page address.
Add a definition for ARMv8
From: Luca Miccio
In order to initialize the colored allocator data structure, the maximum
amount of colors defined by the hardware has to be know.
Add a helper function that returns this information.
Signed-off-by: Luca Miccio
---
xen/arch/arm/coloring.c | 5 +
From: Luca Miccio
Initialize colored heap and allocator data structures. It is assumed
that pages are given to the init function is in ascending order. To
ensure that, pages are retrieved from bootmem_regions starting from the
first one. Moreover, this allows quickly insertion of freed pages
flight 168402 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168402/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Fri, 4 Mar 2022, Ayan Kumar Halder wrote:
> On 04/03/2022 01:43, Stefano Stabellini wrote:
> > On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> > > If the abort was caused due to access to stage1 translation table, Xen
> > > will assume that the stage1 translation table is in the non MMIO region.
flight 168398 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168398/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168388
test-armhf-armhf-libvirt 16
flight 168407 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi,
On 04/03/2022 17:46, Marco Solieri wrote:
From: Luca Miccio
The colored allocator should not make any assumptions on how a color is
defined, since the definition may change depending on the architecture.
IIUC, you are saying that the mapping between a physical address to a
way is the
On Fri, 4 Mar 2022, Julien Grall wrote:
> Hi Stefano,
>
> On 04/03/2022 00:42, Stefano Stabellini wrote:
> > > void register_mmio_handler(struct domain *d,
> > > diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
> > > index 308650b400..58cd320b5a 100644
> > > --- a/xen/arch/arm/ioreq.c
>
flight 168408 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi,
On 04/03/2022 17:46, Marco Solieri wrote:
From: Luca Miccio
A new allocator enforcing a cache-coloring configuration is going to be
introduced. We thus need to distinguish the memory pages assigned to,
and managed by, such colored allocator from the ordinary buddy
allocator's ones. Add
flight 168404 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168404/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 3/4/22 12:43 PM, Christoph Hellwig wrote:
On Fri, Mar 04, 2022 at 12:36:17PM -0500, Boris Ostrovsky wrote:
I bisected it to "x86: remove the IOMMU table infrastructure" but haven't
actually looked at the code yet.
That looks like the swiotlb buffer did not get initialized at all, but I
flight 168405 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168405/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Fri, Mar 04, 2022 at 03:18:23PM -0500, Boris Ostrovsky wrote:
> This indeed allows dom0 to boot. Not sure I see where in the next patch this
> would have been fixed?
I thought it did, but it doesn't. In the meantime I've pushed out an
updated branch with this folded in to:
On Fri, 4 Mar 2022, Christoph Hellwig wrote:
> On Thu, Mar 03, 2022 at 02:49:29PM -0800, Stefano Stabellini wrote:
> > On Thu, 3 Mar 2022, Christoph Hellwig wrote:
> > > On Wed, Mar 02, 2022 at 05:25:10PM -0800, Stefano Stabellini wrote:
> > > > Thinking more about it we actually need to drop the
flight 168400 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168400/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 168390
Tests which did
flight 168411 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168411/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hello,
I have built & installed Xen 4.15 onto my Ubuntu20.04 platform successfully
according to https://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
After reboot, I entered Domain 0 successfully. The command xl info shows
the right version string.
*host
On 03.03.2022 17:37, Jane Malalane wrote:
> On 03/03/2022 11:37, Jan Beulich wrote:
>> On 02.03.2022 16:00, Jane Malalane wrote:
>>> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
>>> XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
>>> and x2apic, on x86 hardware.
>>> No such
On 03.03.2022 16:09, Roger Pau Monné wrote:
> On Thu, Mar 03, 2022 at 01:17:03PM +0100, Jan Beulich wrote:
>> On 03.03.2022 12:19, Roger Pau Monné wrote:
>>> On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
On 3/4/2022 1:27 PM, Roger Pau Monné wrote:
On Fri, Mar 04, 2022 at 01:05:55PM +0100, Andrea Stevanato wrote:
On 3/4/2022 12:52 PM, Roger Pau Monné wrote:
On Thu, Mar 03, 2022 at 01:08:31PM -0500, Jason Andryuk wrote:
On Thu, Mar 3, 2022 at 11:34 AM Roger Pau Monné wrote:
On Thu, Mar 03,
flight 168390 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168390/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168376
test-armhf-armhf-libvirt 16
flight 168397 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168397/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 04.03.2022 10:31, Roger Pau Monné wrote:
> On Fri, Mar 04, 2022 at 09:02:08AM +0100, Jan Beulich wrote:
>> On 03.03.2022 16:09, Roger Pau Monné wrote:
>>> On Thu, Mar 03, 2022 at 01:17:03PM +0100, Jan Beulich wrote:
On 03.03.2022 12:19, Roger Pau Monné wrote:
> On Wed, Mar 02, 2022 at
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
+void post_increment_register(const struct instr_details *instr)
+{
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+register_t val = 0;
+
+/* Currently, we handle only ldr/str post indexing instructions */
+if (
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
If the abort was caused due to access to stage1 translation table, Xen
will assume that the stage1 translation table is in the non MMIO region.
It will try to resolve the translation fault. If it succeeds, it will
return to the guest to
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
When the data abort is caused due to cache maintenance for an address,
there are two scenarios:-
1. Address belonging to a non emulated region - For this, Xen should
set the corresponding bit in the translation table entry to valid and
On Fri, Mar 04, 2022 at 09:02:08AM +0100, Jan Beulich wrote:
> On 03.03.2022 16:09, Roger Pau Monné wrote:
> > On Thu, Mar 03, 2022 at 01:17:03PM +0100, Jan Beulich wrote:
> >> On 03.03.2022 12:19, Roger Pau Monné wrote:
> >>> On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
> As
On Fri, Mar 04, 2022 at 10:17:22AM +0100, Jan Beulich wrote:
> On 04.03.2022 09:57, Roger Pau Monné wrote:
> > On Fri, Mar 04, 2022 at 08:49:39AM +0100, Jan Beulich wrote:
> >> This simply parallels .dtors. Both section types can reference
> >> .text.exit, which requires them to be discarded
Hi Stefano,
On 04/03/2022 00:42, Stefano Stabellini wrote:
void register_mmio_handler(struct domain *d,
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 308650b400..58cd320b5a 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -47,6 +47,7 @@ enum io_state
On Fri, Mar 04, 2022 at 08:49:39AM +0100, Jan Beulich wrote:
> This simply parallels .dtors. Both section types can reference
> .text.exit, which requires them to be discarded together with that one.
> Compilers, depending on their findings during the configure phase, may
> elect to use either
On 04.03.2022 09:57, Roger Pau Monné wrote:
> On Fri, Mar 04, 2022 at 08:49:39AM +0100, Jan Beulich wrote:
>> This simply parallels .dtors. Both section types can reference
>> .text.exit, which requires them to be discarded together with that one.
>> Compilers, depending on their findings during
On Fri, Mar 04, 2022 at 09:02:08AM +0100, Jan Beulich wrote:
> On 03.03.2022 16:09, Roger Pau Monné wrote:
> > On Thu, Mar 03, 2022 at 01:17:03PM +0100, Jan Beulich wrote:
> >> On 03.03.2022 12:19, Roger Pau Monné wrote:
> >>> On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
> As
flight 168395 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 168388 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168388/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168328
test-amd64-amd64-qemuu-nested-amd
On 03/03/2022 19:08, Jason Andryuk wrote:
On Thu, Mar 3, 2022 at 11:34 AM Roger Pau Monné wrote:
On Thu, Mar 03, 2022 at 05:01:23PM +0100, Andrea Stevanato wrote:
On 03/03/2022 15:54, Andrea Stevanato wrote:
Hi all,
according to the conversation that I had with royger, aa67b97ed34 broke
Hi Julien,
Many thanks for the feedback.
I have some clarifications.
On 04/03/2022 10:28, Julien Grall wrote:
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
+void post_increment_register(const struct instr_details *instr)
+{
+ struct cpu_user_regs *regs = guest_cpu_user_regs();
+
On Thu, Mar 03, 2022 at 01:08:31PM -0500, Jason Andryuk wrote:
> On Thu, Mar 3, 2022 at 11:34 AM Roger Pau Monné wrote:
> >
> > On Thu, Mar 03, 2022 at 05:01:23PM +0100, Andrea Stevanato wrote:
> > > On 03/03/2022 15:54, Andrea Stevanato wrote:
> > > > Hi all,
> > > >
> > > > according to the
flight 168393 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi Julien,
On 04/03/2022 10:46, Julien Grall wrote:
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
When the data abort is caused due to cache maintenance for an address,
there are two scenarios:-
1. Address belonging to a non emulated region - For this, Xen should
set the
On 04/03/2022 12:13, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
On 04/03/2022 10:46, Julien Grall wrote:
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
When the data abort is caused due to cache maintenance for an address,
there are two scenarios:-
1. Address belonging to a non
flight 168396 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168396/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, Mar 03, 2022 at 05:47:48PM +0100, Jan Beulich wrote:
> On 03.03.2022 17:45, Alex Olson wrote:
> > --- a/xen/arch/x86/hvm/hypercall.c
> > +++ b/xen/arch/x86/hvm/hypercall.c
> > @@ -84,6 +84,17 @@ static long hvm_physdev_op(int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >
> > switch
On 3/3/2022 7:08 PM, Jason Andryuk wrote:
On Thu, Mar 3, 2022 at 11:34 AM Roger Pau Monné wrote:
On Thu, Mar 03, 2022 at 05:01:23PM +0100, Andrea Stevanato wrote:
On 03/03/2022 15:54, Andrea Stevanato wrote:
Hi all,
according to the conversation that I had with royger, aa67b97ed34 broke
On 3/4/2022 12:52 PM, Roger Pau Monné wrote:
On Thu, Mar 03, 2022 at 01:08:31PM -0500, Jason Andryuk wrote:
On Thu, Mar 3, 2022 at 11:34 AM Roger Pau Monné wrote:
On Thu, Mar 03, 2022 at 05:01:23PM +0100, Andrea Stevanato wrote:
On 03/03/2022 15:54, Andrea Stevanato wrote:
Hi all,
On Fri, Mar 04, 2022 at 01:05:55PM +0100, Andrea Stevanato wrote:
> On 3/4/2022 12:52 PM, Roger Pau Monné wrote:
> > On Thu, Mar 03, 2022 at 01:08:31PM -0500, Jason Andryuk wrote:
> > > On Thu, Mar 3, 2022 at 11:34 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Thu, Mar 03, 2022 at
Hi,
On 04/03/2022 11:27, Ayan Kumar Halder wrote:
+ {
+ rc = decode_instruction(regs, info);
+ if ( rc )
+ {
+ gprintk(XENLOG_DEBUG, "Unable to decode
instruction\n");
+ info->dabt_instr.state = INSTR_ERROR;
+ }
+
Hi Julien,
I have a question.
On 04/03/2022 12:49, Julien Grall wrote:
On 04/03/2022 12:13, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
On 04/03/2022 10:46, Julien Grall wrote:
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
When the data abort is caused due to cache maintenance
On 04/03/2022 14:46, Andrea Stevanato wrote:
> On 3/4/2022 1:27 PM, Roger Pau Monné wrote:
>> On Fri, Mar 04, 2022 at 01:05:55PM +0100, Andrea Stevanato wrote:
>>> On 3/4/2022 12:52 PM, Roger Pau Monné wrote:
On Thu, Mar 03, 2022 at 01:08:31PM -0500, Jason Andryuk wrote:
> On Thu, Mar 3,
Trigger Huang writes:
> Hello,
>
> I have built & installed Xen 4.15 onto my Ubuntu20.04 platform successfully
> according to
> https://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
> After reboot, I entered Domain 0 successfully. The command xl info shows the
> right version string.
>
98 matches
Mail list logo
