[Xen-devel] [xen-unstable baseline-only test] 68385: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68385 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68385/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf 3 host-install(3)

[Xen-devel] [qemu-mainline test] 104227: regressions - trouble: broken/fail/pass

flight 104227 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104227/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 3 host-install(3)broken REGR. vs. 104208

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, January 16, 2017 7:00 PM > > >>> On 16.01.17 at 06:25, wrote: > > One thing noted though. The original patch from Quan is actually orthogonal > > to this ASSERT. Regardless of whether intack.vector is larger or

[Xen-devel] Problems with pci/vga passthrough

Hi! I reported/discussed this earlier on IRC, but was asked to report it here too. The goal I tried to accomplish was getting vga passthrough working to get hardware acceleration and OpenGL 2+ working for a vm containing KDE Plasma 5 (Debian Stretch). The graphics card I tried it with was an

Re: [Xen-devel] [PATCH V5] x86/HVM: Introduce struct hvm_pi_ops

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, January 17, 2017 5:30 PM > To: Suravee Suthikulpanit > Cc: sherry.hurw...@amd.com; andrew.coop...@citrix.com; Nakajima, Jun; Tian, > Kevin; > xen-devel@lists.xen.org; Boris Ostrovsky;

Re: [Xen-devel] PV audio drivers for Linux

>-Original Message- >From: Stefano Stabellini [mailto:sstabell...@kernel.org] >Sent: Wednesday, January 18, 2017 5:41 AM >To: Ughreja, Rakesh A >Cc: xen-devel@lists.xen.org; oleksandr_andrushche...@epam.com; >oleksandr_gryt...@epam.com;

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

flight 104223 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104223/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104202

[Xen-devel] [PATCH v5 23/24] tools: L2 CAT: support set cbm for L2 CAT.

This patch implements the xl/xc changes to support set CBM for L2 CAT. The new level option is introduced to original CAT setting command in order to set CBM for specified level CAT. - 'xl psr-cat-cbm-set' is updated to set cache capacity bitmasks(CBM) for a domain according to input cache

[Xen-devel] [PATCH v5 21/24] tools: L2 CAT: support get HW info for L2 CAT.

This patch implements xl/xc changes to support get HW info for L2 CAT. 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT info. Example(on machine which only supports L2 CAT): Cache Monitoring Technology (CMT): Enabled : 0 Cache Allocation Technology (CAT): L3 libxl: error:

[Xen-devel] [PATCH v5 24/24] docs: add L2 CAT description in docs.

This patch adds L2 CAT description in related documents. Signed-off-by: He Chen Signed-off-by: Yi Sun --- docs/man/xl.pod.1.in | 25 ++--- docs/misc/xl-psr.markdown | 10 -- 2 files changed, 30 insertions(+), 5

[Xen-devel] [PATCH v5 18/24] x86: L2 CAT: implement get hw info flow.

This patch implements get HW info flow for L2 CAT including L2 CAT callback function. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c | 16 xen/arch/x86/sysctl.c | 15 +++ xen/include/asm-x86/psr.h | 1 +

[Xen-devel] [PATCH v5 22/24] tools: L2 CAT: support show cbm for L2 CAT.

This patch implements changes in xl/xc changes to support showing CBM of L2 CAT. The new level option is introduced to original CAT showing command in order to show CBM for specified level CAT. - 'xl psr-cat-show' is updated to show CBM of a domain according to input cache level. Examples:

[Xen-devel] [PATCH v5 20/24] x86: L2 CAT: implement set value flow.

This patch implements L2 CAT set value related callback functions and domctl interface. Signed-off-by: Yi Sun --- xen/arch/x86/domctl.c | 6 +++ xen/arch/x86/psr.c | 92 + xen/include/asm-x86/msr-index.h |

[Xen-devel] [PATCH v5 15/24] x86: refactor psr: implement get value flow for CDP.

This patch implements L3 CDP get value callback function. With this patch, 'psr-cat-show' can work for L3 CDP. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c | 16 1 file changed, 16 insertions(+) diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c

[Xen-devel] [PATCH v5 19/24] x86: L2 CAT: implement get value flow.

This patch implements L2 CAT get value callback function and interface in domctl. Signed-off-by: Yi Sun --- xen/arch/x86/domctl.c | 7 +++ xen/arch/x86/psr.c | 12 xen/include/public/domctl.h | 1 + 3 files changed, 20 insertions(+)

[Xen-devel] [PATCH v5 11/24] x86: refactor psr: set value: implement cos id picking flow.

Continue with previous patch: 'x86: refactor psr: set value: implement cos finding flow.' If fail to find a COS ID, we need pick a new COS ID for domain. Only COS ID that ref[COS_ID] is 1 or 0 can be picked to input a new set feature values. Signed-off-by: Yi Sun ---

[Xen-devel] [PATCH v5 10/24] x86: refactor psr: set value: implement cos finding flow.

Continue with patch: 'x86: refactor psr: set value: assemble features value array' We can try to find if there is a COS ID on which all features' COS registers values are same as the array assembled before. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c | 93

[Xen-devel] [PATCH v5 12/24] x86: refactor psr: set value: implement write msr flow.

Continue with previous patch: 'x86: refactor psr: set value: implement cos id picking flow.' We have got all features values and COS ID to set. Then, we write MSRs of all features except the setting value is same as original value. Till now, set value process is completed. Signed-off-by: Yi Sun

[Xen-devel] [PATCH v5 00/24] Enable L2 Cache Allocation Technology & Refactor psr.c

Hi all, We plan to bring a new PSR (Platform Shared Resource) feature called Intel L2 Cache Allocation Technology (L2 CAT) to Xen. Besides the L2 CAT implementaion, we refactor the psr.c to make it more flexible to add new features and fulfill the principle, open for extension but closed for

[Xen-devel] [PATCH v5 07/24] x86: refactor psr: implement get value flow.

This patch implements get value flow including L3 CAT callback function. It also changes domctl interface to make it more general. With this patch, 'psr-cat-show' can work for L3 CAT. Signed-off-by: Yi Sun --- xen/arch/x86/domctl.c | 18 +-

[Xen-devel] [PATCH v5 17/24] x86: L2 CAT: implement CPU init and free flow.

This patch implements the CPU init and free flow for L2 CAT including L2 CAT initialization callback function. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c| 72 +++ xen/include/asm-x86/psr.h | 1 + 2 files changed,

[Xen-devel] [PATCH v5 13/24] x86: refactor psr: implement CPU init and free flow for CDP.

This patch implements the CPU init and free flow for CDP including L3 CDP initialization callback function. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c | 98 +++--- 1 file changed, 93 insertions(+), 5 deletions(-) diff

[Xen-devel] [PATCH v5 05/24] x86: refactor psr: implement Domain init/free and schedule flows.

This patch implements the Domain init/free and schedule flows. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c | 62 +- 1 file changed, 61 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/psr.c

[Xen-devel] [PATCH v5 16/24] x86: refactor psr: implement set value callback functions for CDP.

This patch implements L3 CDP set value related callback functions. With this patch, 'psr-cat-cbm-set' command can work for L3 CDP. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c | 118 + 1 file changed, 118

[Xen-devel] [PATCH v5 14/24] x86: refactor psr: implement get hw info flow for CDP.

This patch implements get HW info flow for CDP including L3 CDP callback function. It also changes sysctl function to make it work for CDP. With this patch, 'psr-hwinfo' can work for L3 CDP. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c| 18 ++

[Xen-devel] [PATCH v5 04/24] x86: refactor psr: implement CPU init and free flow.

This patch implements the CPU init and free flow including L3 CAT initialization and feature list free. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c | 176 - 1 file changed, 174 insertions(+), 2 deletions(-) diff

[Xen-devel] [PATCH v5 03/24] x86: refactor psr: implement main data structures.

To construct an extendible framework, we need analyze PSR features and abstract the common things and feature specific things. Then, encapsulate them into different data structures. By analyzing PSR features, we can get below map. +--+--+--+ ->| Dom0 |

[Xen-devel] [PATCH v5 06/24] x86: refactor psr: implement get hw info flow.

This patch implements get HW info flow including L3 CAT callback function. It also changes sysctl interface to make it more general. With this patch, 'psr-hwinfo' can work for L3 CAT. Signed-off-by: Yi Sun --- xen/arch/x86/psr.c| 73

[Xen-devel] [PATCH v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

This patch creates L2 CAT feature document in doc/features/. It describes details of L2 CAT. Signed-off-by: Yi Sun --- docs/features/intel_psr_l2_cat.pandoc | 347 ++ 1 file changed, 347 insertions(+) create mode 100644

[Xen-devel] [PATCH v5 02/24] x86: refactor psr: remove L3 CAT/CDP codes.

The current cache allocation codes in psr.c do not consider future features addition and are not friendly to extend. To make psr.c be more flexible to add new features and fulfill the program principle, open for extension but closed for modification, we have to refactor the psr.c: 1. Analyze

[Xen-devel] [PATCH v5 09/24] x86: refactor psr: set value: assemble features value array.

Only can one COS ID be used by one domain at one time. That means all enabled features' COS registers at this COS ID are valid for this domain at that time. When user updates a feature's value, we need make sure all other features' values are not affected. So, we firstly need assemble an array

[Xen-devel] [PATCH v5 08/24] x86: refactor psr: set value: implement framework.

As set value flow is the most complicated one in psr, it will be divided to some patches to make things clearer. This patch implements the set value framework to show a whole picture firstly. It also changes domctl interface to make it more general. To make the set value flow be general and can

[Xen-devel] [xen-unstable-smoke test] 104232: tolerable all pass - PUSHED

flight 104232 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104232/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] [PATCH] xen: credit2: improve debug dump output.

Scheduling information debug dump for Credit2 is hard to read as it contains the same information repeated multiple time in different ways. In fact, in Credit2, CPUs are grouped in runqueus. Before this change, for each CPU, we were printing the while content of the runqueue, as shown below:

[Xen-devel] [PATCH] xen: credit2: clear bit instead of skip step in runq_tickle()

Since we are doing cpumask manipulation already, clear a bit in the mask at once. Doing that will save us an if, later in the code. No functional change intended. Signed-off-by: Dario Faggioli --- Cc: George Dunlap ---

Re: [Xen-devel] PV audio drivers for Linux

On Tue, 17 Jan 2017, Ughreja, Rakesh A wrote: > Hi, > > I am trying to develop PV audio drivers and facing one issue to > achieve zero copy of the buffers between Front End (DOM1) and > Back End (DOM0) drivers. You might want to take a look at the existing PV sound proposal:

Re: [Xen-devel] [PATCH] xen/arm: Don't mix GFN and MFN when using iomem_deny_access

On Tue, 17 Jan 2017, Julien Grall wrote: > iomem_deny_access is working on MFN and not GFN. Make it clear by > renaming the local variables. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > xen/arch/arm/domain_build.c | 6

Re: [Xen-devel] [PATCH] xen/arm: bootfdt.c is only used during initialization

On Tue, 17 Jan 2017, Julien Grall wrote: > This file contains data and code only used at initialization. Mark the > file as such in the build system and correct kind_guess. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini >

Re: [Xen-devel] Reading network data going into a VM from netback.c

On Tue, 2017-01-17 at 06:02 +, #PATHANGI JANARDHANAN JATINSHRAVAN# wrote: > But I am not able to parse the hexadecimal string as shown above.  > > Can anyone point me in the right direction regarding this? > I'm afraid I can't. At the same time, I'm quite sure that by sending the same exact

Re: [Xen-devel] [PATCH v2 1/3] xen: clean up xenbus internal headers

On 01/16/2017 09:15 AM, Juergen Gross wrote: > The xenbus driver has an awful mixture of internally and globally > visible headers: some of the internally used only stuff is defined in > the global header include/xen/xenbus.h while some stuff defined in > internal headers is used by other drivers,

Re: [Xen-devel] [PATCH] x86: Use ACPI reboot method for Dell OptiPlex 9020

>>> On 14.12.16 at 14:15, wrote: > On 14/12/16 12:58, Jan Beulich wrote: > On 14.12.16 at 12:12, wrote: >>> When EFI booting the Dell OptiPlex 9020, it sometimes GP faults in the >>> EFI runtime instead of rebooting. >> Has it been

[Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems

Hi all, I would like to discuss with ARM64 and ACPI Linux maintainers the best way to complete ACPI support in Linux for Dom0 on ARM64. As a reminder, Xen can only parse static ACPI tables. It doesn't have a bytecode interpreter. Xen maps all ACPI tables to Dom0, which parses them as it does on

Re: [Xen-devel] [PATCH v3] kexec: implement STATUS hypercall to check if image is loaded

On Tue, Jan 17, 2017 at 11:29:16AM -0600, Eric DeVolder wrote: > The tools that use kexec are asynchronous in nature and do not keep > state changes. As such provide an hypercall to find out whether an > image has been loaded for either type. > > Note: No need to modify XSM as it has one size fits

[Xen-devel] [seabios test] 104213: tolerable FAIL - PUSHED

flight 104213 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/104213/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104000

[Xen-devel] [PATCH v2 0/2] xen-netback: fix memory leaks on XenBus disconnect

Just split the initial patch in two as proposed by Wei. Since the approach for locking netdev statistics is inconsistent (tends not to have any locking at all) accross the kernel we'd better to rely on our internal lock for this purpose. Igor Druzhinin (2): xen-netback: fix memory leaks on

[Xen-devel] [PATCH v2 1/2] xen-netback: fix memory leaks on XenBus disconnect

Eliminate memory leaks introduced several years ago by cleaning the queue resources which are allocated on XenBus connection event. Namely, queue structure array and pages used for IO rings. Signed-off-by: Igor Druzhinin --- drivers/net/xen-netback/xenbus.c | 11

[Xen-devel] [PATCH v2 2/2] xen-netback: protect resource cleaning on XenBus disconnect

vif->lock is used to protect statistics gathering agents from using the queue structure during cleaning. Signed-off-by: Igor Druzhinin --- drivers/net/xen-netback/interface.c | 6 -- drivers/net/xen-netback/xenbus.c| 2 ++ 2 files changed, 6 insertions(+), 2

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

> > Is this patch of yours that neccessary? Could at least some of the > > functions still exist? > > Well. This patch is manually doing what LTO would do automatically when > it has a cross-translation-unit view of things, and come to the > conclusion that in all cases, inlining cross-unit will

Re: [Xen-devel] [PATCH v3] kexec: implement STATUS hypercall to check if image is loaded

On 17/01/17 17:29, Eric DeVolder wrote: > The tools that use kexec are asynchronous in nature and do not keep > state changes. As such provide an hypercall to find out whether an > image has been loaded for either type. > > Note: No need to modify XSM as it has one size fits all check and > does

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

On 17/01/17 19:00, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 17, 2017 at 01:42:54PM -0500, Konrad Rzeszutek Wilk wrote: >> On Tue, Jan 17, 2017 at 06:16:36PM +, Andrew Cooper wrote: >>> On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote: On Mon, Jan 16, 2017 at 01:04:09PM +, Andrew

[Xen-devel] [PATCH v3 5/5] fix: add multiboot2 protocol support for EFI platforms

This should be squashed into the 4/4 patch 'x86: add multiboot2 protocol support for EFI platforms'. - fix incorrect assembly (identified by Andrew Cooper) - fix issue where the trampoline size was left as 0 and the way the memory is allocated for the trampolines we would go to the end of an

[Xen-devel] [PATCH v3 3/5] efi: create new early memory allocator

From: Daniel Kiper There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB

[Xen-devel] [PATCH v3 1/5] x86: add multiboot2 protocol support

From: Daniel Kiper Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v3 4/5] x86: add multiboot2 protocol support for EFI platforms

From: Daniel Kiper This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper Reviewed-by: Doug Goldstein Tested-by: Doug Goldstein

[Xen-devel] [PATCH v3 0/5] multiboot2 protocol support

This is a series based on v11 of Daniel Kiper's "x86: multiboot2 protocol support" series. It aims to collect up all the fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in code review and testing on actual hardware. I've had problems with the relocation portion of the

[Xen-devel] [PATCH v3 2/5] efi: build xen.gz with EFI code

From: Daniel Kiper Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement

[Xen-devel] [qemu-mainline test] 104208: tolerable FAIL - PUSHED

flight 104208 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104208/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 15 guest-start/debian.repeatfail like 104176

Re: [Xen-devel] STAO spec in xen.git

On Tue, 17 Jan 2017, Olaf Hering wrote: > On Fri, Jan 13, Julien Grall wrote: > > > Regarding the format. Does ODT will allow git to do proper diff? > > There is flat ODT, "Safe as ..." and pick the better format from the pulldown > menu. Sounds like a good idea. Can you submit a patch?

[Xen-devel] [ovmf baseline-only test] 68383: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68383 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68383/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i3863 host-install(3) broken

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Tue, 17 Jan 2017, Julien Grall wrote: > Hi, > > Sorry for the late answer, I am just back from holidays and still catching-up > with my e-mails. > > On 03/01/17 20:08, Stefano Stabellini wrote: > > On Thu, 29 Dec 2016, Bhupinder Thakur wrote: > > > On 28 December 2016 at 23:19, Julien Grall

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

On Tue, Jan 17, 2017 at 01:42:54PM -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 17, 2017 at 06:16:36PM +, Andrew Cooper wrote: > > On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote: > > > On Mon, Jan 16, 2017 at 01:04:09PM +, Andrew Cooper wrote: > > >> The chageset/version/compile

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

flight 104202 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104202/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104181

Re: [Xen-devel] PVH CPU hotplug design document

On 01/17/2017 12:45 PM, Roger Pau Monné wrote: > On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote: >> On 01/17/2017 10:33 AM, Jan Beulich wrote: >> On 17.01.17 at 16:27, wrote: On 01/17/2017 09:44 AM, Jan Beulich wrote: On 17.01.17 at

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

On Tue, Jan 17, 2017 at 06:16:36PM +, Andrew Cooper wrote: > On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote: > > On Mon, Jan 16, 2017 at 01:04:09PM +, Andrew Cooper wrote: > >> The chageset/version/compile information is currently exported as a set of > >> function calls into a separate

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote: > On Mon, Jan 16, 2017 at 01:04:09PM +, Andrew Cooper wrote: >> The chageset/version/compile information is currently exported as a set of >> function calls into a separate translation unit, which is inefficient for all >> callers. >> >> Replace

Re: [Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

On Mon, Jan 16, 2017 at 05:09:24PM -0800, Stefano Stabellini wrote: > On Mon, 16 Jan 2017, Andrii Anisov wrote: > > From: Andrii Anisov > > > > Signed-off-by: Andrii Anisov > > Thanks for the patch! > > > > arch/arm/xen/mm.c | 11 +++ >

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

On Mon, Jan 16, 2017 at 01:04:09PM +, Andrew Cooper wrote: > The chageset/version/compile information is currently exported as a set of > function calls into a separate translation unit, which is inefficient for all > callers. > > Replace the function calls with externs pointing appropriately

[Xen-devel] PV audio drivers for Linux

Hi, I am trying to develop PV audio drivers and facing one issue to achieve zero copy of the buffers between Front End (DOM1) and Back End (DOM0) drivers. When the buffer is allocated using __get_free_pages() on the DOM0 OS, I am able to grant the access using gnttab_grant_foreign_access()

Re: [Xen-devel] PVH CPU hotplug design document

On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote: > On 01/17/2017 10:33 AM, Jan Beulich wrote: > On 17.01.17 at 16:27, wrote: > >> On 01/17/2017 09:44 AM, Jan Beulich wrote: > >> On 17.01.17 at 15:13, wrote: > There's

[Xen-devel] [PATCH 4/5] xen: sched: impove use of cpumask scratch space in Credit1.

It is ok to use just cpumask_scratch in csched_runq_steal(). In fact, the cpu parameter comes from the cpu local variable in csched_load_balance(), which in turn comes from cpu in csched_schedule(), which is smp_processor_id(). While there, also: - move the comment about cpumask_scratch in the

[Xen-devel] [PATCH v4 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...

... HVMOP_set_pci_link_route These HVMOPs were exposed to guests so their definitions need to be preserved for compatibility. This patch therefore updates __XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.

[Xen-devel] [PATCH v4 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

NOTE: This patch also modifies the types of the 'vector', 'type' and 'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to uint8_t. In practice the values passed were always truncated to 8 bits. Suggested-by: Jan Beulich Signed-off-by: Paul Durrant

[Xen-devel] [PATCH v4 8/8] x86/hvm: serialize trap injecting producer and consumer

Since injection works on a remote vCPU, and since there's no enforcement of the subject vCPU being paused, there's a potential race between the producing and consuming sides. Fix this by leveraging the vector field as synchronization variable. Signed-off-by: Jan Beulich

[Xen-devel] [PATCH v4 0/8] New hypercall for device models

Following on from the design submitted by Jennifer Herbert to the list [1] this series provides an implementation of __HYPERCALL_dm_op followed by patches based on Jan Beulich's previous HVMCTL series [2] to convert tools-only HVMOPs used by device models to DMOPs. [1]

[Xen-devel] [PATCH v4 2/8] dm_op: convert HVMOP_*ioreq_server*

The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are already in use by callers of the libxc interface. Suggested-by: Jan Beulich Signed-off-by: Paul Durrant -- Reviewed-by: Jan Beulich Cc: Ian Jackson

[Xen-devel] [PATCH v4 3/8] dm_op: convert HVMOP_track_dirty_vram

The handle type passed to the underlying shadow and hap functions is changed for compatibility with the new hypercall buffer. NOTE: This patch also modifies the type of the 'nr' parameter of xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice the value passed was always

[Xen-devel] [PATCH v4 1/8] public / x86: Introduce __HYPERCALL_dm_op...

...as a set of hypercalls to be used by a device model. As stated in the new docs/designs/dm_op.markdown: "The aim of DMOP is to prevent a compromised device model from compromising domains other then the one it is associated with. (And is therefore likely already compromised)." See that file

[Xen-devel] [PATCH v4 6/8] dm_op: convert HVMOP_set_mem_type

This patch removes the need for handling HVMOP restarts, so that infrastructure is removed. NOTE: This patch also modifies the type of the 'nr' argument of xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the value passed was always truncated to 32 bits. Suggested-by: Jan

[Xen-devel] [PATCH v4 5/8] dm_op: convert HVMOP_modified_memory

This patch introduces code to handle DMOP continuations. NOTE: This patch also modifies the type of the 'nr' argument of xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the value passed was always truncated to 32 bits. Suggested-by: Jan Beulich

[Xen-devel] [PATCH v3] kexec: implement STATUS hypercall to check if image is loaded

The tools that use kexec are asynchronous in nature and do not keep state changes. As such provide an hypercall to find out whether an image has been loaded for either type. Note: No need to modify XSM as it has one size fits all check and does not check for subcommands. Note: No need to check

[Xen-devel] [PATCH 3/5] xen: credit2: fix shutdown/suspend when playing with cpupools.

In fact, during shutdown/suspend, we temporarily move all the vCPUs to the BSP (i.e., pCPU 0, as of now). For Credit2 domains, we call csched2_vcpu_migrate(), expects to find the target pCPU in the domain's pool Therefore, if Credit2 is the default scheduler and we have removed pCPU 0 from

[Xen-devel] [PATCH 5/5] xen: sched: simplify ACPI S3 resume path.

In fact, when domains are being unpaused: - it's not necessary to put the vcpu to sleep, as they are all already paused; - it is not necessary to call vcpu_migrate(), as the vcpus are still paused, and therefore won't wakeup anyway. Basically, the only important thing is to call

[Xen-devel] [PATCH 0/5] xen: sched: scheduling (mostly, Credit2) and cpupool fixes and improvements

Hello, This series fixes a few issues issues, related to Credit2 and to scheduling and cpupools interactions in a more general fashion. The first 3 patches cures (symptoms of) bugs in Credit2, and should be backported to 4.8 (it should not be too hard to do so, and I can help with that, if

[Xen-devel] [PATCH 1/5] xen: credit2: use the correct scratch cpumask.

In fact, there is one scratch mask per each CPU. When you use the one of a CPU, it must be true that: - the CPU belongs to your cpupool and scheduler, - you own the runqueue lock (the one you take via {v,p}cpu_schedule_lock()) for that CPU. This was not the case within the following

[Xen-devel] [DRAFT C] PVH CPU hotplug design document

Hello, Below is a draft of a design document for PVHv2 CPU hotplug. It should cover both vCPU and pCPU hotplug. It's mainly centered around the hardware domain, since for unprivileged PVH guests the vCPU hotplug mechanism is already described in Boris series [0], and it's shared with HVM. The

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

>>> On 17.01.17 at 16:08, wrote: > I was lucky to capture the full log before it fills up my 100MB ring buffer > (in less than 2 seconds). > Please find the log in the attachment. Sadly nothing helpful in there; I'm a little puzzled though that the first thing

[Xen-devel] [PATCH] xen/arm: bootfdt.c is only used during initialization

This file contains data and code only used at initialization. Mark the file as such in the build system and correct kind_guess. Signed-off-by: Julien Grall --- xen/arch/arm/Makefile | 2 +- xen/arch/arm/bootfdt.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

[Xen-devel] [PATCH] xen/arm: Don't mix GFN and MFN when using iomem_deny_access

iomem_deny_access is working on MFN and not GFN. Make it clear by renaming the local variables. Signed-off-by: Julien Grall --- xen/arch/arm/domain_build.c | 6 +++--- xen/arch/arm/gic-v2.c | 18 +- xen/arch/arm/gic-v3.c | 18 +-

Re: [Xen-devel] PVH CPU hotplug design document

On 01/17/2017 10:33 AM, Jan Beulich wrote: On 17.01.17 at 16:27, wrote: >> On 01/17/2017 09:44 AM, Jan Beulich wrote: >> On 17.01.17 at 15:13, wrote: There's only one kind of PVHv2 guest that doesn't require ACPI, and that

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

>>> On 17.01.17 at 16:06, wrote: > On 17/01/17 12:29, George Dunlap wrote: >> On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper >> wrote: >>> On 16/01/17 16:16, Jan Beulich wrote: >>> On 16.01.17 at 17:05, wrote:

Re: [Xen-devel] [PATCH v2 2/6] x86/cpuid: Introduce recalculate_xstate()

On 17/01/17 15:28, Jan Beulich wrote: On 17.01.17 at 16:15, wrote: >> On 17/01/17 12:52, Jan Beulich wrote: >> On 17.01.17 at 12:27, wrote: @@ -154,6 +152,13 @@ struct cpuid_policy }; uint32_t

Re: [Xen-devel] PVH CPU hotplug design document

>>> On 17.01.17 at 16:27, wrote: > On 01/17/2017 09:44 AM, Jan Beulich wrote: > On 17.01.17 at 15:13, wrote: >>> There's only one kind of PVHv2 guest that doesn't require ACPI, and that >>> guest >>> type also doesn't have emulated local

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

>>> On 17.01.17 at 16:13, wrote: > On 17/01/17 12:42, Jan Beulich wrote: >> And I'm not sure we really need to bother considering hypothetical 128-bit architectures at this point in time. >>> Because considering this case will avoid us painting

Re: [Xen-devel] STAO spec in xen.git

On Fri, Jan 13, Julien Grall wrote: > Regarding the format. Does ODT will allow git to do proper diff? There is flat ODT, "Safe as ..." and pick the better format from the pulldown menu. Olaf signature.asc Description: PGP signature ___ Xen-devel

Re: [Xen-devel] [PATCH v2 2/6] x86/cpuid: Introduce recalculate_xstate()

>>> On 17.01.17 at 16:15, wrote: > On 17/01/17 12:52, Jan Beulich wrote: > On 17.01.17 at 12:27, wrote: >>> @@ -154,6 +152,13 @@ struct cpuid_policy >>> }; >>> uint32_t /* b */:32, xss_low, xss_high; >>>

Re: [Xen-devel] [PATCH v2 2/6] x86/cpuid: Introduce recalculate_xstate()

On 17/01/17 12:52, Jan Beulich wrote: On 17.01.17 at 12:27, wrote: >> --- a/xen/arch/x86/cpuid.c >> +++ b/xen/arch/x86/cpuid.c >> @@ -80,6 +80,103 @@ static void sanitise_featureset(uint32_t *fs) >>(fs[FEATURESET_e1d] &

Re: [Xen-devel] PVH CPU hotplug design document

On 01/17/2017 09:44 AM, Jan Beulich wrote: On 17.01.17 at 15:13, wrote: >> On Tue, Jan 17, 2017 at 05:33:41AM -0700, Jan Beulich wrote: >> On 17.01.17 at 12:43, wrote: If the PVH domain has access to an APIC and wants to use it it must

Re: [Xen-devel] STAO spec in xen.git

On 17/01/17 04:55, Juergen Gross wrote: > On 16/01/17 19:40, Stefano Stabellini wrote: >> On Mon, 16 Jan 2017, Ian Jackson wrote: >>> Stefano Stabellini writes ("Re: STAO spec in xen.git"): In that case, I think we should still commit it as ODT, but convert it automatically to PDF when

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

On 17/01/17 12:42, Jan Beulich wrote: > >>> And I'm not sure we really need to bother considering hypothetical >>> 128-bit architectures at this point in time. >> Because considering this case will avoid us painting ourselves into a >> corner. > Why would we consider this case

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

On 17/01/17 12:29, George Dunlap wrote: > On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper > wrote: >> On 16/01/17 16:16, Jan Beulich wrote: >> On 16.01.17 at 17:05, wrote: On 13/01/17 12:47, Jan Beulich wrote: > The kernel

  1   2   >