Re: [Xen-devel] [PATCH v9 for Xen 4.7 3/4] libxl: enable per-VCPU parameter for RTDS

On Wed, Apr 06, 2016 at 02:20:55PM -0500, Chong Li wrote: > On Wed, Apr 6, 2016 at 1:54 PM, Andrew Cooper > wrote: > > On 06/04/16 17:41, Chong Li wrote: > >> On Wed, Apr 6, 2016 at 11:36 AM, Dario Faggioli > >> wrote: > >>> On Wed,

Re: [Xen-devel] [PATCH v3] arm: Fix asynchronous aborts (SError exceptions) due to bogus PTEs

Hi Julien/Stefano, Any other comments to be addressed? Please propose an alternative solution to fix the problem if this patch changes are not appropriate. On 03/28/2016 11:46 PM, Shanker Donthineni wrote: > From: Vikram Sethi > > ARMv8 architecture allows performing

Re: [Xen-devel] [PATCH v9 for Xen 4.7 3/4] libxl: enable per-VCPU parameter for RTDS

On Wed, Apr 06, 2016 at 02:41:31PM -0500, Chong Li wrote: > On Wed, Apr 6, 2016 at 2:30 PM, Wei Liu wrote: > > On Wed, Apr 06, 2016 at 02:20:55PM -0500, Chong Li wrote: > >> On Wed, Apr 6, 2016 at 1:54 PM, Andrew Cooper > >> wrote: > >> > On

Re: [Xen-devel] [PATCH v9 for Xen 4.7 3/4] libxl: enable per-VCPU parameter for RTDS

On Wed, Apr 6, 2016 at 1:54 PM, Andrew Cooper wrote: > On 06/04/16 17:41, Chong Li wrote: >> On Wed, Apr 6, 2016 at 11:36 AM, Dario Faggioli >> wrote: >>> On Wed, 2016-04-06 at 16:38 +0100, Ian Jackson wrote: Ian Jackson writes ("Re:

Re: [Xen-devel] [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.

> > --- a/xen/include/xen/version.h > > +++ b/xen/include/xen/version.h > > @@ -17,4 +17,7 @@ const char *xen_deny(void); > > #include > > int xen_build_id(const void **p, unsigned int *len); > > > > +#include > > +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int > >

[Xen-devel] [PATCH v2 03/11] xen: sched: move pCPU initialization in an helper

That will turn out useful in following patches, where such code will need to be called more than just once. Create an helper now, and move the code there, to avoid mixing code motion and functional changes later. In Credit2, some style cleanup is also done. No functional change intended.

Re: [Xen-devel] [PATCH v3] arm: Fix asynchronous aborts (SError exceptions) due to bogus PTEs

Hi Stefano/Julien, Any other comments to be addressed? Please propose an alternative solution to fix the problem if this patch changes are not appropriate. On 03/28/2016 11:46 PM, Shanker Donthineni wrote: > From: Vikram Sethi > > ARMv8 architecture allows performing

[Xen-devel] [PATCH v2] flask: change default state to enforcing

The previous default of "permissive" is meant for developing or debugging a disaggregated system. However, this default makes it too easy to accidentally boot a machine in this state, which does not place any restrictions on guests. This is not suitable for normal systems because any guest can

Re: [Xen-devel] [PATCH v9 for Xen 4.7 3/4] libxl: enable per-VCPU parameter for RTDS

On Wed, Apr 6, 2016 at 2:30 PM, Wei Liu wrote: > On Wed, Apr 06, 2016 at 02:20:55PM -0500, Chong Li wrote: >> On Wed, Apr 6, 2016 at 1:54 PM, Andrew Cooper >> wrote: >> > On 06/04/16 17:41, Chong Li wrote: >> >> On Wed, Apr 6, 2016 at 11:36 AM,

Re: [Xen-devel] [PATCH v9 for Xen 4.7 3/4] libxl: enable per-VCPU parameter for RTDS

On Wed, 2016-04-06 at 20:49 +0100, Wei Liu wrote: > On Wed, Apr 06, 2016 at 02:41:31PM -0500, Chong Li wrote: > > On Wed, Apr 6, 2016 at 2:30 PM, Wei Liu > > wrote: > > > On Wed, Apr 06, 2016 at 02:20:55PM -0500, Chong Li wrote: > > > Not sure what kind of sanity check you

Re: [Xen-devel] [PATCH v5 3/6] smp: add function to execute a function synchronously on a cpu

On Wed, Apr 06, 2016 at 04:17:43PM +0200, Juergen Gross wrote: > On some hardware models (e.g. Dell Studio 1555 laptop) some hardware > related functions (e.g. SMIs) are to be executed on physical cpu 0 > only. Instead of open coding such a functionality multiple times in > the kernel add a

[Xen-devel] [PATCH v2 02/11] xen: sched: implement .init_pdata in Credit, Credit2 and RTDS

In fact, if a scheduler needs per-pCPU information, that needs to be initialized appropriately. So, we take the code that is performing initializations from (right now) .alloc_pdata, and use it for .init_pdata, leaving only actualy allocations in the former, if any (which is the case in RTDS and

Re: [Xen-devel] [PATCH] xen: write information about supported backends

On Mon, 4 Apr 2016, Juergen Gross wrote: > On 01/04/16 16:56, Stefano Stabellini wrote: > > On Wed, 30 Mar 2016, Juergen Gross wrote: > >> Add a Xenstore directory for each supported pv backend. This will allow > >> Xen tools to decide which backend type to use in case there are > >> multiple

Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

On Thu, Mar 31, 2016 at 11:53 AM, Yu Zhang wrote: > A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to > let one ioreq server claim/disclaim its responsibility for the > handling of guest pages with p2m type p2m_ioreq_server. Users > of this HVMOP can

[Xen-devel] [PATCH v2 00/11] Fixes and improvement (including hard affinity!) for Credit2

Hi, Here's v2 of this series: http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02544.html It took a bit, but the changes in that tricky logic of switching scheduler for pCPUs needed thorough re-testing. :-/ In any case, the series is smaller, and a few patches are reviewed and

[Xen-devel] [PATCH v2 04/11] xen: sched: close potential races when switching scheduler to CPUs

In short, the point is making sure that the actual switch of scheduler and the remapping of the scheduler's runqueue lock occur in the same critical section, protected by the "old" scheduler's lock (and not, e.g., in the free_pdata hook, as it is now for Credit2 and RTDS). Not doing so, is (at

[Xen-devel] [PATCH v2 01/11] xen: sched: make implementing .alloc_pdata optional

The .alloc_pdata scheduler hook must, before this change, be implemented by all schedulers --even those ones that don't need to allocate anything. Make it possible to just use the SCHED_OP(), like for the other hooks, by using ERR_PTR() and IS_ERR() for error reporting. This: - makes NULL a

[Xen-devel] [PATCH v2 07/11] xen: sched: fix per-socket runqueue creation in credit2

The credit2 scheduler tries to setup runqueues in such a way that there is one of them per each socket. However, that does not work. The issue is described in bug #36 "credit2 only uses one runqueue instead of one runq per socket" (http://bugs.xenproject.org/xen/bug/36), and a solution has been

[Xen-devel] [PATCH v2 11/11] xen: sched: implement vcpu hard affinity in Credit2

From: Justin Weaver as it was still missing. Note that this patch "only" implements hard affinity, i.e., the possibility of specifying on what pCPUs a certain vCPU can run. Soft affinity (which express a preference for vCPUs to run on certain pCPUs) is still not supported

[Xen-devel] [PATCH v2 10/11] xen: sched: privde some scratch space for not putting cpumasks on stack

directly, from schedule.c, for any scheduler that needs it to use it. In fact, Credit1 and RTDS needs this already. Credit2 is also going to need it, for supporting hard affinity (which is, typically, what requires a lot of cpumask manipulations, inside various functions). Therefore, let's

[Xen-devel] [PATCH v2 05/11] xen: sched: improve credit2 bootparams' scope, placement and signedness

From: Uma Sharma and, while we are adjusting signedness of opt_load_window_shift, make also prv->load_window_shift unsigned, as approapriate. Signed-off-by: Uma Sharma Signed-off-by: Dario Faggioli Reviewed-by:

[Xen-devel] [PATCH v2 08/11] xen: sched: allow for choosing credit2 runqueues configuration at boot

In fact, credit2 uses CPU topology to decide how to arrange its internal runqueues. Before this change, only 'one runqueue per socket' was allowed. However, experiments have shown that, for instance, having one runqueue per physical core improves performance, especially in case hyperthreading is

[Xen-devel] [PATCH v2 09/11] xen: sched: per-core runqueues as default in credit2

Experiments have shown that arranging the scheduing runqueues on a per-core basis yields better results, in most cases. Such evaluation has been done, for the first time, by Uma Sharma, during her participation to OPW. Some of the results she got are summarized here:

[Xen-devel] [PATCH v2 06/11] xen: sched: on Credit2, don't reprogram the timer if idle

as other schedulers are doing already: if the idle vcpu is picked and scheduled, there is no need to reprogram the scheduler timer to fire and invoke csched2_schedule() again in future. Tickling or external events will serve as pokes, when necessary, but until we can, we should just stay idle.

Re: [Xen-devel] [PATCH v9 for Xen 4.7 3/4] libxl: enable per-VCPU parameter for RTDS

On 06/04/16 20:20, Chong Li wrote: > On Wed, Apr 6, 2016 at 1:54 PM, Andrew Cooper > wrote: >> On 06/04/16 17:41, Chong Li wrote: >>> On Wed, Apr 6, 2016 at 11:36 AM, Dario Faggioli >>> wrote: On Wed, 2016-04-06 at 16:38 +0100, Ian

[Xen-devel] [PATCH v1] libxc: fix uninitialized variable when changing rtds scheduling parameters

Commit 046c2b503a89d21b41e4d555a9f75d02af00dbc6 introduces a build failure: in some cases (e.g., num_vcpus <=0), xc_sched_rtds_vcpu_get/set returns an uninitialized variable. Fix it. Signed-off-by: Chong Li --- CC: CC:

Re: [Xen-devel] [PATCH v1] libxc: fix uninitialized variable when changing rtds scheduling parameters

On 06/04/16 21:30, Chong Li wrote: > Commit 046c2b503a89d21b41e4d555a9f75d02af00dbc6 introduces a build > failure: in some cases (e.g., num_vcpus <=0), > xc_sched_rtds_vcpu_get/set returns an uninitialized variable. > > Fix it. > > Signed-off-by: Chong Li > > --- > CC:

Re: [Xen-devel] [PATCH] libxl: libxl_domain_create_restore has an extra argument

On 4/5/16 9:20 AM, Wei Liu wrote: > In the latest libxenlight code, libxl_domain_create_restore accepts a > new argument. Update libvirt's libxl driver for that. Use the macro > provided by libxenlight to detect which version should be used. > > The new parameter (send_back_fd) is set to -1

Re: [Xen-devel] [PATCH v1] libxc: fix uninitialized variable when changing rtds scheduling parameters

On Wed, 2016-04-06 at 21:35 +0100, Andrew Cooper wrote: > On 06/04/16 21:30, Chong Li wrote: > > > > Commit 046c2b503a89d21b41e4d555a9f75d02af00dbc6 introduces a build > > failure: in some cases (e.g., num_vcpus <=0), > > xc_sched_rtds_vcpu_get/set returns an uninitialized variable. > > > > Fix

Re: [Xen-devel] Regarding Outreachy project on Improving CR Dashboard

On Wed, 2016-04-06 at 17:30 +0530, Priya wrote: > Hello, > > Thanks for your suggestions. > I have made the appropriate changes as you had mentioned. > It took a little time to change from python3 to python3.4 as perceval > supports python3.4. I have updated the changes in my github. You can >

Re: [Xen-devel] [PATCH 0/3] COLO: only build on Linux

On Wed, Apr 06, 2016 at 09:24:26AM +0800, Wen Congyang wrote: > On 04/06/2016 04:05 AM, Wei Liu wrote: > > COLO depends on netlink which is only available on Linux. This series > > cleans up > > COLO code and make it only build on Linux. This should fix FreeBSD build. > > > > Congyang and

[Xen-devel] Shortlist of people for Committer and Security Team member election

Dear Community members, you may remember the following e-mail called "Call for nominations for new Hypervisor subproject maintainers and committers" (also see http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03459.html) We had quite a few nominations for maintainers, committers

Re: [Xen-devel] [PATCH] libxl: replace the usage of uuid_t with a char array

On Wed, 6 Apr 2016, Roger Pau Monne wrote: > diff --git a/tools/libxl/libxl_uuid.h b/tools/libxl/libxl_uuid.h > index c5041c7..c4ffc23 100644 > --- a/tools/libxl/libxl_uuid.h > +++ b/tools/libxl/libxl_uuid.h > @@ -20,19 +20,19 @@ > #define LIBXL__UUID_BYTES(uuid) uuid[0], uuid[1], uuid[2],

Re: [Xen-devel] Stub domain crash on Xen v4.6.1

On Tue, Apr 05, 2016 at 05:17:00PM +0200, Fanny Dwargee wrote: > Hi, > > after adding the 'device_model_stubdomain_override = 1' to an otherwise > fine configuration the domain crashes on start. > > Xen is v4.6.1 compiled from source on Debian Jessie 64bits this way: > >- ./configure

[Xen-devel] [PATCH v2] libxl: replace the usage of uuid_t with a char array

The internals of the uuid_t struct don't match a big endian octet stream on *BSD systems, which means that it cannot be directly casted to a uint8_t[16]. In order to solve that change the type to be an unsigned char[16], which doesn't imply any other change on Linux. On *BSDs change the helpers

Re: [Xen-devel] [PATCH] libxl: libxl_domain_create_restore has an extra argument

On Tue, Apr 05, 2016 at 04:12:57PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH] libxl: libxl_domain_create_restore has an extra > argument"): > > CC Jim as well > > > > On Tue, Apr 05, 2016 at 03:20:12PM +0100, Wei Liu wrote: > > > In the latest libxenlight code,

Re: [Xen-devel] [PATCH v2 3/4] build: rename CONFIG_REMUS_NETBUF to CONFIG_LIBNL

On Wed, Apr 06, 2016 at 12:29:34PM +0100, Andrew Cooper wrote: > On 06/04/16 12:01, Wei Liu wrote: > > diff --git a/tools/configure.ac b/tools/configure.ac > > index 5b5dda4..79ff25e 100644 > > --- a/tools/configure.ac > > +++ b/tools/configure.ac > > @@ -410,12 +410,12 @@

Re: [Xen-devel] [PATCH v2 3/4] build: rename CONFIG_REMUS_NETBUF to CONFIG_LIBNL

On 06/04/16 12:01, Wei Liu wrote: > diff --git a/tools/configure.ac b/tools/configure.ac > index 5b5dda4..79ff25e 100644 > --- a/tools/configure.ac > +++ b/tools/configure.ac > @@ -410,12 +410,12 @@ PKG_CHECK_MODULES(LIBNL3, [libnl-3.0 >= 3.2.8 > libnl-route-3.0 >= 3.2.8], >

Re: [Xen-devel] [PATCH 0/3] COLO: only build on Linux

I've test on my side, and works ok for me. Thanks -Xie On 04/06/2016 04:05 AM, Wei Liu wrote: COLO depends on netlink which is only available on Linux. This series cleans up COLO code and make it only build on Linux. This should fix FreeBSD build. Congyang and Changlong, please review

Re: [Xen-devel] [PATCH 0/3] COLO: only build on Linux

On Wed, Apr 06, 2016 at 06:20:52PM +0800, Wen Congyang wrote: > On 04/06/2016 06:17 PM, Wei Liu wrote: > > On Wed, Apr 06, 2016 at 09:24:26AM +0800, Wen Congyang wrote: > >> On 04/06/2016 04:05 AM, Wei Liu wrote: > >>> COLO depends on netlink which is only available on Linux. This series > >>>

Re: [Xen-devel] ARMv8: New board bring up hangs in kernel start?

On 04/04/2016 16:44, Dirk Behme wrote: Hi Julien, Hello Dirk, On 01.04.2016 18:34, Julien Grall wrote: On 31/03/16 18:41, Dirk Behme wrote: Also have you tried a newer version of Xen? I've switched to the recent master a6f2cdb63 x86/hvm/viridian: keep APIC assist page mapped now.

[Xen-devel] [PATCH v2 2/4] libxl: colo: move netlink related stuff to libxl_colo_proxy.c

They are only used there, no need to expose them to other parts of libxl. This is necessary to make libxl build on FreeBSD again because FreeBSD doesn't have netlink. Signed-off-by: Wei Liu --- tools/libxl/libxl_colo.h | 12

[Xen-devel] [PATCH v2 1/4] libxl: colo: rearrange things in header files

We need to separate COLO code from common code as clean as possible. With this patch, all COLO structures are now in libxl_colo.h. It does the following: 1. Move two typedefs for libxl__domain_create_state{,cb} back to libxl_internal.h. 2. Move libxl__colo_save_state to libxl_colo.h. 3.

[Xen-devel] [PATCH v2 4/4] libxl: colo: make it depend on availability of libnl

Netlink is required when initialising COLO, so make sure only to compile COLO when netlink is available. Change the inclusion of linux/netlink.h to netlink/netlink.h. Provide necessary stub functions in case COLO is disabled. This should fix build on FreeBSD because there is no netlink there. It

Re: [Xen-devel] [PATCH v10 00/17] Add ACPI support for Xen Dom0 on ARM64

Hi Shannon, On 01/04/2016 16:48, Shannon Zhao wrote: This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI information. Introduce a bus notifier of

Re: [Xen-devel] [PATCH 3/3] libxl: colo: only build COLO on Linux

On Tue, Apr 05, 2016 at 09:06:02PM +0100, Wei Liu wrote: > Linux's netlink is required when initialising COLO, so make sure only to > compile COLO on Linux. > > Provide necessary stub functions in case COLO is disabled. This should > fix libxl build on FreeBSD. > > Signed-off-by: Wei Liu

Re: [Xen-devel] [PATCH 09/10] libxl: Fix libxl_set_memory_target return value

On 4 April 2016 at 12:40, George Dunlap wrote: > > On 01/04/16 15:55, Roger Pau Monné wrote: > > On Fri, 1 Apr 2016, Paulina Szubarczyk wrote: > >> libxl_set_memory_target seems to have the following return values: > >> > >> * 1 on failure, if the failure happens because

Re: [Xen-devel] [PATCH v2 0/4] COLO: only build when libnl is available

On Wed, Apr 06, 2016 at 12:01:12PM +0100, Wei Liu wrote: > COLO depends on netlink which is only available on Linux. This series cleans > up > COLO code and make it only build when libnl is available. This should fix > FreeBSD build. > > Tested building on Linux with and without libnl-3-dev and

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 6, 2016 at 3:40 AM, Luis R. Rodriguez wrote: > A huge summary of the discussion over EFI boot option for HVMLite is now on a > wiki [2], below I'll just provide the outline of the discussion. Consider > this a > request for more public review, feel free to take any

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 06/04/16 03:40, Luis R. Rodriguez wrote: > > * You don't need full EFI emulation I think needing any EFI emulation inside Xen (which is where it would need to be for dom0) is not suitable because of the increase in hypervisor ABI. I also still do not understand your objection to the

Re: [Xen-devel] [PATCH 0/3] COLO: only build on Linux

On 04/06/2016 06:17 PM, Wei Liu wrote: > On Wed, Apr 06, 2016 at 09:24:26AM +0800, Wen Congyang wrote: >> On 04/06/2016 04:05 AM, Wei Liu wrote: >>> COLO depends on netlink which is only available on Linux. This series >>> cleans up >>> COLO code and make it only build on Linux. This should fix

[Xen-devel] [PATCH v2 0/4] COLO: only build when libnl is available

COLO depends on netlink which is only available on Linux. This series cleans up COLO code and make it only build when libnl is available. This should fix FreeBSD build. Tested building on Linux with and without libnl-3-dev and libnl3-route-dev. git rebase -i HEAD~4 --exec \ './configure

[Xen-devel] [PATCH v2 3/4] build: rename CONFIG_REMUS_NETBUF to CONFIG_LIBNL

COLO and Remus net buffer support both depend on the availability of libnl. Use a generic name. No functional changes. Signed-off-by: Wei Liu --- I committed configure changes as well. Feel free to rerun autogen.sh. --- config/Tools.mk.in | 2 +- tools/configure

Re: [Xen-devel] [PATCH v2] libxl: replace the usage of uuid_t with a char array

On Wed, Apr 06, 2016 at 01:11:05PM +0200, Roger Pau Monne wrote: > The internals of the uuid_t struct don't match a big endian octet stream on > *BSD systems, which means that it cannot be directly casted to a > uint8_t[16]. > > In order to solve that change the type to be an unsigned char[16],

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote: > Boris sent out the first HVMLite series of patches to add a new Xen guest type > February 1, 2016 [0]. We've been talking off list with a few folks now over > the prospect of instead of adding yet-another-boot-entry we instead

[Xen-devel] [PATCH 1/1] libxl: Fix uninitialized pointer when passing an empty cdrom

Commit 3fec17d4bb56567d139d7806392f4d8702d3f6a7 introduced a bug where an empty cdrom would cause target_path to be uninitialized. Initialize target_path to NULL instead. The other option here would have been to set target_path to NULL only on the LIBXL_DISK_FORMAT_EMPTY path. That would

Re: [Xen-devel] [PATCH v10 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place

Hi Shannon, On 01/04/2016 16:49, Shannon Zhao wrote: Move xlated_setup_gnttab_pages to common place, so it can be reused by ARM to setup grant table. Rename it to xen_xlate_map_ballooned_pages. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini

Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions

On Tue, 5 Apr 2016, Juergen Gross wrote: > On 04/04/16 18:48, Boris Ostrovsky wrote: > > On 04/04/2016 12:30 PM, David Vrabel wrote: > >> On 04/04/16 17:21, Julien Grall wrote: > >>> (CC Stefano new e-mail address) > >>> > >>> Hello Anna-Maria, > >>> > >>> On 04/04/2016 13:32, Anna-Maria Gleixner

[Xen-devel] [PATCH v4 13/14] x86/init: rename ebda code file

This makes it clearer what this is. Signed-off-by: Luis R. Rodriguez --- arch/x86/Makefile | 2 +- arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/{head.c => ebda.c} | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename

[Xen-devel] [PATCH v4 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code

This moves the ACPI specific check into the ACPI boot code, it also takes advantage of the x86_platform.legacy.rtc which is checked for already on the RTC initialization code. This lets us remove the nasty #ifdefery and consolidate the checks to use only one toggle to disable the RTC init code.

[Xen-devel] [PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch

Although hardware_subarch has been in place since the x86 boot protocol 2.07 it hasn't been used much. Enumerate current possible values to avoid misuses and help with semantics later at boot time should this be used further. These enums should only ever be used by architecture x86 code, and all

[Xen-devel] [PATCH v4 12/14] x86, ACPI: parse ACPI_FADT_LEGACY_DEVICES

ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES can be used to determine if a system has legacy devices LPC or ISA devices. The x86 platform already has a struct which lists known associated legacy devices, we start off careful only by disabling root devices we should not

[Xen-devel] [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific legacy quirk set early in boot through

[Xen-devel] [PATCH v4 03/14] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly

Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644

[Xen-devel] [PATCH v4 07/14] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, the area tossed to the kernel on lguest is not zerored out, so ensure lguest force disables tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez ---

[Xen-devel] [PATCH v4 09/14] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled(). Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the boot_params.tboot_addr. The Xen folks are sure a force disable to 0 is not needed, we recently forced disabled this on

Re: [Xen-devel] [PATCH v5 09/28] xsplice: Add helper elf routines

>>> Konrad Rzeszutek Wilk 04/06/16 3:40 AM >>> >> > +struct xsplice_elf_sym { >> > +Elf_Sym *sym; >> >> const? > >.. this is much harder. I end up computing the values for >these symbols and have to write to this this structure a couple of times >(at worst). So I've

Re: [Xen-devel] [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.

>>> Konrad Rzeszutek Wilk 04/06/16 10:05 PM >>> >> > --- a/xen/include/xen/version.h >> > +++ b/xen/include/xen/version.h >> > @@ -17,4 +17,7 @@ const char *xen_deny(void); >> > #include >> > int xen_build_id(const void **p, unsigned int *len); >> > >> > +#include >> >

Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions

On Wed, 6 Apr 2016, David Vrabel wrote: > On 04/04/16 13:32, Anna-Maria Gleixner wrote: > > Xen guests do not offline/online CPUs during suspend/resume and > > therefore FROZEN notifier transitions are not required. Add this > > explanation as a comment in the code to get not confused why > >

Re: [Xen-devel] [PATCH V7 3/3] x86/xsaves: ebx may return wrong value using CPUID eax=0xdh, ecx =1

>>> Shuai Ruan 04/06/16 8:59 AM >>> >Another question is whether we should add this in pv_cpuid() or not. >(which we have discussed in the previous thread). > >Refer to SDM Volume 1 >"13.2 ENUMERATION OF CPU SUPPORT FOR XSAVE INSTRUCTIONS AND XSAVE- >SUPPORTED

Re: [Xen-devel] [PATCH v4 26/26] tools/libxc: Calculate xstate cpuid leaf from guest information

>>> Andrew Cooper 04/07/16 2:40 AM >>> >On 07/04/2016 01:16, Jan Beulich wrote: > Andrew Cooper 04/05/16 7:49 PM >>> >>> There is no possible way of avoiding having a whitelist somewhere, which >>> limits what Xen will tolerate supporting

Re: [Xen-devel] [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces

>>> Konrad Rzeszutek Wilk 04/06/16 4:39 AM >>> >On Fri, Apr 01, 2016 at 09:23:15AM -0600, Jan Beulich wrote: >> >>> On 24.03.16 at 21:00, wrote: >> > @@ -331,16 +332,17 @@ static char *pointer(char *str, char *end, const >> > char **fmt_ptr, >> >

Re: [Xen-devel] [PATCH v5 17/28] xsplice: Add support for exception tables.

>>> Konrad Rzeszutek Wilk 04/06/16 4:42 PM >>> >On Fri, Apr 01, 2016 at 10:06:54AM -0600, Jan Beulich wrote: >> >>> On 24.03.16 at 21:00, wrote: >> > --- a/xen/common/xsplice.c >> > +++ b/xen/common/xsplice.c >> > @@ -573,6 +573,25 @@ static int

Re: [Xen-devel] [PATCH v10 06/17] Xen: ARM: Add support for mapping platform device mmio

On 2016/4/6 20:16, Julien Grall wrote: >> +gpfns[j] = XEN_PFN_DOWN(r->start) + j; >> +idxs[j] = XEN_PFN_DOWN(r->start) + j; >> +} >> + >> +xatp.domid = DOMID_SELF; >> +xatp.size = nr; >> +xatp.space = XENMAPSPACE_dev_mmio; >> + >> +

[Xen-devel] [PATCH v4 08/14] apm32: remove paravirt_enabled() use

There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the apm_bios.info. The Xen folks are sure force disable to 0 is not needed, we recently

[Xen-devel] [PATCH v4 06/14] x86/init: use a platform legacy quirk for ebda

This replaces the paravirt_enabled() check with a proper x86 legacy platform quirk. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/x86_init.h | 3 +++ arch/x86/kernel/head.c| 2 +- arch/x86/kernel/platform-quirks.c | 4 3 files changed, 8

[Xen-devel] [PATCH v4 11/14] pnpbios: replace paravirt_enabled() check with legacy device check

Since we are removing paravirt_enabled() replace it with a logical equivalent. Even though PNPBIOS is x86 specific we add an arch-specific type call, which can be implemented by any architecture to show how other legacy attribute devices can later be also checked for with other ACPI legacy

[Xen-devel] [PATCH v4 10/14] x86/cpu/intel: remove not needed paravirt_enabled() for f00f work around

The X86_BUG_F00F work around is responsible for fixing up the error generated on attempted F00F exploitation from an OOPS to a SIGILL. There is no reason why this code should not be allowed to run on PV guest on a F00F-affected CPU -- it would simply never trigger. The pv_enabled() check was there

[Xen-devel] [PATCH v4 00/14] x86: remove paravirt_enabled

Now that Andy's ASM paravirt_enabled() use is merged all we need is to address the rest of the C code uses. This completes that work by providing proper semantics for platform legacy settings and quirks as suggested by Ingo, this in turn can also be extended later for benefit of further processing

[Xen-devel] [PATCH v4 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/enlighten.c

Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading

Konrad Rzeszutek Wilk 04/05/16 7:49 PM >>> >On Tue, Apr 05, 2016 at 12:45:44PM -0400, Konrad Rzeszutek Wilk wrote: >> > > +void *vm_alloc(unsigned int nr, unsigned int align) >> > > +{ >> > > +return vm_alloc_type(nr, align, VMAP_VIRT); >> > > +} >> > >> >

Re: [Xen-devel] [PATCH v10 00/17] Add ACPI support for Xen Dom0 on ARM64

Hi Julien, On 2016/4/6 19:32, Julien Grall wrote: > Hi Shannon, > > On 01/04/2016 16:48, Shannon Zhao wrote: >> This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen >> ACPI on ARM64 design document could be found from [1]. >> >> This patch set adds a new FDT node "uefi" under

Re: [Xen-devel] Bug in x86 instruction emulator?

>>> 04/07/16 3:28 AM >>> >On 2016-04-06 10:55, Andrew Cooper wrote: >> Can you grab the full register state at the point of Xorgs crash? >> `info >> regs` in gdb? >> >> The instruction in use, `movaps` is specified to fault if the memory >> operand isn't aligned on a

Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading

>>> Konrad Rzeszutek Wilk 04/05/16 6:46 PM >>> >> > +if ( mfn_array ) >> > +*mfn_array = mfn; >> > +else >> > +xfree(mfn); >> >> What's this? I certainly assumed this wouldn't be needed anymore >> now. > >I still need the MFNs so I can change the

Re: [Xen-devel] [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case

>>> Martin Pohlack 04/06/16 8:42 AM >>> >On 06.04.2016 04:42, Konrad Rzeszutek Wilk wrote: >> The normal use-case is to modify structures values where we have to >> be delicate about it and can't just replace the value. As in we >> may have to recompute the value. > >Agree on

Re: [Xen-devel] [PATCH v4 26/26] tools/libxc: Calculate xstate cpuid leaf from guest information

>>> Andrew Cooper 04/05/16 7:49 PM >>> >On 31/03/16 08:48, Jan Beulich wrote: > On 23.03.16 at 17:36, wrote: >>> switch ( input[1] ) >>> { >>> -case 0: >>> +case 0: >>> /* EAX: low 32bits of

Re: [Xen-devel] [PATCH v4 26/26] tools/libxc: Calculate xstate cpuid leaf from guest information

On 07/04/2016 01:16, Jan Beulich wrote: Andrew Cooper 04/05/16 7:49 PM >>> >> On 31/03/16 08:48, Jan Beulich wrote: >> On 23.03.16 at 17:36, wrote: switch ( input[1] ) { -case 0: +case 0:

Re: [Xen-devel] Bug in x86 instruction emulator?

On 2016-04-06 10:55, Andrew Cooper wrote: On 06/04/16 00:57, Mihai Donțu wrote: On Wed, 06 Apr 2016 01:38:32 +0200 wo...@openmailbox.org wrote: I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU with vga="qxl", Xorg will segfault instantly if tried started. Multiple Linux

[Xen-devel] [xen-unstable-smoke test] 89250: tolerable FAIL - PUSHED

flight 89250 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/89250/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-buildfail like 88802 Tests which did not

Re: [Xen-devel] [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.

>>> Konrad Rzeszutek Wilk 04/06/16 4:05 AM >>> >On Fri, Apr 01, 2016 at 07:33:54AM -0600, Jan Beulich wrote: >> >>> On 24.03.16 at 21:00, wrote: >> > --- a/xen/arch/x86/Makefile >> > +++ b/xen/arch/x86/Makefile >> > @@ -75,7 +75,12 @@ efi-y := $(shell

Re: [Xen-devel] [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case

>>> Konrad Rzeszutek Wilk 04/06/16 4:44 AM >>> >On Fri, Apr 01, 2016 at 09:50:31AM -0600, Jan Beulich wrote: >> >>> On 24.03.16 at 21:00, wrote: >> > From: Ross Lagerwall >> > >> > Add hook functions which run during patch

Re: [Xen-devel] [PATCH v9 1/3] VT-d: add a command line parameter for Queued Invalidation

> From: Xu, Quan > Sent: Thursday, April 07, 2016 9:49 AM > > > > > > > +In current code, VT-d Queued Invalidation includes Device-TLB, IOTLB, > > > +Context and IEC flush. If Device-TLB flush timed out, we would hide > > > +the target ATS device and crash the domain owning this ATS device. > >

Re: [Xen-devel] [PATCH v9 1/3] VT-d: add a command line parameter for Queued Invalidation

On April 05, 2016 5:09pm, wrote: > >>> On 01.04.16 at 16:47, wrote: > > The subject should mention "timeout", perhaps either in addition to or in > place > of "command line". > I prefer "VT-d: add a timeout parameter for Queued Invalidation". > > ---

[Xen-devel] [PATCH V8 1/2] x86/xsaves: fix two miscellaneous issues

From: Shuai Ruan 1. get_xsave_addr() will only be called when xsave_area_compressed(xsave) is true. So drop the conditional expression. 2. expand_xsave_states() will memset the area when get NULL from get_xsave_addr(). Reported-by: Jan Beulich

[Xen-devel] [PATCH V8 2/2] x86/xsaves: ebx may return wrong value using CPUID eax=0xd, ecx =1

From: Shuai Ruan Refer to SDM Volume 1 Extended Region of an XSAVE Area. The value returned by ecx[1] with cpuid function 0xd and sub-function i (i>1) indicates the alignment of the state component i when the compacted format of the extended region of an xsave area is used.

[Xen-devel] [PATCH V8 0/2] xsaves bug fix

From: Shuai Ruan This patchset fix xsaves related bugs. Shuai Ruan (2): x86/xsaves: fix two miscellaneous issues x86/xsaves: ebx may return wrong value using CPUID eax=0xd,ecx =1 xen/arch/x86/hvm/hvm.c | 12 xen/arch/x86/xstate.c| 13

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote: > >>> On 24.03.16 at 21:00, wrote: > > The version of ld that first implemented --build-id is v2.18. > > Hence we check for that or later version - if older version > > found we do not build the hypervisor with

[Xen-devel] [PATCH v6 11/24] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.

This change demonstrates how to generate an xSplice ELF payload. The idea here is that we want to patch in the hypervisor the 'xen_version_extra' function with an function that will return 'Hello World'. The 'xl info | grep extraversion' will reflect the new value after the patching. To generate

[Xen-devel] [PATCH v6 22/24] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE

With this third payload one can do: -bash-4.1# xen-xsplice load xen_hello_world.xsplice Uploading xen_hello_world.xsplice (10148 bytes) Performing check: completed Performing apply:. completed [xen_hello_world depends on hypervisor build-id] -bash-4.1# xen-xsplice load xen_bye_world.xsplice

[Xen-devel] [PATCH v6 14/24] xsplice: Add support for bug frames.

From: Ross Lagerwall Add support for handling bug frames contained with xsplice modules. If a trap occurs search either the kernel bug table or an applied payload's bug table depending on the instruction pointer. Signed-off-by: Ross Lagerwall

  1   2   3   >