>>> On 14.04.17 at 17:37, wrote:
> Instead of scrubbing pages while holding heap lock we can mark
> buddy's head as being scrubbed and drop the lock temporarily.
> If someone (most likely alloc_heap_pages()) tries to access
> this chunk it will signal the scrubber to abort scrub by setting
> head'
Julien,
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 run domains, the
configuration can be provided by a user (for instance in cloud
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 sure we observe the locking order (VGIC VCPU lock first,
then pending_irq lock).
This locking order
Hi Andre,
On 04/05/17 16:31, Andre Przywara wrote:
Currently we store the priority for newly triggered IRQs in the rank
structure. To get eventually rid of this structure, move this value
into the struct pending_irq. This one already contains a priority value,
but we have to keep the two apart,
On 04/05/17 17:39, Julien Grall wrote:
Hi Andre,
On 04/05/17 16:31, Andre Przywara wrote:
Currently we store the priority for newly triggered IRQs in the rank
structure. To get eventually rid of this structure, move this value
into the struct pending_irq. This one already contains a priority
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, uint32_t r, int n)
while ( (i = find_next_bit(&mask,
Hi Andre,
On 04/05/17 16:31, Andre Przywara wrote:
Currently we store the interrupt type configuration (level or edge
triggered) in the rank structure. Move this value into struct pending_irq.
We just need one bit (edge or level), so use one of the status bits.
Signed-off-by: Andre Przywara
--
This run is configured for baseline tests only.
flight 71253 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71253/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-ins
On 05/04/2017 11:31 AM, Jan Beulich wrote:
On 14.04.17 at 17:37, wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -1035,16 +1035,82 @@ merge_and_free_buddy(struct page_info *pg, unsigned
>> int node,
>> return pg;
>> }
>>
>> -static void scrub_free_pages
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
>> partially-scrubbed buddy back into heap by breaking the clean portion
>> into small
Hi Andre,
On 04/05/17 16:31, Andre Przywara wrote:
So far we kept the target VCPU for SPIs in the rank structure.
Move that information over into pending_irq.
This changes vgic_get_target_vcpu(), which now takes only a domain
and a struct pending_irq to get the target vCPU, in a way that does no
On 05/04/2017 12:03 PM, Jan Beulich wrote:
On 14.04.17 at 17:37, wrote:
>> Instead of scrubbing pages while holding heap lock we can mark
>> buddy's head as being scrubbed and drop the lock temporarily.
>> If someone (most likely alloc_heap_pages()) tries to access
>> this chunk it will signa
Hi Andre,
On 04/05/17 16:31, Andre Przywara wrote:
So far there is always a statically allocated struct pending_irq for
each interrupt that we deal with.
To prepare for dynamically allocated LPIs, introduce a put/get wrapper
to get hold of a pending_irq pointer.
So far get() just returns the sam
flight 108235 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108235/
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
On 04/05/17 09:52, Julien Grall wrote:
> Hi,
>
> On 02/05/17 14:23, Jan Beulich wrote:
>> The primary purpose is correcting a latent bug in __get_user_check()
>> (the macro has no active user at present): The access_ok() check should
>> be before the actual access, or else any PV guest could initia
Hi Andrew,
On 04/05/17 18:52, Andrew Cooper wrote:
On 04/05/17 09:52, Julien Grall wrote:
Hi,
On 02/05/17 14:23, Jan Beulich wrote:
The primary purpose is correcting a latent bug in __get_user_check()
(the macro has no active user at present): The access_ok() check should
be before the actual
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'
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 Wed, May 03, 2017 at 02:00:35PM -0700, Stefano Stabellini wrote:
> The Xen mapcache is able to create long term mappings, they are called
> "locked" mappings. The third parameter of the xen_map_cache call
> specifies if a mapping is a "locked" mapping.
>
>
> >From the QEMU point of view there
Per Table B1-3 in ARM DDI 0406C.c, the vector 0x8 for hyp is called
"Hypervisor Call".
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/entry.S | 4 ++--
xen/arch/arm/arm32/traps.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/ar
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
On Thu, 4 May 2017, Ian Jackson wrote:
> Stepping back a bit: It is indeed important that our code is easy to
> understand and modify, expresses its intent clearly, and helps future
> programmers avoid writing bugs. But it is also important that
> contributors feel valued, and feel a sense of owne
On 04/05/17 18:54, Julien Grall wrote:
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 6010c96c54..c8ce62ff96 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2805,7 +2805,7 @@ static void enter_hypervisor_head(struct cpu_user_regs
> *regs)
> }
> }
>
Hi Andrew,
On 04/05/17 19:03, Andrew Cooper wrote:
On 04/05/17 18:54, Julien Grall wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6010c96c54..c8ce62ff96 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2805,7 +2805,7 @@ static void enter_hypervisor_head(st
flight 108207 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108207/
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-arm64-arm64-libv
On Thu, 4 May 2017, Wei Chen wrote:
> ARM32 doesn't have an exception similar to hyp_sync of ARM64 to catch
> the synchronous data abort (For example, a NULL pointer has been referenced).
> Hence the SError and sync data abort will be caught by the same data abort
> exception.
>
> Since commit "3f
flight 108216 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108216/
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. 108170
Tests which did not succee
On Thu, 4 May 2017, Julien Grall wrote:
> 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
> ---
> xen/arch/arm/arm32/entry.S | 4 ++--
> xen/arch/arm/arm32/traps.c | 4 ++--
> 2 files cha
On Thu, 4 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
On Thu, 4 May 2017, Julien Grall wrote:
> 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
On 05/04/2017 08:14 PM, Stefano Stabellini wrote:
On Thu, 4 May 2017, Julien Grall wrote:
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 synchro
Hi,
On 05/04/2017 07:32 PM, Stefano Stabellini wrote:
On Thu, 4 May 2017, Wei Chen wrote:
ARM32 doesn't have an exception similar to hyp_sync of ARM64 to catch
the synchronous data abort (For example, a NULL pointer has been referenced).
Hence the SError and sync data abort will be caught by th
Hi,
>> >> > 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 think it is a good idea to mix the two. I suggest to introduce a
>> >> > new libxl__device call to introduc
Commit 2c77db77 "xen/arm: efi: Avoid duplicating the addition of a new
bank", introduced a new function meminfo_add_bank that add a new bank.
This new code fails to check correctly the size of the array which may
result to an out-of-bounds write.
Coverity-ID: 1433183
Signed-off-by: Julien Grall
On Fri, 5 May 2017, Bhupinder Thakur wrote:
> Hi,
>
>
> >> >> > 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 think it is a good idea to
flight 108212 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108212/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 108166
On 05/03/2017 04:41 PM, Andrew Cooper wrote:
On 25/04/17 22:45, Mohit Gambhir wrote:
diff --git a/tests/vpmu/Makefile b/tests/vpmu/Makefile
new file mode 100644
index 000..1eaf436
--- /dev/null
+++ b/tests/vpmu/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME := vpmu
Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General
Protection Fault and thus results in a hypervisor crash. This behavior has
been observed on two generations of Intel processors namely, Haswell and
Broadwell. Other Intel processor generations were not tested. However, it
does
This patch adds Intel PMU MSR addresses as macros for VPMU testing
Signed-off-by: Mohit Gambhir
---
arch/x86/include/arch/msr-index.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/include/arch/msr-index.h
b/arch/x86/include/arch/msr-index.h
index 72373c6..911d7f9 10
This patch tests VPMU functionality in the hypervisor on Intel machines.
The tests write to all valid bits in the MSRs that get exposed to the guests
when VPMU is enabled. The tests also write invalid values to the bits
that should be masked and expect the wrmsr call to fault.
The tests are curren
v5:
Incorporated review comments -
+ Changed test type from utility to functional
+ Test is now defined only for hvm64 instead of ALL_ENVIRONMENTS
+ Several code styling and formatting changes
+ Expanded test description for doxygen
+ Added max_leaf check before cpuid_count
+ Addded PDCM bit ch
Adding personal email id for future correspondence on this thread -
mgamb...@outlook.com
On 05/04/2017 05:13 PM, Mohit Gambhir wrote:
On 05/03/2017 04:41 PM, Andrew Cooper wrote:
On 25/04/17 22:45, Mohit Gambhir wrote:
diff --git a/tests/vpmu/Makefile b/tests/vpmu/Makefile
new file mode 100
On Thu, 4 May 2017, Julien Grall wrote:
> Commit 2c77db77 "xen/arm: efi: Avoid duplicating the addition of a new
> bank", introduced a new function meminfo_add_bank that add a new bank.
> This new code fails to check correctly the size of the array which may
> result to an out-of-bounds write.
>
>
On Thu, 4 May 2017, Julien Grall wrote:
> > @@ -28,11 +27,20 @@ static inline int
> > local_events_need_delivery_nomask(void)
> > * case.
> > */
> > if ( gic_events_need_delivery() )
> > -return 1;
> > +{
> > +ret = 1;
> > +}
> > +else
> > +{
> > +
Ping
The Xen dom0 support in DPDK seems dead.
Reminder:
Last time we talked about, it was because of a severe bug which is not
fixed yet:
http://dpdk.org/ml/archives/dev/2016-July/044207.html
http://dpdk.org/ml/archives/dev/2016-July/044376.html
The request (9 months ago) was to g
Hello, Dmitry!
On 04/21/2017 09:42 AM, Oleksandr Andrushchenko wrote:
On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:
On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Xen input para-virtual protocol defines string constants
used by both bac
Hi, Dmitry!
On 04/21/2017 09:40 AM, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Extend xen_kbdfront to provide multi-touch supp
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 switching threads. Setting the bit and clearing it a little bit
>
This run is configured for baseline tests only.
flight 71256 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 15 guest-l
101 - 149 of 149 matches
Mail list logo
