From: Shannon Zhao
If Xen guest boots with ACPI, the guest kernel will get the event
channel interrupt information via domain param HVM_PARAM_CALLBACK_IRQ.
Initialize that domain param.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 8 +++-
1 file changed, 7 insertions(+), 1 del
From: Shannon Zhao
Add ACPI tables relevant definitions for generating ACPI tables for ARM
guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
be used.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/acpi_defs.h | 277
1 file ch
From: Shannon Zhao
Assign the guest memory space for ACPI tables and replace the reg in DT
with real values.
Signed-off-by: Shannon Zhao
---
tools/libxc/xc_dom_arm.c | 16 +++-
tools/libxl/libxl_arm.c | 40
2 files changed, 55 insertions(+)
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 84ea8b6..1bef9b0 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1082
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index f72f692..84ea8b6 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0fb4f69..c3b8fb4 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@
From: Shannon Zhao
The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.
Then, it copies these ACPI tables to DomU memory space and passes
them to UEFI firmware through the "ARM multiboot" prot
From: Shannon Zhao
Copy all the ACPI tables to guest memory space and also initialize the
address of the tables.
Signed-off-by: Shannon Zhao
---
tools/libxc/xc_dom_core.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/tools/libxc/xc_dom_cor
From: Shannon Zhao
Construct GTDT table with the interrupt information of timers.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 75 -
1 file changed, 74 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/x
From: Shannon Zhao
It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 1195b37..c6d77e3 100644
-
From: Shannon Zhao
Currently there is only the table header in DSDT table.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index c3b8fb4..7949635 100644
--- a/tools/li
From: Shannon Zhao
According to the gic version, construct the MADT table.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 107
1 file changed, 107 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 794
From: Shannon Zhao
Factor out codes for generating DTB to prepare for adding ACPI tables
generation codes.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl
From: Shannon Zhao
Add the ARM Multiboot module for ACPI, so UEFI can get the base address
of ACPI tables from it.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 20
1 file changed, 20 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
From: Shannon Zhao
Add ACPI support for Virt Xen ARM and it gets the ACPI tables through
Xen ARM multiboot protocol.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shannon Zhao
---
The corresponding Xen patches can be fetched from:
http://git.linaro.org/people/shannon.zh
flight 94966 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94966/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REG
Sorry, I Cc'ed the wrong email address of Wei Liu. I'll resend these
patches. Please ignore these ones.
On 2016/5/31 12:43, Shannon Zhao wrote:
> From: Shannon Zhao
>
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> nu
From: Shannon Zhao
Factor out codes for generating DTB to prepare for adding ACPI tables
generation codes.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl
From: Shannon Zhao
Add ACPI tables relevant definitions for generating ACPI tables for ARM
guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
be used.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/acpi_defs.h | 277
1 file ch
From: Shannon Zhao
Assign the guest memory space for ACPI tables and replace the reg in DT
with real values.
Signed-off-by: Shannon Zhao
---
tools/libxc/xc_dom_arm.c | 16 +++-
tools/libxl/libxl_arm.c | 40
2 files changed, 55 insertions(+)
From: Shannon Zhao
Add the ARM Multiboot module for ACPI, so UEFI can get the base address
of ACPI tables from it.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 20
1 file changed, 20 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
From: Shannon Zhao
According to the gic version, construct the MADT table.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 107
1 file changed, 107 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 794
From: Shannon Zhao
Copy all the ACPI tables to guest memory space and also initialize the
address of the tables.
Signed-off-by: Shannon Zhao
---
tools/libxc/xc_dom_core.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/tools/libxc/xc_dom_cor
From: Shannon Zhao
Construct GTDT table with the interrupt information of timers.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 75 -
1 file changed, 74 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 84ea8b6..1bef9b0 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1082
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/x
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index f72f692..84ea8b6 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@
From: Shannon Zhao
If Xen guest boots with ACPI, the guest kernel will get the event
channel interrupt information via domain param HVM_PARAM_CALLBACK_IRQ.
Initialize that domain param.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 8 +++-
1 file changed, 7 insertions(+), 1 del
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0fb4f69..c3b8fb4 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@
From: Shannon Zhao
Currently there is only the table header in DSDT table.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index c3b8fb4..7949635 100644
--- a/tools/li
From: Shannon Zhao
It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 1195b37..c6d77e3 100644
-
From: Shannon Zhao
The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.
Then, it copies these ACPI tables to DomU memory space and passes
them to UEFI firmware through the "ARM multiboot" prot
Grant copy operation is divided into two phases different for
'read' and 'write' operation.
For a 'read' operation the flow is as follow:
1. allocate local buffers for all the segments contained in
a request.
2. fill the request io vectors with the buffers' addresses
3. invoke r
If there are still pending requests the buffers are not free() but
cached in an array of a size max_request*BLKIF_MAX_SEGMENTS_PER_REQUEST
---
hw/block/xen_disk.c | 60 +
1 file changed, 47 insertions(+), 13 deletions(-)
diff --git a/hw/block/x
Implentation of interface to grant copy operation called through
libxc. An ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is
invoked for linux. In the mini-os the operation is yet not
implemented.
* In the file "tools/include/xen-sys/Linux/gntdev.h" added
- 'struct ioctl_gntdev_grant_cop
Grant mapping related functions and variables are removed
on behalf of grant copy operation introduced in following commits.
---
hw/block/xen_disk.c | 284 ++--
1 file changed, 10 insertions(+), 274 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw
Hi,
The patches are resend with split of patch #2.
It is a proposition for implementation of the replacement of the grant map
operation with grant copy.
I would appreciate an opinion about the approach if is proper or maybe
I assumed something wrongly, and if you see any possibility of improv
flight 94963 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94963/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
In AArch32, MPIDR bit 31 is defined as multiprocessing extensions bit.
But in AArch64, this bit is always RES1. So the value check for this
bit is no longer necessary in AArch64.
Signed-off-by: Wei Chen
Reviewed-by: Julien Grall
---
v3-->v4:
1. Add missed Reviewed-by tag.
v2--v3:
1. Fix a typo
In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
as 32-bit register.
We have to provide correct accessing to this register to avoid
unexpected issues that is caused by incorrect MPIDR value.
Wei Chen (4):
xe
The original affinity shift bits algorithm in AFFINITY_MASK is buggy,
it could not generate correct affinity shift bits of level3.
The macro MPIDR_LEVEL_SHIFT can calculate level3 affinity shift bits
correctly. We use this macro in AFFINITY_MASK to generate correct
mask for level3.
Signed-off-by:
Currently, MPIDR_HWID_MASK is using the bit definition of AArch32
MPIDR register. But from D7.2.67 of ARM ARM (DDI 0487A.i) we can see
there are 4 levels of affinity on AArch64 whilst AArch32 has only 3.
So, this value is not correct when Xen is running on AArch64.
Now, we use the value 0xff00
The cpu_logical_map is used to store CPU hardware ID from MPIDR_EL1 or
from CPU node of DT. Currently, the cpu_logical_map is using the u32 as
its variable type. It can work properly while Xen is running on ARM32,
because the hardware ID is 32-bits. While Xen is running on ARM64, the
hardware ID ex
Hi Stefano,
On 30 May 2016 at 21:24, Stefano Stabellini wrote:
> On Mon, 30 May 2016, Wei Chen wrote:
>> In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
>> bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
>> as 32-bit register.
>> We have to provide correc
On 2016/5/31 3:45, Julien Grall wrote:
> (CC Wei Liu)
>
> Hi Stefano,
>
> On 30/05/2016 14:16, Stefano Stabellini wrote:
>> On Fri, 27 May 2016, Julien Grall wrote:
>>> Hello Shanker,
>>>
>>> On 27/05/16 01:39, Shanker Donthineni wrote:
Commit 9d77b3c01d1261c (Configure SPI interrupt type
flight 94964 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94964/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REG
flight 94959 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94959/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 94943
build-i386-rumpuserxen
Hi Peng,
On 27/05/2016 06:31, Peng Fan wrote:
To ARM64, setup_xenheap_mappings may call alloc_boot_pages to allocate
first level page table, if there is a big chunk memory (ie, >512GB).
Out of interest, have you found the bug by testing Xen on a platform
with 512GB of RAM? :)
So, need to m
On Mon, May 30, 2016 at 3:35 PM, Julien Grall wrote:
>
>
> On 30/05/2016 21:37, Tamas K Lengyel wrote:
>>
>> On Mon, May 30, 2016 at 2:20 PM, Julien Grall
>> wrote:
>>>
>>> Hi Tamas,
>>>
>>> On 30/05/2016 20:47, Tamas K Lengyel wrote:
On Mon, May 30, 2016 at 5:50 AM, Jan Beulich w
On 30/05/2016 21:37, Tamas K Lengyel wrote:
On Mon, May 30, 2016 at 2:20 PM, Julien Grall wrote:
Hi Tamas,
On 30/05/2016 20:47, Tamas K Lengyel wrote:
On Mon, May 30, 2016 at 5:50 AM, Jan Beulich wrote:
+struct vm_event_regs_arm64 {
+uint64_t x0;
+uint64_t x1;
+uint64_t x2;
>>> @@ -3393,8 +3409,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>> }
>>> else {
>>> int handled =
>>> -hvm_monitor_breakpoint(regs->eip,
>>> -
>>> HVM_MONITOR_SOFTWARE_BREAKPOIN
On Mon, May 30, 2016 at 2:46 PM, Razvan Cojocaru
wrote:
> On 05/30/16 23:37, Tamas K Lengyel wrote:
>> Well, as we discussed it in the previous revision, there is no
>> hard-set rule of what can and cannot be transmitted here. The only
>> thing to keep in mind is to not grow this struct to be too
On 05/30/16 23:37, Tamas K Lengyel wrote:
> Well, as we discussed it in the previous revision, there is no
> hard-set rule of what can and cannot be transmitted here. The only
> thing to keep in mind is to not grow this struct to be too large. The
> registers sent right now represent a "best guess"
With staging-4.6 this domU boots from xvda, qemu creates an emulated
disk. With staging no disk is found, unless the name is changed to hda.
Looks like qemu-2.6 does not handle xvda either.
Is such setup not part of OSS test, does OSS default to 'vdev=hda'?
Olaf
name="domU"
uuid="64dfa382-6365-4
On Mon, May 30, 2016 at 2:20 PM, Julien Grall wrote:
> Hi Tamas,
>
> On 30/05/2016 20:47, Tamas K Lengyel wrote:
>>
>> On Mon, May 30, 2016 at 5:50 AM, Jan Beulich wrote:
+struct vm_event_regs_arm64 {
+uint64_t x0;
+uint64_t x1;
+uint64_t x2;
+uint64_
flight 94961 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94961/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REG
Hello,
>> I used FreeRTOS code for console output. It is based on Mini OS code. There
>> are two problems as I've >determined
>> with debugging. First is that vsnprintf blocks for some reason in print
>> function so i commented it out. After the
>snprintf blocks...
>> hypercall function block
Hi Tamas,
On 30/05/2016 20:47, Tamas K Lengyel wrote:
On Mon, May 30, 2016 at 5:50 AM, Jan Beulich wrote:
+struct vm_event_regs_arm64 {
+uint64_t x0;
+uint64_t x1;
+uint64_t x2;
+uint64_t x3;
+uint64_t x4;
+uint64_t x5;
+uint64_t x6;
+uint64_t x7;
+uint64_t
On Mon, May 30, 2016 at 8:16 AM, Jan Beulich wrote:
On 30.05.16 at 00:37, wrote:
>> @@ -117,7 +133,11 @@ int hvm_monitor_breakpoint(unsigned long rip,
>>
>> req.vcpu_id = curr->vcpu_id;
>>
>> -return vm_event_monitor_traps(curr, 1, &req);
>> +rc = vm_event_monitor_traps(curr, sy
On Mon, May 30, 2016 at 5:50 AM, Jan Beulich wrote:
On 30.05.16 at 00:37, wrote:
>> +struct vm_event_regs_arm32 {
>> +uint32_t r0_usr;
>> +uint32_t r1_usr;
>> +uint32_t r2_usr;
>> +uint32_t r3_usr;
>> +uint32_t r4_usr;
>> +uint32_t r5_usr;
>> +uint32_t r6_usr;
>>
(CC Wei Liu)
Hi Stefano,
On 30/05/2016 14:16, Stefano Stabellini wrote:
On Fri, 27 May 2016, Julien Grall wrote:
Hello Shanker,
On 27/05/16 01:39, Shanker Donthineni wrote:
Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
Dom0 dynamically) causing dead loop inside the spinlo
On Mon, May 30, 2016 at 4:13 AM, Jan Beulich wrote:
On 30.05.16 at 09:13, wrote:
>> On 05/13/2016 02:35 PM, Jan Beulich wrote:
>> On 06.05.16 at 16:33, wrote:
Previously, subscribing to MSR write events was an all-or-none
approach, with special cases for introspection MSR-s. T
flight 94958 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94958/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
flight 94957 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94957/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REG
Hi Stefano,
On 30/05/2016 15:45, Stefano Stabellini wrote:
On Mon, 23 May 2016, Julien Grall wrote:
Hi Stefano,
On 21/05/16 16:09, Stefano Stabellini wrote:
On Thu, 5 May 2016, Julien Grall wrote:
+void __init apply_alternatives_all(void)
+{
+int ret;
+
+ /* better not try code pat
Hi Stefano,
On 30/05/2016 16:02, Stefano Stabellini wrote:
On Mon, 23 May 2016, Julien Grall wrote:
After each CPU has been started, we iterate through a list of CPU
errata to detect CPUs which need from hypervisor code patches.
For each bug there is a function which check if that a particular
On 30/05/2016 17:19, Stefano Stabellini wrote:
"Erratum #834220: Xen needs to check that the Stage 1 translation does not
generate a fault before handling Stage 2 fault. If it is a stage 1 translation
fault, return to the guest to let the project injecting the correct fault.
XXX: This can be o
Hello,
The following series attempts to fix the build issue introduced by
7fb252bd41, and to make sure the same assembler is used thorough all the
build process. It also supersedes the fix by Jan Beulich for this same issue
[0].
Roger.
[0] http://lists.xenproject.org/archives/html/xen-devel/2
For all the build process, not only the assembly-only files.
This prevents assembling certain code with the integrated assembler, while
other code would be assembled by the external assembler.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beuli
The test code is a C file with inline assembly, not plain assembly.
This fixes the fallout introduced by commit 7fb252bd41 ("build/xen: fix
assembler instruction tests")
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszute
On Mon, 30 May 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 30/05/2016 16:11, Stefano Stabellini wrote:
> > On Mon, 23 May 2016, Julien Grall wrote:
> > > The ARM erratum applies to certain revisions of Cortex-A57. The
> > > processor may report a Stage 2 translation fault as the result of
> > >
Hi Stefano,
On 30/05/2016 16:11, Stefano Stabellini wrote:
On Mon, 23 May 2016, Julien Grall wrote:
The ARM erratum applies to certain revisions of Cortex-A57. The
processor may report a Stage 2 translation fault as the result of
Stage 1 fault for load crossing a page boundary when there is a
p
On Tue, 24 May 2016, Peter Maydell wrote:
> Clean up includes so that osdep.h is included first and headers
> which it implies are not included manually.
>
> This commit was created with scripts/clean-includes.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Stefano Stabellini
Added to my queue
On Mon, 23 May 2016, Julien Grall wrote:
> The ARM erratum applies to certain revisions of Cortex-A57. The
> processor may report a Stage 2 translation fault as the result of
> Stage 1 fault for load crossing a page boundary when there is a
> permission fault or device memory fault at stage 1 and a
On Mon, 23 May 2016, Julien Grall wrote:
> The new document will help to keep track of all the erratum that Xen is
> able to handle.
>
> The text is based on the Linux doc in Documents/arm64/silicon-errata.txt.
>
> Also list the current errata that Xen is aware of.
>
> Signed-off-by: Julien Gral
On Mon, 23 May 2016, Julien Grall wrote:
> After each CPU has been started, we iterate through a list of CPU
> errata to detect CPUs which need from hypervisor code patches.
>
> For each bug there is a function which check if that a particular CPU is
> affected. This needs to be done on every CPUs
On Mon, 23 May 2016, Julien Grall wrote:
> Based on ARM ARM (D4.5.3 in ARM DDI 0486A and B3.12.7 in ARM DDI 0406C.c),
> a Stage 1 translation error has priority over a Stage 2 translation error.
>
> Therefore gva_to_ipa can only fail if another vCPU is playing with the
> page table.
>
> Rather th
On Mon, 23 May 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 21/05/16 16:09, Stefano Stabellini wrote:
> > On Thu, 5 May 2016, Julien Grall wrote:
> > > +void __init apply_alternatives_all(void)
> > > +{
> > > +int ret;
> > > +
> > > + /* better not try code patching on a live SMP system */
>
flight 94956 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94956/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Mon, 23 May 2016, Julien Grall wrote:
> We may need to update branch instruction when patching Xen.
>
> The code has been imported from the files arch/arm64/kernel/insn.c
> and arch/arm64/include/asm/insn.h in Linux v4.6.
>
> Note that only the necessary helpers have been imported.
>
> Signed
On Mon, 23 May 2016, Julien Grall wrote:
> This will be used to know if a feature, which Xen cares, is available accross
> all the CPUs.
>
> This code is a light version of arch/arm64/kernel/cpufeature.c from
> Linux v4.6-rc3.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
>
>>> On 30.05.16 at 00:37, wrote:
> @@ -117,7 +133,11 @@ int hvm_monitor_breakpoint(unsigned long rip,
>
> req.vcpu_id = curr->vcpu_id;
>
> -return vm_event_monitor_traps(curr, 1, &req);
> +rc = vm_event_monitor_traps(curr, sync, &req);
> +if ( type == HVM_MONITOR_DEBUG_EXCEPTI
>>> On 30.05.16 at 00:37, wrote:
> Mechanical renaming and relocation to the monitor subsystem.
>
> Signed-off-by: Tamas K Lengyel
Non-VM-event parts
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-
>>> On 30.05.16 at 00:37, wrote:
> Mechanical renaming to better describe that the code in hvm/event is part of
> the monitor subsystem.
>
> Signed-off-by: Tamas K Lengyel
> Acked-by: Kevin Tian
General x86/hvm parts
Acked-by: Jan Beulich
___
Xen-
Rather than just allowing a fixed address or fully automatic placement,
also allow for specifying an upper bound. Especially on EFI systems,
where firmware memory use is commonly less predictable than on legacy
BIOS ones, this makes success of the reservation more likely when
automatic placement is
On Mon, 30 May 2016, Wei Chen wrote:
> In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
> bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
> as 32-bit register.
> We have to provide correct accessing to this register to avoid
> unexpected issues that is cause
flight 94949 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
On Fri, 27 May 2016, Julien Grall wrote:
> Hello Shanker,
>
> On 27/05/16 01:39, Shanker Donthineni wrote:
> > Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
> > Dom0 dynamically) causing dead loop inside the spinlock function.
> > Note that spinlocks in XEN are not recursive. R
flight 94952 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94952/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REG
Considering that we surface MPX to HVM guests, instructions we emulate
should also correctly deal with MPX state. While for now BND*
instructions don't get emulated, the effect of branches (which we do
emulate) without BND prefix should be taken care of.
Signed-off-by: Jan Beulich
---
RFC reasons
On 30/05/2016 13:08, Julien Grall wrote:
On 30/05/2016 13:00, Stefano Stabellini wrote:
On Fri, 27 May 2016, Julien Grall wrote:
Hello Shanker,
On 27/05/16 15:01, Shanker Donthineni wrote:
On 05/27/2016 08:04 AM, Julien Grall wrote:
On 27/05/16 01:28, Shanker Donthineni wrote:
The ARM S
On 30/05/2016 13:00, Stefano Stabellini wrote:
On Fri, 27 May 2016, Julien Grall wrote:
Hello Shanker,
On 27/05/16 15:01, Shanker Donthineni wrote:
On 05/27/2016 08:04 AM, Julien Grall wrote:
On 27/05/16 01:28, Shanker Donthineni wrote:
The ARM Server Base System Architecture describes a g
On Fri, 27 May 2016, Julien Grall wrote:
> Hello Shanker,
>
> On 27/05/16 15:01, Shanker Donthineni wrote:
> > On 05/27/2016 08:04 AM, Julien Grall wrote:
> > > On 27/05/16 01:28, Shanker Donthineni wrote:
> > > > The ARM Server Base System Architecture describes a generic UART
> > > > interface.
The dma-mapping core and the implementations do not change the
DMA attributes passed by pointer. Thus the pointer can point to const
data. However the attributes do not have to be a bitfield. Instead
unsigned long will do fine:
1. This is just simpler. Both in terms of reading the code and sett
On Fri, May 27, 2016 at 05:06:19PM +0100, Julien Grall wrote:
> Hello all,
>
> This series is based on the thread [1]. To allow future extension, the new
> space dev_mmio should have all unused fields marked as reserved.
>
> This series is candidate for Xen 4.7, the first patch ensure a clean ABI
Hi,
This is second attempt to bring some safeness to dma_attrs.
In v1 [0] I added const to data pointed by attrs. However Christoph
Hellwig suggested getting rid of struct dma_attrs in favor of
some simpler data type.
Benefits of unsigned long for dma_attrs:
1. This is just simpler. Both in te
>>> On 27.05.16 at 18:06, wrote:
> The field 'foreign_id' is not used when the space is dev_mmio. As the
> space is not yet part of the stable ABI, the field is marked as reserved
> for future use.
>
> The value should always be 0, other values will return -EOPNOTSUPP.
>
> Signed-off-by: Julien
>>> On 30.05.16 at 00:37, wrote:
> +struct vm_event_regs_arm32 {
> +uint32_t r0_usr;
> +uint32_t r1_usr;
> +uint32_t r2_usr;
> +uint32_t r3_usr;
> +uint32_t r4_usr;
> +uint32_t r5_usr;
> +uint32_t r6_usr;
> +uint32_t r7_usr;
> +uint32_t r8_usr;
> +uint32_t r
On Fri, 27 May 2016, Julien Grall wrote:
> Hello all,
>
> This small patch series converts DEBUG_DT to Kconfig. This is easier
> to enable than having to modify the code when the user wants to debug
> the device tree parsing.
>
> This series is based on the version 4 of "Kconfig debug options" [1
1 - 100 of 118 matches
Mail list logo
