flight 109042 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
Hi Andre,
On 05/05/2017 10:02 AM, Andre Przywara wrote:
Hi,
On 04/05/17 17:21, Julien Grall wrote:
Hi Andre,
On 04/05/17 16:31, Andre Przywara wrote:
Introduce the proper locking sequence for the new pending_irq lock.
This takes the lock around multiple accesses to struct members,
also makes
flight 109020 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109020/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
Hi Julien,
+unsigned int vpl011_reg_mask[] = {0xff, 0x, 0x};
>>>
>>>
>>>
>>> This should be static. But I don't get what you need that. In the first
>>> version, I suggested to re-purpose vgic_reg*_{extract,update} so we can
>>> use
>>> it here. It would probably need to be rename
flight 109008 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109008/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-winxpsp3 5 xen-install fail in 108218 pass in 109008
test-armhf-armhf-xl-credit2
flight 109009 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-amd 19 guest-start/debian.repeat fail REGR. vs. 107900
test-amd64-i386-xl
flight 109029 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109029/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 108170
test-amd64-amd64-xl-qemuu-
> >>> On 05.05.17 at 05:52, wrote:
> > 'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
> > outstanding p2m_ioreq_server entries")' will call
> > p2m_change_entry_type_global() which set entry.recalc=1. Then
> > the following get_entry(p2m_ioreq_server) will return
> > p2m_ram_rw type
flight 109010 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109010/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 108176
test-xtf-amd64-
flight 109005 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109005/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 108166
build-i386-pvop
On Thu, 4 May 2017, Julien Grall wrote:
> > @@ -545,14 +549,30 @@ static void gic_restore_pending_irqs(struct vcpu *v)
> > /* No more free LRs: find a lower priority irq to evict */
> > list_for_each_entry_reverse( p_r, inflight_r, inflight )
> > {
> > +
On Fri, 5 May 2017, Andre Przywara wrote:
> Hi,
>
> On 04/05/17 17:21, Julien Grall wrote:
> > Hi Andre,
> >
> > On 04/05/17 16:31, Andre Przywara wrote:
> >> Introduce the proper locking sequence for the new pending_irq lock.
> >> This takes the lock around multiple accesses to struct members,
>
On Thu, 4 May 2017, Julien Grall wrote:
> On 04/05/17 16:31, Andre Przywara wrote:
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index f4ae454..44363bb 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -356,11 +356,16 @@ void vgic_enable_irqs(struct vcpu *v,
flight 109007 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109007/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 59254
build-i386-pvops
flight 109001 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109001/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 5 kernel-build fail REGR. vs. 108210
Tests which did not
We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is
Time to wire up all the call sites that request a shutdown or
reset to use the enum added in the previous patch.
It would have been less churn to keep the common case with no
arguments as meaning guest-triggered, and only modified the
host-triggered code paths, via a wrapper function, but then we'
On Fri, 5 May 2017, Andrii Anisov wrote:
> Hello Stefano,
>
> On 24.04.17 21:08, Stefano Stabellini wrote:
> > Stubdomains (stubdoms in short) are small domains, each running a single
> > application. Typically they run unikernels rather than a full fledged
> > operating system. A classic example
On Fri, 5 May 2017, Julien Grall wrote:
> Hi all,
>
> This small patch series ensure that Xen will not die when receiving unknown
> trap from the guests. I am not aware of any issue with platform we currently
> support, so I am not sure whether it would be Xen 4.9 material.
Given that it is a bug
On Fri, 5 May 2017, Julien Grall wrote:
> The function do_trap_hypervisor is currently handling both trap coming
> from the hypervisor and the guest. This makes difficult to get specific
> behavior when a trap is coming from either the guest or the hypervisor.
>
> Split the function into two parts
Currently usbdevice_list is only checked for nullity. But the OCaml binding
will convert empty list to a pointer to NULL, instead of a NULL pointer. That
means the OCaml binding will fail to disable USB.
This patch will check emptiness of usbdevice_list. And NULL is still a valid
empty list.
Sig
On Fri, 5 May 2017, Bhupinder Thakur wrote:
> Hi Stefano,
>
> >> >> >> > It looks like you are reusing the libxl__device_console_add call
> >> >> >> > for the
> >> >> >> > main PV console for the domain, to also add the vuart nodes to
> >> >> >> > xenstore.
> >> >> >> >
> >> >> >> > I don't thin
On 05/05/17 19:16, Marcus Granado wrote:
> On 03/05/17 10:56, Andrew Cooper wrote:
>> On 03/05/17 08:21, Jan Beulich wrote:
>> On 02.05.17 at 19:37, wrote:
On 02/05/17 10:43, Tim Deegan wrote:
> At 02:50 -0600 on 02 May (1493693403), Jan Beulich wrote:
> On 02.05.17 at 10:32,
flight 109015 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
Robin Lee writes ("[PATCH] libxl/libxl_dm.c: u.hvm.usbdevice_list is checked
for emptiness"):
> Currently usbdevice_list is only checked for nullity. But the OCaml binding
> will convert empty list to a pointer to NULL, instead of a NULL pointer. That
> means the OCaml binding will fail to disable
On 03/05/17 10:56, Andrew Cooper wrote:
> On 03/05/17 08:21, Jan Beulich wrote:
> On 02.05.17 at 19:37, wrote:
> >> On 02/05/17 10:43, Tim Deegan wrote:
> >>> At 02:50 -0600 on 02 May (1493693403), Jan Beulich wrote:
> >>> On 02.05.17 at 10:32, wrote:
> > At 04:52 -0600 on 28 Apr (14
flight 109036 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109036/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
Currently usbdevice_list is only checked for nullity. But the OCaml binding
will convert empty list to a pointer to NULL, instead of a NULL pointer. That
means the OCaml binding will fail to disable USB.
This patch will check emptiness of usbdevice_list. And NULL is still a valid
empty list.
Sig
On Fri, May 05, 2017 at 10:00:36AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more. As commit da72ff5bfcb0
> ("partially revert x
On Fri, May 05, 2017 at 09:59:15AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more.
>
> It is still necessary for old Xen versio
On 05/05/2017 04:27 PM, Andrii Anisov wrote:
Hello Julien,
On 05.05.17 17:12, Julien Grall wrote:
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared o
Andrii Anisov writes ("Re: [RFC] scf: SCF device tree and configuration
documentation"):
> On 05.05.17 17:13, Ian Jackson wrote:
> > If these regions of the DT can be marked by this "xen,coproc"
> > property, can't we instead identify them (eg in the libxl domain
> > configuration) by their DT pat
Hello Ian,
On 05.05.17 17:13, Ian Jackson wrote:
I read this proposal.
I agree that putting all the details (interrupts, mmio, etc.) in the
libxl config file is probably undesirable.
AFAICT, there, a particularly coprocessor can be identified as a
portion of the host's DT. Is that right ? T
On 05/05/2017 12:05 PM, Jan Beulich wrote:
On 05.05.17 at 17:23, wrote:
>> On 05/05/2017 10:51 AM, Jan Beulich wrote:
>> On 05.05.17 at 16:27, wrote:
On 05/05/2017 10:14 AM, Jan Beulich wrote:
On 05.05.17 at 16:10, wrote:
> On 05.05.17 at 15:42, wrote:
>>
On Fri, May 05, 2017 at 05:32:43PM +0100, Andrew Cooper wrote:
> The pin_page block is missing one level of indentation, which makes the
> MMUEXT_UNPIN_TABLE case label appear to be outside of the switch statement.
>
> However, the block isn't needed at all if page is declared with switch level
>
The pin_page block is missing one level of indentation, which makes the
MMUEXT_UNPIN_TABLE case label appear to be outside of the switch statement.
However, the block isn't needed at all if page is declared with switch level
scope. This allows for the removal of the identical local declarations f
On 05/05/17 15:48, Wei Liu wrote:
> The body of subarch_percpu_traps_init is for setting up PV syscall
> trampoline. Move that into a dedicated function.
>
> Leave the BUILD_BUG_ON in the original function as it is not tied to PV.
>
> No functional change.
>
> Signed-off-by: Wei Liu
The trampolin
>>> On 05.05.17 at 17:51, wrote:
> The pin_page block is missing one level of indentation, which makes the
> MMUEXT_UNPIN_TABLE case label appear to be outside of the switch statement.
>
> While making this adjustment, delete one other piece of trailing whitespace.
>
> No functional change.
>
>
On 05/05/17 17:07, Jan Beulich wrote:
On 05.05.17 at 17:51, wrote:
>> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beulich
>
> I too had this on my mental list for killing...
I have lost count of the number of times I've looked at it and decided
that I really should get around to deleting
>>> On 05.05.17 at 17:51, wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
I too had this on my mental list for killing...
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 05.05.17 at 17:23, wrote:
> On 05/05/2017 10:51 AM, Jan Beulich wrote:
> On 05.05.17 at 16:27, wrote:
>>> On 05/05/2017 10:14 AM, Jan Beulich wrote:
>>> On 05.05.17 at 16:10, wrote:
On 05.05.17 at 15:42, wrote:
> Otoh there's not much to scrub yet until Dom0 had
On 05/05/2017 01:09 AM, Juergen Gross wrote:
> Any comments?
>
>
> Juergen
>
> On 27/04/17 07:01, Juergen Gross wrote:
>> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
>> on AMD cpus.
>>
>> This bug/feature bit is kind of special as it will be used very early
>> when switchin
On Fri, May 05, 2017 at 04:51:02PM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/domain.c | 4
1 file changed, 4 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ef8c05a..862a568 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1886,8 +1886,6 @@ static void
The pin_page block is missing one level of indentation, which makes the
MMUEXT_UNPIN_TABLE case label appear to be outside of the switch statement.
While making this adjustment, delete one other piece of trailing whitespace.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
On Fri, May 5, 2017 at 10:47 AM, Jan Beulich wrote:
On 05.05.17 at 16:42, wrote:
>> On Thu, May 4, 2017 at 11:37 AM, Jan Beulich wrote:
>> On 04.05.17 at 17:17, wrote:
On 05/04/17 17:57, Tamas K Lengyel wrote:
> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
> On
Hello Julien,
On 05.05.17 17:12, Julien Grall wrote:
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared of
attack
from a domain privileged enough to run
On 05/05/2017 10:51 AM, Jan Beulich wrote:
On 05.05.17 at 16:27, wrote:
>> On 05/05/2017 10:14 AM, Jan Beulich wrote:
>> On 05.05.17 at 16:10, wrote:
>>> On 05.05.17 at 15:42, wrote:
Otoh there's not much to scrub yet until Dom0 had all its memory
allocated, and we
And provide an Emacs block.
Signed-off-by: Wei Liu
---
xen/include/asm-x86/traps.h | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h
index 7f36f6c1a7..0676e81d1a 100644
--- a/xen/include/asm-x86/tra
Move them to pv/traps.c.
This in turn requires exporting pv_percpu_traps_init and
hypercall_page_initialise_ring3_kernel.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 363
xen/arch/x86/x86_64/traps.c | 363 +
Replace bool_t with bool. Delete trailing white spaces. Fix some coding
style issues.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c | 77 +++-
1 file changed, 40 insertions(+), 37 deletions(-)
diff --git a/xen/arch/x86/tra
Fix coding style issues.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 8cabef7a44..8aa4d9e335 100644
--- a/xen/arch/
Export hypercall_page_initialise_ring1_kernel as the code is moved.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c| 406
xen/arch/x86/x86_64/compat/traps.c | 415 -
xen/arch/x86/x86_64
It needs to be non-static when we split PV specific code out.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c| 2 +-
xen/include/asm-x86/traps.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 4 ++--
xen/include/asm-x86/traps.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 8aa4d9e335..c946d855c3 100644
--- a/xen/arch/x86/p
Fixed some coding style issues while moving.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 50 +
xen/arch/x86/traps.c| 47 --
2 files changed, 50 insertions(+), 47 deleti
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 18 ++
xen/arch/x86/traps.c| 18 --
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 54d77922c5..4e9a376000 10064
On 05/05/17 14:12, Jan Beulich wrote:
> While using alloc_domheap_pages() and assuming the allocated memory is
> directly accessible is okay at boot time (as we run on the idle page
> tables there), memory hotplug code too assumes it can access the
> resulting page tables without using map_domain_p
>>> On 14.04.17 at 17:37, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -114,6 +114,13 @@ config DEVICE_TREE_DEBUG
> logged in the Xen ring buffer.
> If unsure, say N here.
>
> +config SCRUB_DEBUG
> +bool "Page scrubbing test"
> +default DEBUG
> +---
>>> On 05.05.17 at 16:27, wrote:
> On 05/05/2017 10:14 AM, Jan Beulich wrote:
> On 05.05.17 at 16:10, wrote:
>> On 05.05.17 at 15:42, wrote:
>>> Otoh there's not much to scrub yet until Dom0 had all its memory
>>> allocated, and we know which pages truly remain free (wanting
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 27 +++
xen/arch/x86/traps.c| 27 ---
2 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 9de5798e58
It will be used in common and pv specific code. Export it in traps.h.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c| 2 +-
xen/include/asm-x86/traps.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 63 +
xen/arch/x86/traps.c| 59 -
2 files changed, 63 insertions(+), 59 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/
This series splits PV code related to trap handling to files under pv
directory.
The patches to refactor various entry.S are dropped in this version as Andrew
is going to work on those.
git://xenbits.xen.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 37 +
xen/arch/x86/traps.c| 36
2 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps
Replace bool_t with bool.
Change check_stack_limit to return bool.
Fix some coding style issues.
Undef TOGGLE_MODE when it is no longer needed.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/emulate_ops.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff -
The following handlers are moved:
1. do_set_trap_table
2. do_set_debugreg
3. do_get_debugreg
4. do_fpu_taskswitch
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 97 +
xen/arch/x86/traps.c| 94 ---
Put it along side with other pv_inject functions and rename it to
pv_inject_trap.
We need this because this function is used by PV emulation code and PV
trap handling code, which will be split into different files.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c |
The body of subarch_percpu_traps_init is for setting up PV syscall
trampoline. Move that into a dedicated function.
Leave the BUILD_BUG_ON in the original function as it is not tied to PV.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/x86_64/traps.c | 13 +
1 file c
On 05/05/17 14:11, Jan Beulich wrote:
> Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from
> assembly") didn't go quite far enough with the cleanup it did: The
> changed maximum frame size should also have been reflected in the early
> address range check (which has now been pointed o
>>> On 05.05.17 at 16:42, wrote:
> On Thu, May 4, 2017 at 11:37 AM, Jan Beulich wrote:
> On 04.05.17 at 17:17, wrote:
>>> On 05/04/17 17:57, Tamas K Lengyel wrote:
On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
On 04.05.17 at 11:14, wrote:
>> On 05/04/17 12:11, Jan Be
On Thu, May 4, 2017 at 11:37 AM, Jan Beulich wrote:
On 04.05.17 at 17:17, wrote:
>> On 05/04/17 17:57, Tamas K Lengyel wrote:
>>> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
>>> On 04.05.17 at 11:14, wrote:
> On 05/04/17 12:11, Jan Beulich wrote:
> On 04.05.17 at 11:
David Miller writes:
> From: Vitaly Kuznetsov
> Date: Thu, 4 May 2017 14:23:04 +0200
>
>> Unavoidable crashes in netfront_resume() and netback_changed() after a
>> previous fail in talk_to_netback() (e.g. when we fail to read MAC from
>> xenstore) were discovered. The failure path in talk_to_ne
>>> On 05.05.17 at 05:52, wrote:
> 'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
> outstanding p2m_ioreq_server entries")' will call
> p2m_change_entry_type_global() which set entry.recalc=1. Then
> the following get_entry(p2m_ioreq_server) will return
> p2m_ram_rw type.
> But 'com
Currently we crash Xen if we see an ESR_EL2.EC value we don't recognise.
As configurable disables/enables are added to the architecture
(controlled by RES1/RESO bits respectively), with associated synchronous
exceptions, it may be possible for a guest to trigger exceptions with
classes that we don'
Hi all,
This small patch series ensure that Xen will not die when receiving unknown
trap from the guests. I am not aware of any issue with platform we currently
support, so I am not sure whether it would be Xen 4.9 material.
Cheers,
Julien Grall (3):
xen/arm: arm32: Rename the trap to the corr
Per Table B1-3 in ARM DDI 0406C.c, the vector 0x8 for hyp is called
"Hypervisor Call".
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
---
xen/arch/arm/arm32/entry.S | 4 ++--
xen/arch/arm/arm32/traps.c | 4 ++--
2 files ch
The function do_trap_hypervisor is currently handling both trap coming
from the hypervisor and the guest. This makes difficult to get specific
behavior when a trap is coming from either the guest or the hypervisor.
Split the function into two parts:
- do_trap_guest_sync to handle guest traps
On 05/05/2017 10:14 AM, Jan Beulich wrote:
On 05.05.17 at 16:10, wrote:
> On 05.05.17 at 15:42, wrote:
>> Otoh there's not much to scrub yet until Dom0 had all its memory
>> allocated, and we know which pages truly remain free (wanting
>> what is currently the boot time scrub
On 04/05/17 10:00, Razvan Cojocaru wrote:
> This small series first creates hvm/vm_event.{h,c}, in order to bring
> under vm_event maintainership the code that has previously lived in
> hvm_do_resume(), and then fixes a __context_switch()-related race
> condition when attempting to set registers vi
Julien Grall writes ("Re: [RFC] scf: SCF device tree and configuration
documentation"):
> I have CCed Ian and Wei to comment on the difficult to describe a such
> interface in libxl. They may have insights how to do this properly.
Hi.
> @Ian @Wei: Andrii is suggesting to use Device-Tree for des
>>> On 05.05.17 at 16:10, wrote:
On 05.05.17 at 15:42, wrote:
> Otoh there's not much to scrub yet until Dom0 had all its memory
> allocated, and we know which pages truly remain free (wanting
> what is currently the boot time scrubbing done on them). But that
> point in time
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared of attack
from a domain privileged enough to run domains?
Whilst the domain is privileged enough to ru
>>> On 05.05.17 at 15:51, wrote:
> On 05/05/2017 06:27 AM, Jan Beulich wrote:
> On 04.05.17 at 19:18, wrote:
>>> On 05/04/2017 11:43 AM, Jan Beulich wrote:
>>> On 14.04.17 at 17:37, wrote:
> While scrubbing from idle loop, check for softirqs every 256 pages.
> If softirq is pendi
>>> On 05.05.17 at 15:42, wrote:
Otoh there's not much to scrub yet until Dom0 had all its memory
allocated, and we know which pages truly remain free (wanting
what is currently the boot time scrubbing done on them). But that
point in time may still be earlier than when we swit
On 05/05/2017 06:27 AM, Jan Beulich wrote:
On 04.05.17 at 19:18, wrote:
>> On 05/04/2017 11:43 AM, Jan Beulich wrote:
>> On 14.04.17 at 17:37, wrote:
While scrubbing from idle loop, check for softirqs every 256 pages.
If softirq is pending, don't scrub any further and merge the
On 04/05/17 16:50, Andrii Anisov wrote:
Julien,
Hi Andrii,
What I would like to understand is what are the information that the
hypervisors as to know for sharing co-processor? So far I have:
- MMIOs
- Interrupts
Anything else?
IOMMU bindings.
This knowledge enough to get the physi
On 05/05/17 08:10, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
Hi Jan,
@@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d,
unsigned int domcr_flags,
if ( (rc = domain_vtimer_init(d, config)) != 0 )
goto fail;
+if ( domcr_flags & DOMCRF_vuart )
+if (
+bool scrub_free_pages(void)
{
struct page_info *pg;
unsigned int zone, order;
unsigned long i;
+unsigned int cpu = smp_processor_id();
+bool preempt = false;
+nodeid_t node;
-ASSERT(spin_is_locked(&heap_lock));
>>
flight 109011 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109011/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 108170
build-i386-pvops
On 05/05/17 12:18, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
+
+unsigned int vpl011_reg_mask[] = {0xff, 0x, 0x};
This should be static. But I don't get what you need that. In the first
version, I suggested to re-purpose vgic_reg*_{extract,update} so we can use
it here.
While using alloc_domheap_pages() and assuming the allocated memory is
directly accessible is okay at boot time (as we run on the idle page
tables there), memory hotplug code too assumes it can access the
resulting page tables without using map_domain_page() or alike, and
hence we need to obtain me
Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from
assembly") didn't go quite far enough with the cleanup it did: The
changed maximum frame size should also have been reflected in the early
address range check (which has now been pointed out to have been wrong
anyway, using 60 instead
On 05/05/2017 01:41 AM, Lu Baolu wrote:
> Hi,
>
> On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
>> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>>> Add a simple udelay calibration in x86 architecture-specific
>>> boot-time initializations. This will get a workable estimate
>>> for loops_per_jiffy. Henc
Hi,
On 05/05/17 11:13, Andrew Cooper wrote:
On 05/05/17 10:27, Jan Beulich wrote:
Commit 897129deab ("x86: use unambiguous register names") went a little
too far: With it we also get register names like _e15 and e15 for
non-Xen consumers using a gcc compatible compiler. Correct this.
Signed-of
flight 109014 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109014/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
flight 109003 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 107358
build-amd64-pvops
Hi Julien,
>> +
>> +unsigned int vpl011_reg_mask[] = {0xff, 0x, 0x};
>
>
> This should be static. But I don't get what you need that. In the first
> version, I suggested to re-purpose vgic_reg*_{extract,update} so we can use
> it here. It would probably need to be renamed to vreg_reg*.
On 24.04.17 21:08, Stefano Stabellini wrote:
If we are speaking about shared coprocessors framework, we need here several
things:
- MMIO access emulation
This could be run as EL0 app.
But even now, the MMIO access emulation has something to do with the
real hardware under the circumstances
Hello Stefano,
On 24.04.17 21:08, Stefano Stabellini wrote:
Stubdomains (stubdoms in short) are small domains, each running a single
application. Typically they run unikernels rather than a full fledged
operating system. A classic example is QEMU stubdoms on x86: one QEMU
stubdoms is started for
1 - 100 of 128 matches
Mail list logo
