On Mon, Aug 20, 2018 at 11:42:30AM -0700, Christopher Clark wrote:
> Fixing top-level "make uninstall":
>
> tools/tests/x86_emulator is missing an uninstall target, which causes
> failure. Trivial to add one since it installs nothing, so do that.
>
> Linux hotplug uninstall returns success but do
On Tue, Aug 21, 2018 at 09:44:01AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add support for Linux grant device driver extension which allows
> converting existing dma-buf's into an array of grant references
> and vise versa. This is only implemented for Linux as o
>>> On 20.08.18 at 20:42, wrote:
> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -126,6 +126,9 @@ distclean: clean
> .PHONY: install
> install:
>
> +.PHONY: uninstall
> +uninstall:
To be honest, since we're not expecting these two goals to ever
become
This avoids repeated calls to page_is_ram_type which improves
performance and makes the code easier to read.
No functional change.
Signed-off-by: Roger Pau Monné
---
Changes since v4:
- New in this version.
---
Cc: Jan Beulich
---
xen/drivers/passthrough/x86/iommu.c | 60 +++--
Hello,
The following series implement a workaround for missing RMRR
entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
option.
The PVH workaround identity maps all regions marked as reserved in the
memory map.
Note that this workaround is enabled by default on Intel hardware.
Introduce a new dom0-iommu=map-inclusive generic option that
supersedes iommu_inclusive_mapping. The previous behavior is preserved
and the option should only be enabled by default on Intel hardware.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Changes s
To select the iommu configuration used by Dom0. This option supersedes
iommu=dom0-strict|dom0-passthrough.
Signed-off-by: Roger Pau Monné
---
Changes since v5:
- Fix typo in docs.
- Force iommu_hwdom_passthrough to false for PVH Dom0. Note this in
the documentation.
Changes since v4:
- Mov
Several people have reported hardware issues (malfunctioning USB
controllers) due to iommu page faults on Intel hardware. Those faults
are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
be worked around on VTd hardware by manually adding RMRR entries on
the command line, this is
To iommu_hwdom_strict and iommu_hwdom_passthrough which is more
descriptive of their usage. Also change their type from bool_t to
bool.
No functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Suravee Suthikulpanit
Cc: Brian Wood
Returns all the memory types applicable to a page.
This function is unimplemented for ARM.
Signed-off-by: Roger Pau Monné
---
Changes since v5:
- Return all types that apply to a page, since the types themselves
are flags that can be or'ed together.
---
Cc: Stefano Stabellini
Cc: Julien Gra
>>> On 17.08.18 at 17:12, wrote:
> Move it to x86 generic code. While at it, use proper boolean type.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
with a couple of cosmetic adjustments beyond the bool
conversion you've already done:
> +bool is_var_mtrr_overlapped(const struct mtrr_state *
>>> On 17.08.18 at 17:12, wrote:
> p2m_flush is only called by HAP code, nvcpu_flush is only useful for
> nestedhvm, both of which depend on HVM support.
>
> Enclose their code in CONFIG_HVM. Add assertions.
But why do you put the #ifdef-s inside the functions, rather than
around them? From what
>>> On 17.08.18 at 17:12, wrote:
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -2,8 +2,9 @@ subdir-y += shadow
> subdir-y += hap
>
> obj-y += paging.o
> -obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
> -obj-y += altp2m.o
> +obj-y += p2m.o p2m-pt.o p2m-pod.o
> +obj-$(CONF
On Tue, Aug 21, 2018 at 01:36:54AM -0600, Jan Beulich wrote:
> >>> On 20.08.18 at 20:42, wrote:
> > --- a/tools/tests/x86_emulator/Makefile
> > +++ b/tools/tests/x86_emulator/Makefile
> > @@ -126,6 +126,9 @@ distclean: clean
> > .PHONY: install
> > install:
> >
> > +.PHONY: uninstall
> > +unin
On Fri, Aug 17, 2018 at 04:12:48PM +0100, Wei Liu wrote:
> Move the common parts to emul-i8254.c. This requires moving some of
> the macros to vpt.h. Some of the code in common code is put under
> is_hvm_* checks so that DCE can kick in. Factor out HVM only
> pit_load_count_channel0 to reduce amoun
>>> On 17.08.18 at 17:12, wrote:
> The code snippet in question is to detect NMI held by SVM until STGI
> is called. When Xen doesn't even support HVM guests there is no need
> to check svm_stgi_label.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
On Fri, Aug 17, 2018 at 04:12:21PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Fri, Aug 17, 2018 at 04:12:24PM +0100, Wei Liu wrote:
> The one in context_switch is fixed by annotating with __maybe_unused
> because I want to keep prevd around.
>
> The other is fixed by eliminating v.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
> ---
> xen/arch/x86/domain.
On 21/08/2018 09:09, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:24PM +0100, Wei Liu wrote:
>> The one in context_switch is fixed by annotating with __maybe_unused
>> because I want to keep prevd around.
>>
>> The other is fixed by eliminating v.
>>
>> Signed-off-by: Wei Liu
> Reviewed-
On Fri, Aug 03, 2018 at 04:03:54PM +0200, Roger Pau Monné wrote:
> On Fri, Aug 03, 2018 at 02:54:20PM +0100, Anthony PERARD wrote:
> > On Thu, Aug 02, 2018 at 11:35:53AM +0200, Roger Pau Monné wrote:
> > > On Fri, Jul 27, 2018 at 03:05:55PM +0100, Anthony PERARD wrote:
> > > > +typedef enum {
> > >
On 20/08/18 18:43, Dario Faggioli wrote:
> On a system with hyperthreading, we currently allow putting cpus that
> are SMT siblings in different cpupools. This is bad for a number of
> reasons.
>
> For instance, the schedulers can't know whether or not a core is fully
> idle or not, if the threads
On Thu, Aug 02, 2018 at 12:01:23PM +0200, Roger Pau Monné wrote:
> On Fri, Jul 27, 2018 at 03:05:57PM +0100, Anthony PERARD wrote:
> > This allow to parse a string that is not NUL-terminated. With that
>^ allows
> > options disabled, YAJL v2 would look ahead on completion to find out if
>
On Fri, Jul 27, 2018 at 03:05:58PM +0100, Anthony PERARD wrote:
> Allow to generate a JSON string from a libxl__json_object,
> usefull for debugging.
>
> Signed-off-by: Anthony PERARD
> Acked-by: Ian Jackson
Acked-by: Wei Liu
___
Xen-devel mailing l
>>> On 17.08.18 at 17:12, wrote:
> @@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
> ? sizeof(sh_ctxt->insn_buf) : 0;
>
> return &hvm_shadow_emulator_ops;
> +#else
> +BUG();
> +return NULL;
> +#endif
> }
The sole invocation of the function sits r
On Fri, Aug 17, 2018 at 04:12:43PM +0100, Wei Liu wrote:
> Enclose HVM only emulation code under CONFIG_HVM. Add some BUG()s to
> to catch any issue.
>
> Note that although some code checks is_hvm_*, which hints it can be
> called for PV as well, I can't find such paths.
>
> Signed-off-by: Wei Li
On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> hvm_directio is set when iommu is enabled, but in fact iommu is not
> tied to HVM. In order to not break existing tools, expose a new flag
> directio for (iommu_enabled && !hvm_enabled).
>
> RFC This doesn't build at the moment. Do we care
On Fri, Aug 17, 2018 at 04:12:45PM +0100, Wei Liu wrote:
> They reference hvm_inject_event which is HVM code (not compiled). They
> aren't used by code outside HVM code anyway.
Can you put all the functions inside of an #ifdef CONFIG_HVM instead
of making them no-ops?
Thanks, Roger.
>>> On 21.08.18 at 10:29, wrote:
> On Fri, Aug 17, 2018 at 04:12:43PM +0100, Wei Liu wrote:
>> @@ -2723,12 +2736,13 @@ static int sh_remove_all_mappings(struct domain *d,
>> mfn_t gmfn, gfn_t gfn)
>> && (page->count_info & PGC_count_mask) <= 3
>> && ((page->u.inuse
On Fri, Aug 17, 2018 at 04:12:51PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 17.08.18 at 17:12, wrote:
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> }
> else
> {
> +#if CONFIG_HVM
> /* Magic MMIO marker: extract
On Tue, 2018-08-21 at 10:25 +0200, Juergen Gross wrote:
> On 20/08/18 18:43, Dario Faggioli wrote:
> >
> > Therefore, let's start allowing in a cpupool only cpus that have
> > their
> > SMT siblings, either:
> > - in that same pool,
> > - outside of any pool.
>
> Can we make this optional somehow
On Fri, Jul 27, 2018 at 03:06:03PM +0100, Anthony PERARD wrote:
> Remove the libxl__qmp_handler* argument so the function can be reused
> later in a different context.
>
> Signed-off-by: Anthony PERARD
> Acked-by: Ian Jackson
Acked-by: Wei Liu
___
X
On Fri, Aug 03, 2018 at 06:25:00PM +0100, Anthony PERARD wrote:
> > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > > index 4a385801ba..e104fea941 100644
> > > --- a/tools/libxl/libxl_types.idl
> > > +++ b/tools/libxl/libxl_types.idl
> > > @@ -69,6 +69,10 @@ libxl_error
On Fri, Jul 27, 2018 at 03:06:05PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
> ---
> tools/libxl/libxl_qmp.c | 36 ++--
> 1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index
On Fri, Jul 27, 2018 at 03:06:06PM +0100, Anthony PERARD wrote:
> There is no need for it.
>
> Signed-off-by: Anthony PERARD
> Acked-by: Ian Jackson
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject
On Tue, Aug 07, 2018 at 03:40:17PM +0100, Anthony PERARD wrote:
> On Tue, Aug 07, 2018 at 04:18:21PM +0200, Roger Pau Monné wrote:
> > On Mon, Aug 06, 2018 at 06:20:50PM +0100, Anthony PERARD wrote:
> > > On Thu, Aug 02, 2018 at 05:50:52PM +0200, Roger Pau Monné wrote:
> > > > On Fri, Jul 27, 2018
When TBOOT enabled, acpi_parse_dmar() called acpi_dmar_zap() to zap
DMAR table, then tboot_parse_dmar_table() called acpi_dmar_zap() to
zap it again. This is unnecessory, remove the second call.
Some stale comments not right for current code are also removed.
No functional change.
Signed-off-by:
On Wed, Aug 01, 2018 at 04:41:24PM +0100, George Dunlap wrote:
> mem-set is the primary command that users will need to use and
> understand. Move it first, and clarify the wording; also specify that
> you can't set the target higher than maxmem from the domain config.
>
> mem-max is actually a p
On Mon, Aug 13, 2018 at 03:06:10PM +0200, Juergen Gross wrote:
> Today's interface of Xen for memory ballooning is quite a mess. There
> are some shortcomings which should be addressed somehow. After a
> discussion on IRC there was consensus we should try to design a new
> interface addressing the
This run is configured for baseline tests only.
flight 75095 xen-4.10-testing real [real]
http://osstest.xensource.com/osstest/logs/75095/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-instal
On Wed, Aug 15, 2018 at 07:34:33PM +0100, Andrew Cooper wrote:
> Replace pfn_to_paddr(mfn_x(...)) with mfn_to_maddr(), and replace an opencoded
> gfn_to_gaddr().
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen
On Wed, Aug 15, 2018 at 07:34:35PM +0100, Andrew Cooper wrote:
> Drop the now-unused SH_L1E_MMIO_GFN_SHIFT definition.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproj
On Wed, Aug 15, 2018 at 07:34:36PM +0100, Andrew Cooper wrote:
> Use bool when appropraite, remove extranious brackets and fix up comment
> style.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing
On Wed, Aug 15, 2018 at 07:34:37PM +0100, Andrew Cooper wrote:
> ... as the only user of sl1mfn would prefer it that way.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenp
flight 126316 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126316/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, Aug 21, 2018 at 10:58:18AM +0100, Wei Liu wrote:
> On Mon, Aug 13, 2018 at 03:06:10PM +0200, Juergen Gross wrote:
> > Today's interface of Xen for memory ballooning is quite a mess. There
> > are some shortcomings which should be addressed somehow. After a
> > discussion on IRC there was co
On Thu, Aug 16, 2018 at 10:07:00AM +0100, Andrew Cooper wrote:
> Irrespective of what we do here, I'd really like Wei to rebase his work
> to remove the lazy fpu logic from the nested virt paths, because its a
> no-brainer (perf wise) and comes with a massive amount of code
> simplification in Xen.
Dario Faggioli writes ("Re: [Xen-devel] [PATCH] tools: libxl/xl: run NUMA
placement even when an hard-affinity is set"):
> On Mon, 2018-08-20 at 11:14 +0100, Wei Liu wrote:
> > You can use NDEBUG instead.
>
> I found this in one other place in libxl (libxl_event.c), and figured I
> could use it h
On Tue, Aug 21, 2018 at 10:32:18AM +0200, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> > hvm_directio is set when iommu is enabled, but in fact iommu is not
> > tied to HVM. In order to not break existing tools, expose a new flag
> > directio for (iommu_enable
Roger Pau Monné writes ("Re: [PATCH 2/2] osstest: configure git proxy for
FreeBSD"):
> On Mon, Aug 20, 2018 at 03:04:37PM +0100, Ian Jackson wrote:
> > And similar things from cron. I have rewound pretest and will await
> > updated patches...
>
> Sorry, here is a working branch:
>
> git://xenbi
On Mon, Aug 20, 2018 at 06:05:13AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > --- /dev/null
> > +++ b/xen/drivers/passthrough/vtd/x86/hvm.c
> > @@ -0,0 +1,77 @@
> > +/*
> > + * Copyright (c) 2008, Intel Corporation.
> > + *
> > + * This program is free software; you can redis
flight 126235 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126235/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-i386-libvirt-xsm 13 migrat
On Tue, Aug 21, 2018 at 11:25:58AM +0100, Wei Liu wrote:
> On Tue, Aug 21, 2018 at 10:32:18AM +0200, Roger Pau Monné wrote:
> > On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> > > hvm_directio is set when iommu is enabled, but in fact iommu is not
> > > tied to HVM. In order to not break
On Mon, Aug 20, 2018 at 01:59:57PM +0100, Andrew Cooper wrote:
> On 17/08/2018 16:12, Wei Liu wrote:
> > Signed-off-by: Wei Liu
> > ---
> > xen/common/domain.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index
On Tue, Aug 21, 2018 at 12:40:22PM +0200, Roger Pau Monné wrote:
> On Tue, Aug 21, 2018 at 11:25:58AM +0100, Wei Liu wrote:
> > On Tue, Aug 21, 2018 at 10:32:18AM +0200, Roger Pau Monné wrote:
> > > On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> > > > hvm_directio is set when iommu is e
add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.
In general, we should hold the device_hotplug
This is the same approach as in the first RFC, but this time without
exporting device_hotplug_lock (requested by Greg) and with some more
details and documentation regarding locking. Tested only on x86 so far.
--
Reading thro
remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported. So let's provide a variant
that takes the lock and only export that one.
The lock is already held in
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
So,
There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
fix concurrent memory hot-add deadlock"), which tried to fix a possible
lock inversion reported and discussed in [1] due to the two locks
a) device_lock()
b) mem_hotplug_lock
While add_memory() first takes b), f
device_online() should be called with device_hotplug_lock() held.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Signed-off-by: David Hildenbrand
---
arch/powerpc/platforms/powernv/memtrace.c | 2 ++
1 file changed
Let's document the magic a bit, especially why device_hotplug_lock is
required when adding/removing memory and how it all play together with
requests to online/offline memory from user space.
Cc: Jonathan Corbet
Cc: Michal Hocko
Cc: Andrew Morton
Signed-off-by: David Hildenbrand
---
Documenta
Let's perform all checking + offlining + removing under
device_hotplug_lock, so nobody can mess with these devices via
sysfs concurrently.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Signed-off-by: David Hildenbra
While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
this then became equivalent to "xpti=no". In particular, the presence
of "xpti=" alone on the command line means nothing as to which
default is to be overridden; "x
On Sun, Aug 19, 2018 at 07:41:11PM +0300, Razvan Cojocaru wrote:
> On 8/17/18 6:12 PM, Wei Liu wrote:
> > Ideally the HVM specific part of VM event should be moved into hvm/ at
> > some point, but this will do for now.
> >
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86/vm_event.c | 2 ++
> >
flight 126244 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126244/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125959
test-amd64-i386-xl-qemuu-win7-amd64
On Tue, Aug 21, 2018 at 10:00:14AM +0100, Wei Liu wrote:
> On Fri, Jul 27, 2018 at 03:06:05PM +0100, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
> > ---
> > tools/libxl/libxl_qmp.c | 36 ++--
> > 1 file changed, 30 insertions(+), 6 deletions(-)
> >
> >
On 8/21/18 1:45 PM, Wei Liu wrote:
> On Sun, Aug 19, 2018 at 07:41:11PM +0300, Razvan Cojocaru wrote:
>> On 8/17/18 6:12 PM, Wei Liu wrote:
>>> Ideally the HVM specific part of VM event should be moved into hvm/ at
>>> some point, but this will do for now.
>>>
>>> Signed-off-by: Wei Liu
>>> ---
>>> On 21.08.18 at 03:11, wrote:
> flight 126201 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/126201/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-libvirt-pair 22 guest-migra
>>> On 21.08.18 at 12:10, wrote:
> On Thu, Aug 16, 2018 at 10:07:00AM +0100, Andrew Cooper wrote:
>> Irrespective of what we do here, I'd really like Wei to rebase his work
>> to remove the lazy fpu logic from the nested virt paths, because its a
>> no-brainer (perf wise) and comes with a massive
flight 75096 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75096/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install fail like 75064
test-amd64-i386-i386-sid-netboot-pvgrub
>>> On 17.08.18 at 17:12, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/mm/shadow/hvm.c
> @@ -0,0 +1,590 @@
> +
> +/**
> + * arch/x86/mm/shadow/hvm.c
> + *
> + * Shadow code that does not need to be multiply compiled and is
>>> On 17.08.18 at 17:12, wrote:
> They reference hvm_inject_event which is HVM code (not compiled). They
> aren't used by code outside HVM code anyway.
Again looks to be a case of DCE doing its job (if arranged for properly)
instead of adding #ifdef-s to functions which ought to be entirely
unav
>>> On 17.08.18 at 17:12, wrote:
> Nested HVM is not enabled when !CONFIG_HVM.
All callers of the function sit under hvm/, so once again I don't see
why the function needs to remain available with an empty body.
Jan
___
Xen-devel mailing list
Xen-de
>>> On 17.08.18 at 17:12, wrote:
> Move the common parts to emul-i8254.c. This requires moving some of
> the macros to vpt.h. Some of the code in common code is put under
> is_hvm_* checks so that DCE can kick in. Factor out HVM only
> pit_load_count_channel0 to reduce amount of code in x86 common
On Tue, Aug 21, 2018 at 05:14:54AM -0600, Jan Beulich wrote:
> >>> On 21.08.18 at 03:11, wrote:
> > flight 126201 xen-4.9-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/126201/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including
>>> On 17.08.18 at 17:12, wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -318,8 +318,14 @@ struct domain *domain_create(domid_t domid,
> if ( !is_idle_domain(d) )
> {
> if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
> +{
> +#if CONFIG_HVM
>
>>> On 17.08.18 at 17:12, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>
> config HVM
> def_bool y
> + prompt "HVM / PVH support"
> + ---help---
> + Interfaces to support HVM and PVH guests.
> +
> + If
>>> On 17.08.18 at 17:12, wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
> if ( hvm_enabled )
> pi->capabilitie
>>> On 21.08.18 at 13:44, wrote:
> On Tue, Aug 21, 2018 at 05:14:54AM -0600, Jan Beulich wrote:
>> The apparently same issue is blocking 4.7, and I think it is only
>> because of some earlier force-push and/or "fail pass in" that 4.8
>> and 4.6 aren't blocked by this. The failures look to always b
On 21/08/18 12:44, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no". In particular, the presence
> of "xpti=" alone on the command line means nothi
On 21/08/18 12:44, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no". In particular, the presence
> of "xpti=" alone on the command line means nothi
On 21/08/18 14:04, Juergen Gross wrote:
> On 21/08/18 12:44, Jan Beulich wrote:
>> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
>> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
>> this then became equivalent to "xpti=no". In particular, the presence
>> of
>>> On 21.08.18 at 11:11, wrote:
> @@ -490,10 +488,6 @@ int __init tboot_parse_dmar_table(acpi_table_handler
> dmar_handler)
> rc = dmar_handler(dmar_table);
> xfree(dmar_table);
>
> -/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */
> -/* but dom0 will read r
>>> On 21.08.18 at 14:13, wrote:
> On 21/08/18 12:44, Jan Beulich wrote:
>> @@ -219,17 +216,13 @@ static int __init parse_spec_ctrl(const
>> }
>> custom_param("spec-ctrl", parse_spec_ctrl);
>>
>> -int8_t __read_mostly opt_pv_l1tf = -1;
>> +uint8_t __read_mostly opt_pv_l1tf = OPT_PV_L1TF_DOMU_D
>>> On 21.08.18 at 09:49, wrote:
> To select the iommu configuration used by Dom0. This option supersedes
> iommu=dom0-strict|dom0-passthrough.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.x
On 21/08/2018 12:48, Jan Beulich wrote:
On 17.08.18 at 17:12, wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>
>> config HVM
>> def_bool y
>> +prompt "HVM / PVH support"
>> + ---help---
>> + Interfaces to
On Tue, Aug 21, 2018 at 09:58:57AM +0100, Wei Liu wrote:
> On Fri, Aug 03, 2018 at 06:25:00PM +0100, Anthony PERARD wrote:
> > > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > > > index 4a385801ba..e104fea941 100644
> > > > --- a/tools/libxl/libxl_types.idl
> > > > +++
>>> On 21.08.18 at 09:49, wrote:
> Returns all the memory types applicable to a page.
>
> This function is unimplemented for ARM.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
But this should only go in together with the consumer of the new function
seeing that you didn't fold
>>> On 21.08.18 at 14:49, wrote:
> On 21/08/2018 12:48, Jan Beulich wrote:
> On 17.08.18 at 17:12, wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>>
>>> config HVM
>>> def_bool y
>>> + prompt "HVM / PVH support"
>>> +
On Tue, Aug 21, 2018 at 10:08:49AM +0100, Wei Liu wrote:
> On Tue, Aug 07, 2018 at 03:40:17PM +0100, Anthony PERARD wrote:
> > On Tue, Aug 07, 2018 at 04:18:21PM +0200, Roger Pau Monné wrote:
> > > On Mon, Aug 06, 2018 at 06:20:50PM +0100, Anthony PERARD wrote:
> > > > On Thu, Aug 02, 2018 at 05:50
>>> On 21.08.18 at 09:49, wrote:
> This avoids repeated calls to page_is_ram_type which improves
> performance and makes the code easier to read.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
I can't seem to be able to fully convince myself of the "No functional
change" part, bu
flight 126324 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126324/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 21.08.18 at 09:49, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -704,6 +704,15 @@ This list of booleans controls the iommu usage by Dom0:
>option is only applicable to a PV Dom0 and is enabled by default on Intel
>hardware.
>
On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > --- a/xen/arch/x86/sysctl.c
> > +++ b/xen/arch/x86/sysctl.c
> > @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> > min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.
On 21/08/18 14:40, Jan Beulich wrote:
On 21.08.18 at 14:13, wrote:
>> On 21/08/18 12:44, Jan Beulich wrote:
>>> @@ -219,17 +216,13 @@ static int __init parse_spec_ctrl(const
>>> }
>>> custom_param("spec-ctrl", parse_spec_ctrl);
>>>
>>> -int8_t __read_mostly opt_pv_l1tf = -1;
>>> +uint8_t
On Tue, Aug 21, 2018 at 01:58:51AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > Move it to x86 generic code. While at it, use proper boolean type.
> >
> > Signed-off-by: Wei Liu
>
> Acked-by: Jan Beulich
> with a couple of cosmetic adjustments beyond the bool
> conversion y
Anthony PERARD writes ("Re: [Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle
messages from QEMU"):
> I've already tried to have qmp specific error number, I've been asked to
> invent libxl error number instead:
> https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg01151.html
I stand by
On 08/15/2018 01:07 PM, Andrew Cooper wrote:
> OSVW data is technically per-cpu, but it is the firmwares reponsibility to
> make it equivelent on each cpu. A guests OSVW data is sources from global
> data in Xen, clearly making it per-domain data rather than per-vcpu data.
>
> Move the data from s
On Tue, 2018-08-21 at 11:25 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH] tools: libxl/xl: run
> NUMA placement even when an hard-affinity is set"):
> > On Mon, 2018-08-20 at 11:14 +0100, Wei Liu wrote:
> > > You can use NDEBUG instead.
> >
> > But I don't have a too
On Tue, Aug 21, 2018 at 07:36:17AM -0600, Jan Beulich wrote:
> >>> On 21.08.18 at 09:49, wrote:
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -704,6 +704,15 @@ This list of booleans controls the iommu usage by Dom0:
> >option is only applica
1 - 100 of 152 matches
Mail list logo
