This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.11 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
flight 118447 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118447/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118394
test-armhf-armhf-libvirt 14 saveresto
On 30/01/18 20:26, Andrew Cooper wrote:
> However, there is literally nothing we can do to prevent #MC from
> arriving. We can stop servicing #MC by disabling CR4.MCE, but then the
> processor will shut down.
Hmm, there is a way to avoid #MC on other processors, but this
requires the really big h
flight 118446 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118446/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 broken in 118369
test-a
On 01/30/2018 11:53 AM, Oleksandr Tyshchenko wrote:
I'm wondering what the GPU would like to the guest. Would it be the same
interface as on a native machine, or would I need PV drivers?
It depends on what guest domain contains.
If DomU has both Display Unit and GPU assigned then PV driver is
flight 118445 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118445/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
test-amd64-amd64-xl
Initially submitted here: http://elrepo.org/bugs/view.php?id=820
No issues with the latest 4.14.1x versions. The crash replicates on 3
hypervisors:
- CentOS 7.4 running kernel 4.9.77-30.el7.x86_64 and
xen-4.6.6-9.el7.x86_64 on Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
- CentOS 7.4 running kernel
Hi Manish,
I am testing Xen support in ThunderX, but I am having some issues
booting Dom0 using Xen staging and the Ubuntu Xenial kernel (it has
CONFIG_XEN enabled). The trace is appened to this email. I am using the
device tree converted from /proc/device-tree on the running system
without Xen.
The ocaml safe-strings patch uses code introduced in ocaml 4.02
so update the minimal version.
Signed-off-by: Michael Young
---
stubdom/configure| 4 ++--
stubdom/configure.ac | 2 +-
tools/configure | 2 +-
tools/configure.ac | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
Xen built with ocaml 4.06 gives errors such as
Error: This expression has type bytes but an expression was
expected of type string
as Byte and safe-strings which were introduced in 4.02 are the
default in 4.06.
This patch which is partly by Richard W.M. Jones of Red Hat
from https://bugzil
On 30/01/18 19:04, Stefano Stabellini wrote:
> On Tue, 30 Jan 2018, Andre Przywara wrote:
>> At the moment we re-generate the Dom0 GICv3 DT node, by creating the
>> "reg" property from scratch using our previously parsed and
>> translated(!) host addresses. However we then write the *absolute*
>> a
flight 118460 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118460/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 30 January 2018 at 19:35, Volodymyr Babchuk
wrote:
>
>
> On 30.01.18 20:44, Julien Grall wrote:
>>
>>
>>
>> On 30/01/18 18:28, Volodymyr Babchuk wrote:
>>>
>>> Hi Julien,
>>>
>>> On 30.01.18 20:01, Julien Grall wrote:
On 26/01/18 18:27, Volodymyr Babchuk wrote:
>
> H
flight 118448 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118448/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
flight 118459 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118459/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi
On Tue, Jan 30, 2018 at 2:22 AM, Martin Kelly wrote:
> On 01/29/2018 08:31 AM, Oleksandr Tyshchenko wrote:
>>
>> Hi
>>
>> On Sat, Jan 27, 2018 at 2:41 AM, Martin Kelly wrote:
>>>
>>> On 01/26/2018 10:13 AM, Oleksandr Tyshchenko wrote:
Hi, Martin
On Fri, Jan 26, 2018 a
On 30.01.18 20:44, Julien Grall wrote:
On 30/01/18 18:28, Volodymyr Babchuk wrote:
Hi Julien,
On 30.01.18 20:01, Julien Grall wrote:
On 26/01/18 18:27, Volodymyr Babchuk wrote:
Hi,
Hi Volodymyr,
On 26.01.18 20:15, Julien Grall wrote:
Hi,
On 26/01/18 18:09, Volodymyr Babchuk wrote:
On 30/01/18 08:39, Jan Beulich wrote:
On 29.01.18 at 16:38, wrote:
>> +bool init_or_livepatch text_poke_live(const struct cpu_user_regs *regs)
>> +{
>> +struct live_poke_info *i = &live_poke_info;
>> +
>> +if ( unlikely(i->cpu != smp_processor_id()) )
>> +{
>> +ASSERT(regs
On 30/01/18 19:21, Stefano Stabellini wrote:
> On Tue, 30 Jan 2018, Julien Grall wrote:
>> Hi,
>>
>> On 30/01/18 18:29, Andrew Cooper wrote:
>>> On 30/01/18 17:00, Julien Grall wrote:
On 30/01/18 16:38, Andrew Cooper wrote:
> On 30/01/18 16:14, Julien Grall wrote:
>> Hi all,
>
On Tue, 30 Jan 2018, Julien Grall wrote:
> Hi,
>
> On 30/01/18 18:29, Andrew Cooper wrote:
> > On 30/01/18 17:00, Julien Grall wrote:
> > >
> > >
> > > On 30/01/18 16:38, Andrew Cooper wrote:
> > > > On 30/01/18 16:14, Julien Grall wrote:
> > > > > Hi all,
> > > > >
> > > > > This small series
On 30/01/18 18:46, Julien Grall wrote:
> Hi,
>
> On 30/01/18 18:29, Andrew Cooper wrote:
>> On 30/01/18 17:00, Julien Grall wrote:
>>>
>>>
>>> On 30/01/18 16:38, Andrew Cooper wrote:
On 30/01/18 16:14, Julien Grall wrote:
> Hi all,
>
> This small series replaces all call to domain_
On Tue, 30 Jan 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 30/01/18 18:14, Stefano Stabellini wrote:
> > On Tue, 30 Jan 2018, Julien Grall wrote:
> > > Currently, Xen is considering that an IO could either be handled or
> > > unhandled. When unhandled, the stage-2 abort function will try anothe
On Tue, 30 Jan 2018, Andre Przywara wrote:
> At the moment we re-generate the Dom0 GICv3 DT node, by creating the
> "reg" property from scratch using our previously parsed and
> translated(!) host addresses. However we then write the *absolute*
> addresses into the new node, not considering possibl
Roger Pau [Monn_] wrote:
> On Fri, Jan 26, 2018 at 01:54:30PM -0600, Michael Glasgow wrote:
> > This recent patch can be simplified a bit. (The patch below is
> > untested, just a suggestion.)
>
> Thanks, this LGTM, but it needs your Signed-off-by tag in order to be
> applied.
Simplify posix-fri
Hi,
On 30/01/18 18:29, Andrew Cooper wrote:
On 30/01/18 17:00, Julien Grall wrote:
On 30/01/18 16:38, Andrew Cooper wrote:
On 30/01/18 16:14, Julien Grall wrote:
Hi all,
This small series replaces all call to domain_crash_synchronous by
injecting
an exception to the guest.
This will resul
On 30/01/18 18:28, Volodymyr Babchuk wrote:
Hi Julien,
On 30.01.18 20:01, Julien Grall wrote:
On 26/01/18 18:27, Volodymyr Babchuk wrote:
Hi,
Hi Volodymyr,
On 26.01.18 20:15, Julien Grall wrote:
Hi,
On 26/01/18 18:09, Volodymyr Babchuk wrote:
On 24.01.18 20:34, Julien Grall wrote:
On 30/01/18 17:00, Julien Grall wrote:
>
>
> On 30/01/18 16:38, Andrew Cooper wrote:
>> On 30/01/18 16:14, Julien Grall wrote:
>>> Hi all,
>>>
>>> This small series replaces all call to domain_crash_synchronous by
>>> injecting
>>> an exception to the guest.
>>>
>>> This will result to a nicer trac
Hi Stefano,
On 30/01/18 18:14, Stefano Stabellini wrote:
On Tue, 30 Jan 2018, Julien Grall wrote:
Currently, Xen is considering that an IO could either be handled or
unhandled. When unhandled, the stage-2 abort function will try another
way to resolve the abort.
However, the MMIO emulation may
Hi Julien,
On 30.01.18 20:01, Julien Grall wrote:
On 26/01/18 18:27, Volodymyr Babchuk wrote:
Hi,
Hi Volodymyr,
On 26.01.18 20:15, Julien Grall wrote:
Hi,
On 26/01/18 18:09, Volodymyr Babchuk wrote:
On 24.01.18 20:34, Julien Grall wrote:
- case PSCI_0_2_FN32(AFFINITY_INFO):
- ca
On 30/01/18 18:24, Stefano Stabellini wrote:
On Tue, 30 Jan 2018, Julien Grall wrote:
domain_crash_synchronous() should only be used when something went wrong
in Xen. It is better to inject to the guest as it will be in better
^ a
On Tue, 30 Jan 2018, Julien Grall wrote:
> domain_crash_synchronous() should only be used when something went wrong
> in Xen. It is better to inject to the guest as it will be in better
^ a better
> position to provide helpful informat
Xen does not properly support big.LITTLE platform. All vCPUs of a guest
will always have the MIDR of the boot CPU (see arch_domain_create).
At best the guest may see unreliable performance (vCPU switching between
big and LITTLE), at worst the guest will become unreliable or insecure.
This is becom
On Tue, 30 Jan 2018, Julien Grall wrote:
> Now the MMIO emulation is able to distinguish unhandled IO from aborted
> one, there are no need to crash the domain when the region is access
> with a bad width.
>
> Instead let Xen inject a data abort to the guest and decide what to do.
>
> Signed-off-
On Tue, 30 Jan 2018, Julien Grall wrote:
> Currently, Xen is considering that an IO could either be handled or
> unhandled. When unhandled, the stage-2 abort function will try another
> way to resolve the abort.
>
> However, the MMIO emulation may return unhandled when the address
> belongs to an
On 26/01/18 18:27, Volodymyr Babchuk wrote:
Hi,
Hi Volodymyr,
On 26.01.18 20:15, Julien Grall wrote:
Hi,
On 26/01/18 18:09, Volodymyr Babchuk wrote:
On 24.01.18 20:34, Julien Grall wrote:
- case PSCI_0_2_FN32(AFFINITY_INFO):
- case PSCI_0_2_FN64(AFFINITY_INFO):
+ switch ( fid )
On Wed, 24 Jan 2018, Julien Grall wrote:
> There are firmware tables out describing the ITS but does not support
> LPIs. This will result to a data abort when trying to initialize ITS.
>
> While this can be consider a bug in the Device-Tree, same configuration
> boots on Linux. So gate the ITS ini
On Wed, 24 Jan 2018, Julien Grall wrote:
> There are Device Tree (e.g for the Foundation Model) out that describes the
> ITS but LPIs is not supported by the platform. Booting with such DT will
> result to an early Data Abort. The same DT is booting fine with a
> baremetal Linux because ITS will b
The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based communication.
This patch introduces XENMAPS
Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:
* For a master: decrease the refcount of the sshm region, if the refcount
reaches 0, cleanup the whole sshm path.
* For a slave: 1) unmap the shared pages, and clea
Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file" (see [1]).
[1] https:/
Add docs to document the motivation, usage, use cases and other
relevant information about the static shared memory feature.
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:
https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Add a new structure to the IDL familiy to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
And deleted some trailing white spaces.
[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242
Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the follwing steps:
* Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
not page aligned, no master domain etc.
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:
https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
one domU to another and use XENMEM_remove_from_p
Hi,
This series implements the new xl config entry proposed in [1]. Users can use
the new config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each other
through the static shared memory areas.
After several rounds
On 30/01/18 17:33, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> When scheduling a vcpu subject to xpti activate the per-vcpu stacks
>> by loading the vcpu specific gdt and tss. When de-scheduling such a
>> vcpu switch back to the per physical cpu gdt and tss.
>>
>> Accessing the user re
On Wed, 24 Jan 2018, Andre Przywara wrote:
> In gic_restore_pending_irqs() we push our pending virtual IRQs into the
> list registers. This function is called once from gic_inject(), just
> before we return to the guest, but also in gic_restore_state(), when
> we context-switch a VCPU. Having a clo
On 30/01/18 17:07, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> --- a/xen/arch/x86/x86_64/asm-offsets.c
>> +++ b/xen/arch/x86/x86_64/asm-offsets.c
>> @@ -137,6 +137,10 @@ void __dummy__(void)
>> OFFSET(CPUINFO_processor_id, struct cpu_info, processor_id);
>> OFFSET(CPUINFO_cur
On 30/01/18 16:40, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> In case of XPTI being active for a pv-domain allocate and initialize
>> per-vcpu stacks. The stacks are added to the per-domain mappings of
>> the pv-domain.
>
> Considering the intended use of these stacks (as per the ove
On 30/01/18 16:38, Andrew Cooper wrote:
On 30/01/18 16:14, Julien Grall wrote:
Hi all,
This small series replaces all call to domain_crash_synchronous by injecting
an exception to the guest.
This will result to a nicer trace from the guest (no need to manually walk
the stack) and give a chan
On 30/01/18 16:39, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> @@ -212,6 +249,24 @@ int pv_domain_initialise(struct domain *d, unsigned int
>> domcr_flags,
>> /* 64-bit PV guest by default. */
>> d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>>
>> +switch (opt_xp
On 30/01/18 16:11, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> --- a/xen/arch/x86/x86_64/traps.c
>> +++ b/xen/arch/x86/x86_64/traps.c
>> @@ -260,10 +260,11 @@ void do_double_fault(struct cpu_user_regs *regs)
>> panic("DOUBLE FAULT -- system shutdown");
>> }
>>
>> -static unsign
On 30/01/18 16:14, Julien Grall wrote:
> Hi all,
>
> This small series replaces all call to domain_crash_synchronous by injecting
> an exception to the guest.
>
> This will result to a nicer trace from the guest (no need to manually walk
> the stack) and give a chance to the guest to give a bit mor
On 30/01/18 15:49, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> In order to support switching stacks when entering the hypervisor for
>> support of page table isolation, don't use %rsp for accessing the
>> saved user registers, but do that via %rdi.
>
> If this really turns out to be n
>>> On 22.01.18 at 13:32, wrote:
> When scheduling a vcpu subject to xpti activate the per-vcpu stacks
> by loading the vcpu specific gdt and tss. When de-scheduling such a
> vcpu switch back to the per physical cpu gdt and tss.
>
> Accessing the user registers on the stack is done via helpers as
Currently, Xen is considering that an IO could either be handled or
unhandled. When unhandled, the stage-2 abort function will try another
way to resolve the abort.
However, the MMIO emulation may return unhandled when the address
belongs to an emulated range but was not correct. In that case, Xen
Now the MMIO emulation is able to distinguish unhandled IO from aborted
one, there are no need to crash the domain when the region is access
with a bad width.
Instead let Xen inject a data abort to the guest and decide what to do.
Signed-off-by: Julien Grall
---
xen/arch/arm/vgic-v2.c | 2 -
domain_crash_synchronous() should only be used when something went wrong
in Xen. It is better to inject to the guest as it will be in better
position to provide helpful information (stack trace...).
Signed-off-by: Julien Grall
---
We potentially want to return -1 instead. This would make Xe
Hi all,
This small series replaces all call to domain_crash_synchronous by injecting
an exception to the guest.
This will result to a nicer trace from the guest (no need to manually walk
the stack) and give a chance to the guest to give a bit more information on
what it was doing.
Cheers,
Julie
>>> On 22.01.18 at 13:32, wrote:
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -137,6 +137,10 @@ void __dummy__(void)
> OFFSET(CPUINFO_processor_id, struct cpu_info, processor_id);
> OFFSET(CPUINFO_current_vcpu, struct cpu_info, current_vcpu);
>
Julien Grall writes ("Re: [Xen-devel] [xen-unstable test] 118441: regressions -
trouble: blocked/broken/fail/pass"):
..
> failure (trapped): status 65280 at Osstest/TestSupport.pm line 486.
The real error is this:
Connection closed by 172.16.144.44 port 22
At 2018-01-29 19:15:29 Z. This is m
Hi all, (mentors on CC list)
a quick note that there are significant changes to Outreachy this year, which
in my view will make it a little harder to participate.
Namely
* This round, instead of having communities create landing pages on their own
websites or wikis coordinators and mentors will
Most users of decode_register() can be replaced with decode_gpr() right away.
For the few sites which do care about possibly using the legacy byteop
encoding, rename decode_register() to decode_gpr_byteop(), and adjust its 'int
highbyte_regs' parameter to the more correct 'bool legacy_byteop'.
Si
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
---
tools/tests/x86_emulator/test_x86_emulator.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/tests/x86_emulator/test_x86_emulator.c
b/tools/tests/x86_emulator/test_x86_emulator.c
index 7a8df41..850fba6 1
The positions of GPRs inside struct cpu_user_regs doesn't follow any
particular order, so as compiled, decode_register() becomes a jump table to 16
blocks which calculate the appropriate offset, at a total of 207 bytes.
Instead, pre-compute the offsets at build time and use pointer arithmetic to
c
* Rename to decode_gpr() to be more specific as to its purpose
* Drop the highbyte encoding handling, as no users currently care, and it
unlikely that future users would care.
* Change to a static inline, returning an unsigned long pointer.
Doing so highlights that the "invalid gpr" paths in
On 30/01/18 15:44, osstest service owner wrote:
flight 118441 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair
flight 118441 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pairbroken
build-armhf-xsm 6 xen-build
>>> On 22.01.18 at 13:32, wrote:
> In case of XPTI being active for a pv-domain allocate and initialize
> per-vcpu stacks. The stacks are added to the per-domain mappings of
> the pv-domain.
Considering the intended use of these stacks (as per the overview
mail) I consider 32k per vCPU a non-negl
>>> On 22.01.18 at 13:32, wrote:
> @@ -212,6 +249,24 @@ int pv_domain_initialise(struct domain *d, unsigned int
> domcr_flags,
> /* 64-bit PV guest by default. */
> d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>
> +switch (opt_xpti)
Style.
> +{
> +case XPTI_OFF:
>
>>> On 22.01.18 at 13:32, wrote:
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -260,10 +260,11 @@ void do_double_fault(struct cpu_user_regs *regs)
> panic("DOUBLE FAULT -- system shutdown");
> }
>
> -static unsigned int write_stub_trampoline(
> -unsigned
For our records.
14:41 Diziet: How long do we wait in off state when hard cycling the
box in the colo?
14:42 I think the default is quite short but there's a per-host
override.
14:43 Default is 5s. Some hosts have more.
14:44 Diziet: For softiron: Even though
>>> On 22.01.18 at 13:32, wrote:
> In order to support switching stacks when entering the hypervisor for
> support of page table isolation, don't use %rsp for accessing the
> saved user registers, but do that via %rdi.
If this really turns out to be necessary ...
> @@ -58,20 +58,24 @@ compat_tes
On Wed, Jan 24, 2018 at 06:10:58PM +, Andre Przywara wrote:
> On ARM the maximum number of IRQs is a constant, but we share it being
> a variable to match x86. Since we are not supposed to alter it, let's
> mark it as "const" to avoid accidental change.
>
> Suggested-by: Julien Grall
> Signed
On 23/01/18 10:38, Jan Beulich wrote:
> When XPTI is active, the CR3 load in restore_all_guest is sufficient
> when switching to user mode, improving in particular system call and
> page fault exit paths for the guest.
>
> Signed-off-by: Jan Beulich
While I can see the utility of this, we are sta
>>> On 30.01.18 at 13:02, wrote:
> On 23/01/18 10:37, Jan Beulich wrote:
>> Introduce a synthetic feature flag to use alternative instruction
>> patching to NOP out all code on entry/exit paths other than those
>> involved in NMI/#MC handling (the patching logic can't properly handle
>> those path
On 23/01/18 10:38, Jan Beulich wrote:
> toggle_guest_mode() is only ever being called for 64-bit PV vCPU-s -
> replace the 32-bit PV conditional by an ASSERT().
>
> Introduce a local helper without 32-bit PV conditional, to be used by
> both pre-existing functions.
>
> Signed-off-by: Jan Beulich
Hi
I am trying to passthrough the I2C bus[channel 2 group A] to DomU in
Xen. I am implementing this on R-Car H3.
I added xen,passthrough = "1" to the i2c2 node in r8a7795.dtsi and
rebuilt the dtb for Domain 0. The dtb works when I boot into Dom0, but
the kernel crashes when I try to boot again us
Hi Andre,
On 24/01/18 18:10, Andre Przywara wrote:
On ARM the maximum number of IRQs is a constant, but we share it being
a variable to match x86. Since we are not supposed to alter it, let's
mark it as "const" to avoid accidental change.
Suggested-by: Julien Grall
Signed-off-by: Andre Przywar
Hi Andre,
On 24/01/18 18:10, Andre Przywara wrote:
At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.
Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardwar
flight 118453 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118453/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 23/01/18 10:37, Jan Beulich wrote:
> Introduce a synthetic feature flag to use alternative instruction
> patching to NOP out all code on entry/exit paths other than those
> involved in NMI/#MC handling (the patching logic can't properly handle
> those paths yet). Having NOPs here is generally be
Hi Andre,
On 24/01/18 18:10, Andre Przywara wrote:
diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
new file mode 100644
index 00..98df84e3d5
--- /dev/null
+++ b/xen/arch/arm/gic-vgic.c
@@ -0,0 +1,410 @@
+/*
+ * xen/arch/arm/gic-vgic.c
+ *
+ * ARM Generic Interrupt Controll
Hi Andre,
On 24/01/18 18:10, Andre Przywara wrote:
In gic_restore_pending_irqs() we push our pending virtual IRQs into the
list registers. This function is called once from gic_inject(), just
before we return to the guest, but also in gic_restore_state(), when
we context-switch a VCPU. Having a
Hi Andrew,
On 30/01/18 11:24, Andrew Cooper wrote:
On 30/01/18 11:05, Julien Grall wrote:
Hi Andrew,
On 29/01/18 15:38, Andrew Cooper wrote:
On x86, we would like to alter how we patch based on whether there is
any
chance of the code being patched being concurrently executed.
prepare_payload
On 30/01/18 11:29, Julien Grall wrote:
> Hi Andrew,
>
> Thank you for doing the clean-up.
>
> On 30/01/18 11:16, Andrew Cooper wrote:
>> ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
>> !HAS_ALTERNATIVE code in include/asm-arm/alternative.h to bitrot to
>> the point
>> of fa
Hi Andrew,
Thank you for doing the clean-up.
On 30/01/18 11:16, Andrew Cooper wrote:
ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
!HAS_ALTERNATIVE code in include/asm-arm/alternative.h to bitrot to the point
of failing to compile.
Expand all the CONFIG_HAS_ALTERNATIVE
On 30/01/18 11:05, Julien Grall wrote:
> Hi Andrew,
>
> On 29/01/18 15:38, Andrew Cooper wrote:
>> On x86, we would like to alter how we patch based on whether there is
>> any
>> chance of the code being patched being concurrently executed.
>>
>> prepare_payload() passes false (as the livepatch def
ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
!HAS_ALTERNATIVE code in include/asm-arm/alternative.h to bitrot to the point
of failing to compile.
Expand all the CONFIG_HAS_ALTERNATIVE references in ARM code.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Ju
Hi Andre,
On 30/01/18 09:35, Andre Przywara wrote:
@@ -1173,27 +1172,21 @@ static int gicv3_make_hwdom_dt_node(const struct domain
*d,
if ( res )
return res;
-len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
+new_len = dt_cells_to_size(dt_n_addr_c
>>> On 30.01.18 at 12:01, wrote:
> On 23/01/18 10:36, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/asm_defns.h
>> +++ b/xen/include/asm-x86/asm_defns.h
>> @@ -206,13 +206,12 @@ void ret_from_intr(void);
>> #define ASM_STAC ASM_AC(STAC)
>> #define ASM_CLAC ASM_AC(CLAC)
>>
>> -.macro write_cr
Hi Andrew,
On 29/01/18 15:38, Andrew Cooper wrote:
On x86, we would like to alter how we patch based on whether there is any
chance of the code being patched being concurrently executed.
prepare_payload() passes false (as the livepatch definitely isn't live at this
point), whereas the boot-time
On 23/01/18 10:36, Jan Beulich wrote:
> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -206,13 +206,12 @@ void ret_from_intr(void);
> #define ASM_STAC ASM_AC(STAC)
> #define ASM_CLAC ASM_AC(CLAC)
>
> -.macro write_cr3 val:req, tmp1:req, tmp2:req
> -mo
Hi,
On 29/01/18 20:23, Stefano Stabellini wrote:
On Mon, 29 Jan 2018, Andrew Cooper wrote:
The !HAS_ALTERNATIVE case has bit-rotten and won't even compile.
The x86 side of apply_alternatives() is void, while the ARM side returns int.
However, the functions can't fail and no return values are c
On 30/01/18 01:33, Zhang, Xiong Y wrote:
> The message is really short. Dom0 error happens before the first kernel
> message:
>
> ▒ Xen 4.11-unstable
> (XEN) Xen version 4.11-unstable (test@) (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4)
> 5.4.0 20160609) debug=n Tue Jan 30 02:38:14 CST 2018
Aah, just
Hi,
Thanks for the patch.
On Tue, Jan 30, 2018 at 3:05 PM, Andre Przywara wrote:
> At the moment we re-generate the Dom0 GICv3 DT node, by creating the
> "reg" property from scratch using our previously parsed and
> translated(!) host addresses. However we then write the *absolute*
> addresses i
At the moment we re-generate the Dom0 GICv3 DT node, by creating the
"reg" property from scratch using our previously parsed and
translated(!) host addresses. However we then write the *absolute*
addresses into the new node, not considering possible "range" mappings
in any of the GIC's parent nodes
> On 28. Jan 2018, at 23:44, Michael Young wrote:
>
>>
>> I do not know if caml-stubdom uses any of these files, but it seems to use
>> ocaml-3.11.0?
>> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=stubdom/configure;h=a7a0c0915440b7b351a7adf4f40c8f9ee8e739ef;hb=refs/heads/staging#l3534
On Mon, Jan 29, 2018 at 09:50:56AM -0700, Jan Beulich wrote:
> >>> On 29.01.18 at 13:26, wrote:
> > Clang assembler doesn't support using .skip with non-absolute
> > expressions:
> >
> > entry.S:109:15: error: expected absolute expression
> > .skip .Lcr4_alt_end - .Lcr4_alt, 0x90
> >
On 01/30/2018 11:16 AM, Razvan Cojocaru wrote:
> On exit, xen-access did not unsubscribe from CR4 write vm_events,
> potentially leaving the guest stuck.
>
> Signed-off-by: Razvan Cojocaru
> ---
> tools/tests/xen-access/xen-access.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/too
1 - 100 of 109 matches
Mail list logo
