branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree
flight 141563 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141563/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
flight 141495 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141495/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 19 leak-check/check fail pass in 141459
Tests which did not succeed, but
flight 141501 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141501/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 14aef6dfca96006e52b8fb920bde7c612ba58b79
baseline version:
freebsd 2fa3479cfad
flight 141554 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141554/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
flight 141490 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141490/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 129313
build-armhf-pvops
flight 141546 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141546/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
flight 141493 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141493/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
141415
test-armhf-armhf-li
With nestedhvm=1, the L2 HVM guest is either hanging (Xen 4.8) or crashing (Xen 4.12.1) the L1 Xen hypervisor with recent versions of Linux. We
isolated the commit to:
commit 093ae8f9a86a974c920b613860f1f7fd5bbd70ab
Author: Borislav Petkov
Date: Thu Apr 12 13:11:36 2018 +0200
x86/TSC: Us
flight 141484 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-fre
flight 141539 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141539/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
On 9/18/19 7:57 AM, Paul Durrant wrote:
> When a frontend gracefully disconnects from an offline backend, it will
> set its own state to XenbusStateClosed. The code in xen-block.c correctly
> deals with this and sets the backend into XenbusStateClosed. Unfortunately
> it is possible for toolstack
flight 141531 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141531/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced:
flight 141521 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141521/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
On 20/09/2019 17:19, Anthony PERARD wrote:
> The following libxl API became asynchronous and gained an additional
> `ao_how' parameter:
> libxl_domain_pause()
> libxl_domain_unpause()
> libxl_send_trigger()
>
> Adapt the ocaml binding.
>
> Build tested only.
>
> Fixes: edaa631ddcee665cd
flight 141482 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141482/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 141448 REGR.
vs. 139698
Tests which
Anthony PERARD writes ("Re: [PATCH] tools/ocaml: Build fix following libxl API
changes"):
> On Fri, Sep 20, 2019 at 05:19:02PM +0100, Anthony PERARD wrote:
> > The following libxl API became asynchronous and gained an additional
> > `ao_how' parameter:
> > libxl_domain_pause()
> > libxl_do
On Fri, Sep 20, 2019 at 05:19:02PM +0100, Anthony PERARD wrote:
> The following libxl API became asynchronous and gained an additional
> `ao_how' parameter:
> libxl_domain_pause()
> libxl_domain_unpause()
> libxl_send_trigger()
>
> Adapt the ocaml binding.
>
> Build tested only.
>
>
flight 141513 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141513/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
flight 141476 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141476/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 141392 REGR.
vs. 141254
Tests which
The following libxl API became asynchronous and gained an additional
`ao_how' parameter:
libxl_domain_pause()
libxl_domain_unpause()
libxl_send_trigger()
Adapt the ocaml binding.
Build tested only.
Fixes: edaa631ddcee665cdfae1cf6bc7492c791e01ef4
Fixes: 95627b87c3159928458ee586e8c5c59
On 14.09.2019 10:52, Juergen Gross wrote:
> This is achieved by switching the scheduler to no longer see vcpus as
> the primary object to schedule, but "schedule units". Each schedule
> unit consists of as many vcpus as each core has threads on the current
> system. The vcpu->unit relation is fixed
On 14.09.2019 10:52, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -55,6 +55,9 @@ boolean_param("sched_smt_power_savings",
> sched_smt_power_savings);
> int sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
> integer_param("sched_ratelimit_us", sched_rateli
On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> > Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
> > bypassing pciback. While pciback is still used to access config space
> > from within stubdomain, i
On 14.09.2019 10:52, Juergen Gross wrote:
> @@ -368,7 +372,7 @@ static struct sched_unit *sched_alloc_unit(struct vcpu *v)
> unit->vcpu_list = v;
> unit->unit_id = v->vcpu_id;
> unit->domain = d;
> -v->sched_unit = unit;
> +unit->runstate_cnt[v->runstate.state]++;
>
>
Hi,
On 20/09/2019 16:16, Stefano Stabellini wrote:
On Fri, 20 Sep 2019, Julien Grall wrote:
On 20/09/2019 00:37, Stefano Stabellini wrote:
On Tue, 17 Sep 2019, Julien Grall wrote:
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those hel
On Fri, 20 Sep 2019, Julien Grall wrote:
> After commit 6e3e771203 "xen/arm: setup: Relocate the Device-Tree later on
> in the boot", the boot allocator will not receive any xenheap page (i.e.
> mapped page) on Arm32.
>
> However, the boot allocator implicitely rely on having the first page
"impl
On 20.09.2019 16:59, Alexandru Stefan ISAILA wrote:
>
>
> On 20.09.2019 17:22, Jan Beulich wrote:
>> On 20.09.2019 14:16, Alexandru Stefan ISAILA wrote:
>>> In order to have __hvm_copy() issue ~X86EMUL_RETRY a new return type,
>>> HVMTRANS_need_retry, was added and all the places that consume HVM
On Fri, 20 Sep 2019, Julien Grall wrote:
> On 20/09/2019 00:37, Stefano Stabellini wrote:
> > On Tue, 17 Sep 2019, Julien Grall wrote:
> > > The current implementations of xen_{map, unmap}_table() expect
> > > {map, unmap}_domain_page() to be usable. Those helpers are used to
> > > map/unmap page t
On 20.09.2019 16:45, osstest service owner wrote:
> flight 141508 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/141508/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64-xsm
On 14.09.2019 10:52, Juergen Gross wrote:
> @@ -508,25 +515,27 @@ int sched_move_domain(struct domain *d, struct cpupool
> *c)
> if ( IS_ERR(domdata) )
> return PTR_ERR(domdata);
>
> -vcpu_priv = xzalloc_array(void *, d->max_vcpus);
> -if ( vcpu_priv == NULL )
> +/* TOD
On 20.09.2019 17:22, Jan Beulich wrote:
> On 20.09.2019 14:16, Alexandru Stefan ISAILA wrote:
>> In order to have __hvm_copy() issue ~X86EMUL_RETRY a new return type,
>> HVMTRANS_need_retry, was added and all the places that consume HVMTRANS*
>> and needed adjustment where changed accordingly.
>
flight 141508 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141508/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
On 14.09.2019 10:52, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -474,12 +474,20 @@ int sched_init_vcpu(struct vcpu *v)
> return 0;
> }
>
> -static void sched_move_irqs(struct vcpu *v)
> +static void vcpu_move_irqs(struct vcpu *v)
> {
> arch_m
On 20.09.2019 14:16, Alexandru Stefan ISAILA wrote:
> In order to have __hvm_copy() issue ~X86EMUL_RETRY a new return type,
> HVMTRANS_need_retry, was added and all the places that consume HVMTRANS*
> and needed adjustment where changed accordingly.
This is wrong and hence confusing: __hvm_copy()
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osst
On 20.09.2019 15:54, Jan Beulich wrote:
> Recent AMD processors may report up to 128 logical processors in CPUID
> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
> as the respective field is only 8 bits wide. Suppress doubling the value
> (and its leaf 0x8008 counterpart
Recent AMD processors may report up to 128 logical processors in CPUID
leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
as the respective field is only 8 bits wide. Suppress doubling the value
(and its leaf 0x8008 counterpart) in such a case.
Note that while there's a sim
flight 141481 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141481/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 85ccbee2abf4ac9ed006409d1b02a3bdd660261c
baseline version:
ovmf b0c15fb128c518b9acd86
Hi Julien
+
+int __init iommu_add_dt_device(struct dt_device_node *np)
Sorry to only realise it now. Would it make sense to have this
function implemented in xen/passthrough/device_tree.c?
Not entirely sure. device_tree.c is a common code. The iommu_fwspec
stuff (widely used in t
On 19/09/2019 14:26, Oleksandr wrote:
On 19.09.19 15:29, Julien Grall wrote:
Hi,
Hi, Julien
Hi,
+
+int __init iommu_add_dt_device(struct dt_device_node *np)
Sorry to only realise it now. Would it make sense to have this function
implemented in xen/passthrough/device_tree.c?
Not
On 20.09.2019 14:40, Andrew Cooper wrote:
> Overall, I would suggest doing the absolute minimum change required to
> unbreak Rome CPUs.
Well, okay, I'm zapping everything else, but it feels wrong to
leave in place the similar overflow in intel_xc_cpuid_policy().
Jan
_
On 20.09.19 03:31, Stefano Stabellini wrote:
Hi, Stefano.
On Tue, 20 Aug 2019, Oleksandr wrote:
On 20.08.19 15:22, Julien Grall wrote:
Hi, Julien
-iommu_setup();
+rc = iommu_setup();
+if ( !iommu_enabled && rc != -ENODEV )
+panic("Couldn't configure correctly all the
On 20.09.19 03:25, Yoshihiro Shimoda wrote:
Hi Oleksandr-san,
Hi, Shimoda-san
From: Oleksandr Tyshchenko, Sent: Saturday, September 14, 2019 12:35 AM
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and acc
> On 19. Sep 2019, at 17:18, Ross Lagerwall wrote:
>
> On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
>> Livepatch only tracks an entire payload applied/reverted state. But,
>> with an option to supply the apply_payload() and/or revert_payload()
>> functions as optional hooks, it becomes possi
On 20/09/2019 11:20, Jan Beulich wrote:
> On 20.09.2019 12:05, Andrew Cooper wrote:
>> On 19/09/2019 12:48, Jan Beulich wrote:
>>> Recent AMD processors may report up to 128 logical processors in CPUID
>>> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
>>> as the respective
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receiving vm_events for them is a pessimization. We try here to
optimize by filtering these events out.
Currently, we are fully emulating the instruction at RIP when the hardware sees
an EPT fault with npfec.kind
flight 141498 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141498/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
On 03.09.2019 18:14, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -1493,9 +1493,18 @@ int hvm_send_ioreq(ioservid_t id, ioreq_t *proto_p,
> bool buffered)
>
> ASSERT(s);
>
> +if ( hvm_ioreq_is_internal(id) && buffered )
> +{
> +
Ian Jackson writes ("Re: [PATCH] libxlu: Handle += in config files"):
> Anthony PERARD writes ("Re: [PATCH] libxlu: Handle += in config files"):
> > I wonder if instead of doing += on all strings, we should instead have
> > `xl' whitelist the few options where += would make sense. (and at that
> >
Ian Jackson writes ("Re: [PATCH] tools: fix linking hypervisor includes to
tools include directory"):
> Juergen Gross writes ("[PATCH] tools: fix linking hypervisor includes to
> tools include directory"):
> > An incremental build of tools/include won't pickup new hypervisor
> > headers in tools/
On 03.09.2019 18:14, Roger Pau Monne wrote:
> @@ -821,6 +851,9 @@ int hvm_create_ioreq_server(struct domain *d, int
> bufioreq_handling,
> if ( i >= MAX_NR_IOREQ_SERVERS )
> goto fail;
>
> +ASSERT((internal &&
> +i >= MAX_NR_EXTERNAL_IOREQ_SERVERS && i < MAX_NR_IORE
flight 141471 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141471/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 139910
test-amd64-i386-pair
On 03.09.2019 18:14, Roger Pau Monne wrote:
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -52,21 +52,29 @@ struct hvm_ioreq_vcpu {
> #define MAX_NR_IO_RANGES 256
>
> struct hvm_ioreq_server {
> -struct domain *target, *emulator;
> -
> +
On 10.09.2019 14:31, Paul Durrant wrote:
>> -Original Message-
>> From: Roger Pau Monne
>> Sent: 03 September 2019 17:14
>> To: xen-devel@lists.xenproject.org
>> Cc: Roger Pau Monne ; Jan Beulich ;
>> Andrew Cooper
>> ; Wei Liu ; George Dunlap
>> ; Ian
>> Jackson ; Julien Grall ;
>> Kon
On 20.09.2019 11:51, Oleksandr wrote:
>>> On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -35,6 +35,15 @@
#define xzalloc_array(_type, _num) \
((_type *)_xzalloc_array(sizeof(_type), __alignof__(_ty
On 20.09.2019 12:05, Andrew Cooper wrote:
> On 19/09/2019 12:48, Jan Beulich wrote:
>> Recent AMD processors may report up to 128 logical processors in CPUID
>> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
>> as the respective field is only 8 bits wide. Suppress doubling t
On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
> PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE/PCI
On 19/09/2019 12:48, Jan Beulich wrote:
> Recent AMD processors may report up to 128 logical processors in CPUID
> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
> as the respective field is only 8 bits wide. Suppress doubling the value
> (and its leaf 0x8008 counterpart
Hi Jan
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -35,6 +35,15 @@
#define xzalloc_array(_type, _num) \
((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type),
_num))
+/* Allocate space for a structure wi
On Thu, Sep 19, 2019 at 08:17:43PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v2 00/35] libxl refactoring to use ev_qmp
> (with API changes)"):
> > Patches with missing ackes:
> ...
> > libxl: Use ev_qmp in libxl_set_vcpuonline
>
> From my point of view I seem to have sent a a
Hi,
On 20/09/2019 00:37, Stefano Stabellini wrote:
On Tue, 17 Sep 2019, Julien Grall wrote:
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
map/unmap page tables while update Xen page-tables.
Since commit 022387e
After commit 6e3e771203 "xen/arm: setup: Relocate the Device-Tree later on
in the boot", the boot allocator will not receive any xenheap page (i.e.
mapped page) on Arm32.
However, the boot allocator implicitely rely on having the first page
already mapped and therefore result to break boot on Arm3
Hi Stefano,
On 20/09/2019 09:48, Jan Beulich wrote:
On 20.09.2019 00:49, Stefano Stabellini wrote:
On Tue, 17 Sep 2019, Julien Grall wrote:
@@ -665,6 +666,11 @@ static void __init setup_mm(void)
setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
+/* We ne
On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -254,7 +254,13 @@ void __init clear_irq_vector(int irq)
> /*
> * Dynamic irq allocate and deallocation for MSI
> */
> -int create_irq(nodeid_t node)
> +
> +/*
> + * create_irq - a
On 20.09.2019 10:50, Andrew Cooper wrote:
> On 19/09/2019 11:37, Jan Beulich wrote:
>> hvm_monitor_cpuid() expects the input registers, not two of the outputs.
>
> Perhaps worth nothing that this has been broken since its introduction
> in c/s d05f1eb3741b85 ?
Ah, yes, I should have done this. I'
On 19/09/2019 11:37, Jan Beulich wrote:
> hvm_monitor_cpuid() expects the input registers, not two of the outputs.
Perhaps worth nothing that this has been broken since its introduction
in c/s d05f1eb3741b85 ?
>
> However, once having made the necessary adjustment, the SVM and VMX
> functions are
On 20.09.2019 00:49, Stefano Stabellini wrote:
> On Tue, 17 Sep 2019, Julien Grall wrote:
>> @@ -665,6 +666,11 @@ static void __init setup_mm(void)
>>
>> setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages,
>> xenheap_pages);
>>
>> +/* We need a single mapped page for populating
On 20.09.2019 10:39, Alexandru Stefan ISAILA wrote:
>
>
> On 19.09.2019 13:37, Jan Beulich wrote:
>> hvm_monitor_cpuid() expects the input registers, not two of the outputs.
>>
>> However, once having made the necessary adjustment, the SVM and VMX
>> functions are so similar that they should be f
On 19.09.2019 13:37, Jan Beulich wrote:
> hvm_monitor_cpuid() expects the input registers, not two of the outputs.
>
> However, once having made the necessary adjustment, the SVM and VMX
> functions are so similar that they should be folded (thus avoiding
> further similar asymmetries to get int
On 20.09.2019 11:24, Jan Beulich wrote:
> On 20.09.2019 10:06, Alexandru Stefan ISAILA wrote:
>> On 19.09.2019 16:59, Jan Beulich wrote:
>>> Furthermore while you now restrict the check to linear address
>>> based accesses, other than the description says (or at least
>>> implies) you do not rest
On 19.09.2019 23:38, Joe Jin wrote:
> On 9/19/19 3:24 AM, Jan Beulich wrote:
>> What's
>> still missing is the further updating of pirq_dpci->gmsi.dest_vcpu_id
>> (as explained before, still visible in context above).
>>
>
> 422
> 423 dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_
On 20.09.2019 10:06, Alexandru Stefan ISAILA wrote:
> On 19.09.2019 16:59, Jan Beulich wrote:
>> Furthermore while you now restrict the check to linear address
>> based accesses, other than the description says (or at least
>> implies) you do not restrict it to read and exec accesses. It's
>> not c
On 19.09.2019 17:09, Paul Durrant wrote:
>> -Original Message-
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index fdb1e17f59..4cc077bb3f 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3236,6 +3236,19 @@ static enum hvm_translation_resul
On 19.09.2019 16:59, Jan Beulich wrote:
> On 19.09.2019 15:03, Alexandru Stefan ISAILA wrote:
>> @@ -601,6 +602,7 @@ static void *hvmemul_map_linear_addr(
>>
>> case HVMTRANS_gfn_paged_out:
>> case HVMTRANS_gfn_shared:
>> +case HVMTRANS_bad_gfn_access:
>>
flight 141494 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141466 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141466/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 140282
Tests which did n
78 matches
Mail list logo
