flight 128367 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128367/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128331
test-armhf-armhf-libvirt-raw 13
On Mon, Sep 24, 2018 at 11:55:29AM +0100, Andy Cooper wrote:
> In practice, this allows the compiler to replace the loop with a pair of movs.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Brian Woods
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
>
On Mon, Sep 24, 2018 at 11:55:30AM +0100, Andy Cooper wrote:
> It is MASK_EXTR() in disguise, but less flexible.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Brian Woods
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Paul Durrant
> CC:
This run is configured for baseline tests only.
flight 75351 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/75351/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On Wed, 1 Aug 2018, Jan Beulich wrote:
> >>> On 01.08.18 at 01:28, wrote:
> > Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> > mechanism to allow for switching between Xen, Dom0, and any of the
> > initial DomU created from Xen alongside Dom0 out of information provided
> >
Hi Julien,
I'll remove the DOM prefix for the input domain, relying to the
"Switching..." message as you suggested.
Cheers,
Stefano
On Wed, 22 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 16/08/18 20:41, Stefano Stabellini wrote:
> > On Mon, 13 Aug 2018, Julien Grall wrote:
> > > Hi,
> > >
> >
flight 128363 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128363/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 128226
On Thu, 4 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 04/10/2018 00:11, Stefano Stabellini wrote:
> > On Wed, 1 Aug 2018, Julien Grall wrote:
> > > > +{
> > > > +mod = >cmdline[i];
> > > > +if ( mod->kind == kind )
> > > > +return mod;
> > > > +}
> > > >
On Wed, 1 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Don't add duplicate boot modules (same kind and same start address).
>
> Please explain why you don't want to duplicate it.
OK
> >
> > Mark kernels and ramdisks of "xen,domain" nodes as
On Thu, 4 Oct 2018 17:45:13 +0200
David Hildenbrand wrote:
> On 04/10/2018 17:28, Michal Suchánek wrote:
> >
> > The state of the art is to determine what to do with hotplugged
> > memory in userspace based on platform and virtualization type.
>
> Exactly.
>
> >
> > Changing the default
flight 128362 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128362/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12
Hi Peng,
On 04/10/2018 02:12, Peng Fan wrote:
-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 2018年10月3日 0:03
To: Peng Fan ; Stefano Stabellini
Cc: xen-devel@lists.xenproject.org; Andre Przywara
Subject: Re: Question, How to share interrupt between Doms
On
Hi Stefano,
On 04/10/2018 00:11, Stefano Stabellini wrote:
On Wed, 1 Aug 2018, Julien Grall wrote:
+{
+mod = >cmdline[i];
+if ( mod->kind == kind )
+return mod;
+}
+return NULL;
+}
+
const char * __init boot_module_kind_as_string(bootmodule_kind kind)
On 03/10/2018 22:21, Stefano Stabellini wrote:
On Wed, 22 Aug 2018, Julien Grall wrote:
On 16/08/18 20:21, Stefano Stabellini wrote:
On Mon, 13 Aug 2018, Julien Grall wrote:
Hi Stefano,
On 01/08/18 00:28, Stefano Stabellini wrote:
Make vpl011 being able to be used without a userspace
Hi Paul,
On 04/10/2018 11:45, Paul Durrant wrote:
The name 'need_iommu()' is a little confusing as it suggests a domain needs
to use the IOMMU but something might not be set up yet, when in fact it
represents a tri-state value (not a boolean as might be expected) where
-1 means 'IOMMU mappings
On Thu, Sep 27, 2018 at 1:59 AM Razvan Cojocaru
wrote:
>
> Currently there is a subop for setting the memaccess of a page, but not
> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
> functionality.
>
> Both altp2m get/set mem access functions use the struct
>
On 10/4/18 7:42 PM, Wei Liu wrote:
> It is discovered that hvm_funcs made it into monitor.o even when HVM
> is disabled. This version of clang doesn't seem to completely
> eliminate the code after is_hvm_domain() in
> arch_monitor_get_capabilities().
>
> Signed-off-by: Wei Liu
Acked-by: Razvan
flight 128380 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128380/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
It is discovered that hvm_funcs made it into monitor.o even when HVM
is disabled. This version of clang doesn't seem to completely
eliminate the code after is_hvm_domain() in
arch_monitor_get_capabilities().
Signed-off-by: Wei Liu
---
xen/include/asm-x86/hvm/hvm.h | 10 ++
On 10/4/18 7:04 PM, Jan Beulich wrote:
On 02.10.18 at 17:17, wrote:
>> +static void ept_set_ad_sync(struct p2m_domain *hostp2m, bool value)
>> +{
>> +struct domain *d = hostp2m->domain;
>> +
>> +ASSERT(p2m_is_hostp2m(hostp2m));
>> +ASSERT(p2m_locked_by_me(hostp2m));
>> +
>> +
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 04 October 2018 17:30
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Stefano Stabellini
> ; Andrew Cooper ; Ian
> Jackson ; Konrad Rzeszutek Wilk
> ; Tim (Xen.org) ; Jun Nakajima
> ;
On 10/04/2018 11:45 AM, Paul Durrant wrote:
> This patch removes the implicit domain_crash() from iommu_map(),
> unmap_page() and iommu_iotlb_flush() and turns them into straightforward
> wrappers that check the existence of the relevant iommu_op and call
> through to it. This makes them usable by
On 10/04/2018 11:45 AM, Paul Durrant wrote:
> The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
> domain's IOMMU pagetable which, prior to this patch, is not strictly true
> since the macro did not test whether the domain actually has IOMMU
> mappings.
>
> Signed-off-by:
On 10/04/2018 11:45 AM, Paul Durrant wrote:
> The name 'need_iommu()' is a little confusing as it suggests a domain needs
> to use the IOMMU but something might not be set up yet, when in fact it
> represents a tri-state value (not a boolean as might be expected) where
> -1 means 'IOMMU mappings
>>> On 02.10.18 at 17:17, wrote:
> +static void ept_set_ad_sync(struct p2m_domain *hostp2m, bool value)
> +{
> +struct domain *d = hostp2m->domain;
> +
> +ASSERT(p2m_is_hostp2m(hostp2m));
> +ASSERT(p2m_locked_by_me(hostp2m));
> +
> +hostp2m->ept.ad = value;
> +
> +if (
On 10/04/2018 11:45 AM, Paul Durrant wrote:
> ...for some uses of get_page_from_gfn().
>
> There are many occurrences of the following pattern in the code:
>
> q = ? P2M_ALLOC : P2M_UNSHARE;
> page = get_page_from_gfn(d, gfn, , q);
>
> if ( p2m_is_paging(p2mt) )
> {
>
This will give us a Xen setting in idle loop. This doesn't have
practical use except for debugging purpose.
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 6a44902..6ac5d32 100644
DCE couldn't have helped here because the invocation of switch_compat
also depends on external input.
Signed-off-by: Wei Liu
---
xen/include/xen/compat.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index 895e2ff..6f72353
They will be used by build tests.
Signed-off-by: Wei Liu
---
xen/arch/x86/configs/hvm_only_defconfig | 2 ++
xen/arch/x86/configs/no_hvm_pv_defconfig | 2 ++
xen/arch/x86/configs/pv_only_defconfig | 2 ++
3 files changed, 6 insertions(+)
create mode 100644
Signed-off-by: Wei Liu
---
xen/arch/x86/Kconfig | 8
1 file changed, 8 insertions(+)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 548cbf9..955443f 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -37,6 +37,14 @@ source "arch/Kconfig"
config PV
This is a bit more complicated than the HVM case because system
domains have PV guest type.
Instead of inventing a new guest type, we still set system domains'
type to PV. This shouldn't really matter in practice.
Signed-off-by: Wei Liu
---
xen/common/domain.c | 21 +++--
1
Instead of trying to split up entry.S and compat/entry.S, simply
provide some stubs for them.
Signed-off-by: Wei Liu
---
xen/arch/x86/x86_64/Makefile | 5 +-
xen/arch/x86/x86_64/no-pv.c | 41 +-
2 files changed, 46 insertions(+)
create mode 100644
Signed-off-by: Wei Liu
---
automation/scripts/build | 18 ++
1 file changed, 18 insertions(+)
diff --git a/automation/scripts/build b/automation/scripts/build
index c463b06..8af3fab 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -31,3 +31,21 @@ fi
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 6ac5d32..293c9aa 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1827,10 +1827,13 @@ void
On 10/04/2018 04:45 PM, Jan Beulich wrote:
On 04.10.18 at 17:34, wrote:
>> On 10/04/2018 04:20 PM, Jan Beulich wrote:
>> On 04.10.18 at 16:56, wrote:
The biggest problem here is p2m->logdirty_ranges. This patch will
(justly) not work, because struct rangeset is only
>>> On 17.11.17 at 07:22, wrote:
> This patchset is to introduce vIOMMU framework and add virtual VTD's
> interrupt remapping support according "Xen virtual IOMMU high level
> design doc V3"(https://lists.xenproject.org/archives/html/xen-devel/
> 2016-11/msg01391.html).
>
> - vIOMMU framework
>
On 04/10/2018 17:28, Michal Suchánek wrote:
> On Thu, 4 Oct 2018 10:13:48 +0200
> David Hildenbrand wrote:
>
> ok, so what is the problem here?
>
> Handling the hotplug in userspace through udev may be suboptimal and
> kernel handling might be faster but that's orthogonal to the problem at
>
>>> On 04.10.18 at 17:34, wrote:
> On 10/04/2018 04:20 PM, Jan Beulich wrote:
> On 04.10.18 at 16:56, wrote:
>>> The biggest problem here is p2m->logdirty_ranges. This patch will
>>> (justly) not work, because struct rangeset is only forward-declared in
>>> xen/rangeset.h, so an incomplete
The trap handlers in hypervisor need to forward events to PV guests if
necessary. If there is no PV guest relevant code should be excluded.
Put code under CONFIG_PV and add ASSERT_UNREACHABLE.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c | 38 ++
1 file
This series makes CONFIG_PV work.
Booting a hypervisor with PVH Dom0 works. It also creates / destroys HVM guests
just fine.
Due to issues in PVH implementation, XTF tests cause hypervisor to crash (seen
on staging as well).
root@lcy2-dt108:~# xl info
host : lcy2-dt108
release
This hypercall is PV only on x86. Provide a stub for it when
!CONFIG_PV.
Signed-off-by: Wei Liu
---
xen/arch/x86/hypercall.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 74bde5e..a2f4797 100644
---
It is used by PV code only.
Signed-off-by: Wei Liu
---
xen/arch/x86/cpu/amd.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index c394c1c..5e2112e 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -443,12 +443,14 @@
This is useful to rewrite the following pattern (v is PV vcpu)
if ( is_pv_32bit_vcpu(v) )
do_foo;
else
do_bar;
to
if ( is_pv_32bit_vcpu(v) )
do_foo;
else if ( is_pv_64bit_vcpu(v) )
do_bar;
else
ASSERT_UNREACHABLE;
.
Previously it is not
Signed-off-by: Wei Liu
---
xen/include/asm-x86/shadow.h | 4
1 file changed, 4 insertions(+)
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index b3ebe56..7d88637 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -163,6 +163,8 @@
Signed-off-by: Wei Liu
---
xen/arch/x86/dom0_build.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 86eb7db..4577111 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -509,8
Put PV only code under CONFIG_PV.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c | 55
1 file changed, 46 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 02abd06..f211383 100644
--- a/xen/arch/x86/mm.c
+++
And make them work with CONFIG_PV.
Signed-off-by: Wei Liu
---
xen/include/asm-x86/domain.h | 2 --
xen/include/xen/sched.h | 21 +++--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index
Provide declarations for hypercall_page_initialise_ring*_kernel, make
sure DCE work as expected.
Signed-off-by: Wei Liu
---
xen/arch/x86/x86_64/traps.c | 6 --
xen/include/asm-x86/hypercall.h | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git
>>> On 18.09.18 at 08:02, wrote:
> @@ -187,14 +191,24 @@ static int parse_params(const char *cmdline, const
> struct kernel_param *start,
> return final_rc;
> }
>
> +static const struct parse_data boot_parse_data = {
__initconstrel
With this
Acked-by: Jan Beulich
provided it will
>>> On 18.09.18 at 08:02, wrote:
> Define macros for filling struct kernel_param when defining parameters.
>
> Signed-off-by: Juergen Gross
> ---
> xen/include/xen/init.h | 58
> +-
> 1 file changed, 20 insertions(+), 38 deletions(-)
The
On 10/04/2018 04:20 PM, Jan Beulich wrote:
On 04.10.18 at 16:56, wrote:
>> The biggest problem here is p2m->logdirty_ranges. This patch will
>> (justly) not work, because struct rangeset is only forward-declared in
>> xen/rangeset.h, so an incomplete type here:
>>
>> -void
On Thu, 4 Oct 2018 10:13:48 +0200
David Hildenbrand wrote:
ok, so what is the problem here?
Handling the hotplug in userspace through udev may be suboptimal and
kernel handling might be faster but that's orthogonal to the problem at
hand.
The state of the art is to determine what to do with
>>> On 04.10.18 at 16:56, wrote:
> The biggest problem here is p2m->logdirty_ranges. This patch will
> (justly) not work, because struct rangeset is only forward-declared in
> xen/rangeset.h, so an incomplete type here:
>
> -void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
> +int
On 10/04/2018 11:45 AM, Paul Durrant wrote:
> This patch modifies the declaration of the entry points to the IOMMU
> sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent
> patch will similarly modify the methods in the iommu_ops structure.
>
> Signed-off-by: Paul Durrant
>
On 9/19/18 3:44 PM, George Dunlap wrote:
> On 09/19/2018 01:15 PM, George Dunlap wrote:
>> On 09/03/2018 09:25 AM, Razvan Cojocaru wrote:
>>> When an new altp2m view is created very early on guest boot, the
>>> display will freeze (although the guest will run normally). This
>>> may also happen on
On Wed 03-10-18 19:09:39, Arun KS wrote:
[...]
> +static int online_pages_blocks(unsigned long start, unsigned long nr_pages)
> +{
> + unsigned long end = start + nr_pages;
> + int order, ret, onlined_pages = 0;
> +
> + while (start < end) {
> + order = min(MAX_ORDER - 1UL,
>>> On 17.07.18 at 11:48, wrote:
> The current code detects enabling of the virtual functions feature and
> automatically adds the VFs to the domain. It also detects enabling of
> memory space and maps the VFs BARs into the domain p2m. Disabling of
> the VF enable bit removes the devices and the
flight 128375 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128375/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 75350 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75350/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
>>> On 04.10.18 at 12:45, wrote:
> The name 'need_iommu()' is a little confusing as it suggests a domain needs
> to use the IOMMU but something might not be set up yet, when in fact it
> represents a tri-state value (not a boolean as might be expected) where
> -1 means 'IOMMU mappings being set
On Thu, Oct 04, 2018 at 01:22:12PM +0100, Andrew Cooper wrote:
> On 02/10/18 17:36, Roger Pau Monne wrote:
> > Instead of just doing it for the BSP. This requires storing the
> > maximum number of possible vCPUs in xc_dom_image.
> >
> > This has been a latent bug so far because PVH doesn't yet
>>> On 04.10.18 at 12:45, wrote:
> The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
> domain's IOMMU pagetable which, prior to this patch, is not strictly true
> since the macro did not test whether the domain actually has IOMMU
> mappings.
>
> Signed-off-by: Paul
Hello Xen Developer Group,
One of my client needs help for about 5 months onsite in New Hampshire. Feel
free to reach out if interested:
5 Months (Needs to be completed by end of February 2019)
Rate Range: $100/ hr
MUST Skills:
Xen Project (OS) Hypervisor - this is what they are working on,
>>> On 04.10.18 at 15:20, wrote:
> On 04/10/18 11:45, Jan Beulich wrote:
> On 03.10.18 at 13:56, wrote:
>>> It turns out that Xen advertise the hardware APIC bit to PV guests,
>>> which isn't necessarily always set. On top of that, the default
>>> read/write-ignore behaviour of MSR lets
On 04/10/18 11:45, Jan Beulich wrote:
On 03.10.18 at 13:56, wrote:
>> A bug has recently been discovered internally, where a 4.14 dom0 was
>> observed to be doing this:
>>
>> (XEN) [ 16.035377] emul-priv-op.c:1166:d0v0 Domain attempted WRMSR
>> 001b from 0xfee00d00 to
Hi Paul,
On 04/10/2018 14:04, Paul Durrant wrote:
-Original Message-
From: Paul Durrant [mailto:paul.durr...@citrix.com]
Sent: 04 October 2018 11:46
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant ; Andrew Cooper
; George Dunlap
Subject: [PATCH v14 3/9] iommu: push use of type-safe
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 04 October 2018 11:46
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap
> Subject: [PATCH v14 3/9] iommu: push use of type-safe DFN and MFN into
> iommu_ops
>
> This
> On 4 Oct 2018, at 12:43, Andrew Cooper wrote:
>
> I stumbled into the issuse fixed by patch 2 while investigating an unrelated
> issue. The other two patches are just cleanup.
>
> Andrew Cooper (3):
> tools/ocaml: Strip all trailing whitespace
> oxenstored: Don't re-open a xenctrl handle
Having noticed that VMLOAD alone is about as fast as a single of the
involved WRMSRs, I thought it might be a reasonable idea to also use it
for PV. Measurements, however, have shown that an actual improvement can
be achieved only with an early prefetch of the VMCB (thanks to Andrew
for suggesting
>>> On 04.10.18 at 13:58, wrote:
> On 26/09/18 08:42, Jan Beulich wrote:
>> @@ -1630,6 +1646,66 @@ static void svm_init_erratum_383(const s
>> }
>> }
>>
>> +#ifdef CONFIG_PV
>> +bool svm_load_segs(unsigned int ldt_ents, unsigned long ldt_base,
>> + unsigned int fs_sel,
On 02/10/18 17:36, Roger Pau Monne wrote:
> Instead of just doing it for the BSP. This requires storing the
> maximum number of possible vCPUs in xc_dom_image.
>
> This has been a latent bug so far because PVH doesn't yet support
> pci-passthrough, so the effective memory cache attribute is forced
On 10/3/18 4:14 PM, Wei Liu wrote:
> On Thu, Sep 27, 2018 at 10:58:54AM +0300, Razvan Cojocaru wrote:
>> Currently there is a subop for setting the memaccess of a page, but not
>> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
>> functionality.
>>
>> Both altp2m get/set mem
On 26/09/18 08:42, Jan Beulich wrote:
> @@ -1630,6 +1646,66 @@ static void svm_init_erratum_383(const s
> }
> }
>
> +#ifdef CONFIG_PV
> +bool svm_load_segs(unsigned int ldt_ents, unsigned long ldt_base,
> + unsigned int fs_sel, unsigned long fs_base,
> +
flight 128337 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128337/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 5 host-ping-check-native fail REGR. vs. 128278
flight 128354 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128354/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-credit1 6 xen-install fail baseline untested
This wrapper hides an opening and closing of the xenctrl handle, which amongst
other things opens and closes multiple device files.
A process should create one handle at the start of day and reuse that; indeed
there is no guarentee that the process will retain sufficient permissions to
re-open
I stumbled into the issuse fixed by patch 2 while investigating an unrelated
issue. The other two patches are just cleanup.
Andrew Cooper (3):
tools/ocaml: Strip all trailing whitespace
oxenstored: Don't re-open a xenctrl handle for every domain introduction
tools/ocaml: Delete the
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Christian Lindig
---
tools/ocaml/LICENSE | 146 +++
tools/ocaml/libs/xc/xenctrl_stubs.c | 2 +-
tools/ocaml/libs/xl/genwrap.py | 44
On 10/04/2018 11:51 AM, Juergen Gross wrote:
> The per-cpu buffers for Xentrace are addressed by cpu-id, but the info
> array for the buffers is sized only by number of online cpus. This
> might lead to crashes when using Xentrace with smt=0.
>
> The t_info structure has to be sized based on
On 04/10/2018 13:22, George Dunlap wrote:
> On 10/04/2018 11:51 AM, Juergen Gross wrote:
>> Modify the xentrace utility to allow sparse cpu list resulting in not
>> all possible cpus having a trace buffer allocated.
>>
>> Signed-off-by: Juergen Gross
>
> This looks good:
>
> Reviewed-by: George
On 10/04/2018 11:51 AM, Juergen Gross wrote:
> Modify the xentrace utility to allow sparse cpu list resulting in not
> all possible cpus having a trace buffer allocated.
>
> Signed-off-by: Juergen Gross
This looks good:
Reviewed-by: George Dunlap
Would you mind if I fold in the attached
This run is configured for baseline tests only.
flight 75349 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75349/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
Modify the xentrace utility to allow sparse cpu list resulting in not
all possible cpus having a trace buffer allocated.
Signed-off-by: Juergen Gross
---
tools/xentrace/xentrace.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/tools/xentrace/xentrace.c
The per-cpu buffers for Xentrace are addressed by cpu-id, but the info
array for the buffers is sized only by number of online cpus. This
might lead to crashes when using Xentrace with smt=0.
The t_info structure has to be sized based on nr_cpu_ids.
Signed-off-by: Juergen Gross
---
When hyperthreads are disabled via smt=0 Xen boot parameter xentrace
is no longer working, but crashing the system.
Patch 1 makes the xentrace user tool work on systems when not all
possible cpu ids have an associated trace buffer allocated.
Patch 2 corrects xentrace handling by sizing the
This patch adds a new method to the VT-d IOMMU implementation to find the
MFN currently mapped by the specified DFN along with a wrapper function
in generic IOMMU code to call the implementation if it exists.
NOTE: This patch only adds a Xen-internal interface. This will be used by
a
...in intel_iommu_unmap_page().
This patch also includes some non-functional modifications in
intel_iommu_map_page().
Signed-off-by: Paul Durrant
Acked-by: Kevin Tian
---
Cc: Wei Liu
Cc: Jan Beulich
Cc: George Dunlap
v8:
- New in v8. (Split from the next patch in the series as requested
The name 'need_iommu()' is a little confusing as it suggests a domain needs
to use the IOMMU but something might not be set up yet, when in fact it
represents a tri-state value (not a boolean as might be expected) where
-1 means 'IOMMU mappings being set up' and 1 means 'IOMMU mappings have
been
This patch removes the implicit domain_crash() from iommu_map(),
unmap_page() and iommu_iotlb_flush() and turns them into straightforward
wrappers that check the existence of the relevant iommu_op and call
through to it. This makes them usable by PV IOMMU code to be delivered in
future patches.
...for some uses of get_page_from_gfn().
There are many occurrences of the following pattern in the code:
q = ? P2M_ALLOC : P2M_UNSHARE;
page = get_page_from_gfn(d, gfn, , q);
if ( p2m_is_paging(p2mt) )
{
if ( page )
put_page(page);
...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU
(rather than the MMU) and hence used for DMA address translation.
This patch is a largely cosmetic change that substitutes the terms 'gfn'
and 'gaddr' for 'dfn' and 'daddr' in all the places where the frame number
or
This patch modifies the methods in struct iommu_ops to use type-safe DFN
and MFN. This follows on from the prior patch that modified the functions
exported in xen/iommu.h.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monne
Acked-by: Jan
The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
domain's IOMMU pagetable which, prior to this patch, is not strictly true
since the macro did not test whether the domain actually has IOMMU
mappings.
Signed-off-by: Paul Durrant
Reviewed-by: Kevin Tian
Acked-by: Julien
This series contains pre-requisites and clean-up needed for paravirtual
IOMMU support.
I have separated these patches to avoid further delaying their application
whilst I re-work the implementation of paravirtual IOMMU after review of
v6 of the series. Several of them already have all necessary
This patch modifies the declaration of the entry points to the IOMMU
sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent
patch will similarly modify the methods in the iommu_ops structure.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
>>> On 03.10.18 at 13:56, wrote:
> A bug has recently been discovered internally, where a 4.14 dom0 was
> observed to be doing this:
>
> (XEN) [ 16.035377] emul-priv-op.c:1166:d0v0 Domain attempted WRMSR
> 001b from 0xfee00d00 to 0xfee00100
> (XEN) [ 16.035392]
On 02/10/18 11:16, Jan Beulich wrote:
> This looks to be the only frequently executed hook; don't bother
> patching any other ones.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
On 02/10/18 11:16, Jan Beulich wrote:
> This reduces the post-init memory footprint, eliminates a pointless
> level of indirection at the use sites, and allows for subsequent
> alternatives call patching.
>
> Take the opportunity and also add a name to the PowerNow! instance.
>
> Signed-off-by:
On 02/10/18 11:15, Jan Beulich wrote:
> For now only the ones used during entering/exiting of idle states are
> converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
> be converted, as they may get established rather late (when Dom0 is
> already active).
>
> Note that for patching
I notice this series now needs a re-base after some recent commits to staging.
I will send v14.
Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 02 October 2018 18:00
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ;
1 - 100 of 116 matches
Mail list logo
