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
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
>
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
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
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
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
> > +{
> > +
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.
>
>
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
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
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
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
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
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 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
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
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
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
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
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 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:
> 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
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, 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 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
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
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)
> }
> }
>
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
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
---
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
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
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
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 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
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
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
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
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 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 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
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
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
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
--
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,
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
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,
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
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
>>> 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'
Recently, the tests of Windows XP SP3 that are run by osstest, as part
of the Xen Project's test suite, have started failing a lot more.
It is not clear what has caused this. The failures are causing
blockages: several of our `staging' branches are not gettting pushed
to the corresponding `stable
Hey,
On Tue, May 02, 2017 at 03:06:24PM +0800, fu@linaro.org wrote:
> From: Fu Wei
>
> This patchset add xen_boot support into grup-mkconfig for
> generating xen boot entrances automatically
>
> Also update the docs/grub.texi for new xen_boot commands.
Slowly recovering after long weekend in
Hi Andre,
On 04/05/17 16:31, Andre Przywara wrote:
gic_route_irq_to_guest() and gic_remove_irq_from_guest() take the rank
lock, however never actually access the rank structure.
Avoid taking the lock in those two functions and remove some more
unneeded code on the way.
The rank is here to prot
flight 108232 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108232/
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
Julien,
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 physical coprocessor shared.
In order to spawn a virtual
>>> 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 smaller power-of-2 chunks. Then repeat the same proce
>>> 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:00, wrote:
>> Created arch/x86/hvm/vm_event.c and incl
>>> On 04.05.17 at 17:04, wrote:
> On 05/04/2017 10:44 AM, Jan Beulich wrote:
> On 14.04.17 at 17:37, wrote:
>>> When allocating pages in alloc_heap_pages() first look for clean pages.
>> As expressed before, there are cases when we don't really need
>> scrubbed pages. Hence the local variabl
On Thu, May 4, 2017 at 11:17 AM, Razvan Cojocaru
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:00, wrote:
>> Created arch/x86/
>>> 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(unsigned int node)
> +static nodemask_t node_scrubb
Currently gic_raise_inflight_irq() and gic_raise_guest_irq() are used
to queue interrupts to a VCPU, for which they are given a VCPU and an
interrupt number.
To allow proper locking and simplify further changes, change their prototypes
to take a struct pending_irq directly (since the callers have t
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 not
necessarily require the pending_irq lock to be held.
gic_route_irq_to_guest() and gic_remove_irq_from_guest() take the rank
lock, however never actually access the rank structure.
Avoid taking the lock in those two functions and remove some more
unneeded code on the way.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c | 28 ---
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, as the priority for guest visible
IRQs must not change
Now that every information formerly stored in the irq_rank has been
transferred over to struct pending_irq, we can get rid of all dead code
declaring and initializing the structure and all the support functions.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic.c | 55
Hi,
this is a sketch of the first step of some ARM VGIC rework.
While working more closely with the code during the ITS patch series, we
identified some shortcomings with the existing code which should be fixed.
This series addresses two, somewhat related, fields:
It introduces a per-IRQ lock to p
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
---
xen/arch/arm/vgic-v2.c | 29 ++-
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 same pointer and put() is empty, but this
change allows t
Currently we store the enable bit of an interrupt in the rank structure.
Remove it from there and let the MMIO emulation use the already existing
GIC_IRQ_GUEST_ENABLED in the status bits of struct pending_irq.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v2.c | 38
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).
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c | 26 +
Currently we protect the pending_irq structure with the corresponding
VGIC VCPU lock. For future extensions this leads to problems (for
instance if an IRQ is migrating), so let's introduce a per-IRQ lock,
which protects the consistency of this structure independent from
any VCPU.
This patch just in
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_netback() does
> unregister/free
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:00, wrote:
> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
> where H
On 05/04/2017 10:44 AM, Jan Beulich wrote:
On 14.04.17 at 17:37, wrote:
>> When allocating pages in alloc_heap_pages() first look for clean pages.
> As expressed before, there are cases when we don't really need
> scrubbed pages. Hence the local variable "use_unscrubbed" below
> should really
On Thu, May 04, 2017 at 01:53:00PM +0100, Julien Grall wrote:
>
>
> On 04/05/17 11:55, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH for-4.9] libs/devicemodel: Fix dependency
> > with libxencall"):
> > > libxendevicemodel.so do depends on libxencall.so but the dependency was
> > > missin
>>> On 04.05.17 at 16:53, wrote:
> On 05/04/2017 06:17 AM, Jan Beulich wrote:
> On 14.04.17 at 17:37, wrote:
>>> @@ -678,6 +680,20 @@ static void check_low_mem_virq(void)
>>> }
>>> }
>>>
>>> +/* Pages that need scrub are added to tail, otherwise to head. */
>>> +static void page_list_
flight 71255 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71255/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops
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:00, wrote:
Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
where HVM-specific vm_event-related code will live. This
On 05/04/2017 06:17 AM, Jan Beulich wrote:
On 14.04.17 at 17:37, wrote:
>> @@ -678,6 +680,20 @@ static void check_low_mem_virq(void)
>> }
>> }
>>
>> +/* Pages that need scrub are added to tail, otherwise to head. */
>> +static void page_list_add_scrub(struct page_info *pg, unsigned in
>>> On 14.04.17 at 17:37, wrote:
> When allocating pages in alloc_heap_pages() first look for clean pages.
As expressed before, there are cases when we don't really need
scrubbed pages. Hence the local variable "use_unscrubbed" below
should really be some form of input to alloc_heap_pages().
> -
Jan Beulich writes ("Re: differing opinions between maintainers vs patch acks"):
> On 04.05.17 at 14:44, wrote:
> > Well, at one level I agree with Andrew on at least the 1*1 and 0*8
> > question. These seem clearer to me as they state the programmer's
> > intent as well as merely the effect. I
On 05/03/2017 05:35 PM, osstest service owner wrote:
> flight 108160 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/108160/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-pvh-intel 6
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 04/05/17 13:54, Jan Beulich wrote:
On 04.05.17 at 14:44, wrote:
>> Andrew Cooper writes ("Re: differing opinions between maintainers vs patch
>> acks"):
>>> Taking this example, as you have called it out, but without going into
>>> the details.
>>>
>>> I accept that the issues under debat
>>> On 04.05.17 at 14:20, wrote:
> XP is really quite obsolete now.
>
> From diffing standalone-generate-dump-flight-runvars output,
> the tests that are dropped are:
> test-amd64-amd64-xl-qemut-winxpsp3
> test-amd64-amd64-xl-qemuu-winxpsp3
> test-amd64-i386-xl-qemut-winxpsp3
> test-amd64
>>> On 04.05.17 at 14:53, wrote:
> To become a CNA (CVE Numbering Authority), which we would like to do,
> we need to provide MITRE's CNA programme with a definition of the
> scope of our CNA. That should be the scope of our general security
> support, clearly.
>
> At the moment we don't seem to
>>> On 04.05.17 at 14:44, wrote:
> Andrew Cooper writes ("Re: differing opinions between maintainers vs patch
> acks"):
>> Taking this example, as you have called it out, but without going into
>> the details.
>>
>> I accept that the issues under debate do not have any impact on the
>> technical
To become a CNA (CVE Numbering Authority), which we would like to do,
we need to provide MITRE's CNA programme with a definition of the
scope of our CNA. That should be the scope of our general security
support, clearly.
At the moment we don't seem to have this written down in a single
clear docu
On 04/05/17 11:55, Ian Jackson wrote:
Anthony PERARD writes ("[PATCH for-4.9] libs/devicemodel: Fix dependency with
libxencall"):
libxendevicemodel.so do depends on libxencall.so but the dependency was
missing at link time.
Acked-by: Ian Jackson
IMO this should indeed go into 4.9.
Relea
Hi Jan,
On 04/05/17 13:02, Jan Beulich wrote:
This is because that code, added by commit 997382b771 ("y86/vmx: dump
PIR and vIRR before ASSERT()"), was meant to be removed by the time we
finalize 4.9, but the root cause of the ASSERT() wrongly(?) triggering
still wasn't found.
Take the opportun
Hi Andrew,
On 04/05/17 12:11, Andrew Cooper wrote:
On 02/05/17 19:05, Andrew Cooper wrote:
Various improvements based on observations while investigating and fixing the
aformentioned XSAs. All are candidate patches for 4.9 at this point, with
patches 2, 3 and 7 being the important ones from an
Hi Jan,
On 04/05/17 13:07, Jan Beulich wrote:
On 04.05.17 at 11:42, wrote:
On 04/05/17 10:39, Andrew Cooper wrote:
On 04/05/17 10:09, Jan Beulich wrote:
See the code comment.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Release-acked-by: Julien Grall
Thanks, but what about th
On 04/05/2017 13:44, "Ian Jackson" wrote:
>Andrew Cooper writes ("Re: differing opinions between maintainers vs
>patch acks"):
>> Taking this example, as you have called it out, but without going into
>> the details.
>>
>> I accept that the issues under debate do not have any impact on the
>>
On 04/05/17 13:35, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
Thank you for your comments.
As you may have seen in the description of the option "device_tree",
it is complex to verify the partial device tree because of the libfdt
design. So without fully auditing libfdt and fixing the
Andrew Cooper writes ("Re: differing opinions between maintainers vs patch
acks"):
> Taking this example, as you have called it out, but without going into
> the details.
>
> I accept that the issues under debate do not have any impact on the
> technical correctness of the fix. Once compiled/ass
Hello Julien,
Thank you for your comments.
As you may have seen in the description of the option "device_tree",
it is complex to verify the partial device tree because of the libfdt
design. So without fully auditing libfdt and fixing the holes, this
suggestion would be a vector attack to the
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_netback() does
unregister/free for netdev but we don't reset drvdata and we try accessing
it again aft
No functional change. (Verified with
standalone-generate-dump-flight-runvars.)
Don't bother messing with do_hvm_winxp_tests as 1. that uses testids
without the guest arch, so isn't compatible with this unless we make
it more general 2. we intend to abolish that for most branches
shortly.
Signed-
We call this function `do_hvm_win_2017_tests' because 2017 is the year
in which we are adding these tests and there isn't otherwise a good
common name. This is in the expectation we might want to retire them
at a similar point.
Do these new tests for all branches. If they fail on some old
branch
On 04/05/17 08:59, Jan Beulich wrote:
> All,
>
> it's been a (not very often, but anyway) recurring situation that in
> order to get an ack on some patch I had to make adjustments which
> I didn't agree with. Since all maintainers opinions are supposed to be
> equal, it is not really clear to me wh
XP is really quite obsolete now.
From diffing standalone-generate-dump-flight-runvars output,
the tests that are dropped are:
test-amd64-amd64-xl-qemut-winxpsp3
test-amd64-amd64-xl-qemuu-winxpsp3
test-amd64-i386-xl-qemut-winxpsp3
test-amd64-i386-xl-qemut-winxpsp3-vcpus1
test-amd64-i386-x
1 - 100 of 149 matches
Mail list logo
