[Xen-devel] [linux-3.18 test] 135872: regressions - FAIL

flight 135872 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/135872/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-

Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

On 5/10/19 2:03 AM, Tamas K Lengyel wrote: >> Either way, everything comes down to what behaviour is wanted to start with. > As I said, I think adding that monitoring capability is fine as long > as its limitation is clearly documented. Right. My thoughts as well. Thanks, Razvan ___

Re: [Xen-devel] [PATCH] xenbus: Avoid deadlock during suspend due to open transactions

On 08/05/2019 12:28, Ross Lagerwall wrote: > During a suspend/resume, the xenwatch thread waits for all outstanding > xenstore requests and transactions to complete. This does not work > correctly for transactions started by userspace because it waits for > them to complete after freezing userspace

Re: [Xen-devel] [PATCH v2 4/5] xen: fix handling framebuffer located above 4GB

On 09/05/2019 21:48, Marek Marczykowski-Górecki wrote: > On some machines (for example Thinkpad P52), UEFI GOP reports > framebuffer located above 4GB (0x40 on that machine). This > address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base > field, which is 32bit. The overflow

[Xen-devel] [ovmf test] 135885: all pass - PUSHED

flight 135885 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/135885/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f5245a1db144be95046deaed71a99b64362595b6 baseline version: ovmf fbb0ec7ea4c0d1e9e397f

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

> On May 9, 2019, at 21:28, Lars Kurth wrote: > > Hi all, > > following a discussion with committers about Guest testing in OSSTEST, it > surfaced that we have not updated what distros we test in OSSTEST for a very > long time. All agreed that we should regularly review what we test against:

[Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

Hi all, following a discussion with committers about Guest testing in OSSTEST, it surfaced that we have not updated what distros we test in OSSTEST for a very long time. All agreed that we should regularly review what we test against: maybe at the beginning of a release cycle In any case, curr

Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

On Thu, May 9, 2019 at 4:54 PM Andrew Cooper wrote: > > On 09/05/2019 23:34, Tamas K Lengyel wrote: > > On Thu, May 9, 2019 at 3:50 PM Razvan Cojocaru > > wrote: > >> On 5/10/19 12:31 AM, Andrew Cooper wrote: > >>> What we'll have to do is end up in a position where we can have some > >>> real %d

Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

On 09/05/2019 23:34, Tamas K Lengyel wrote: > On Thu, May 9, 2019 at 3:50 PM Razvan Cojocaru > wrote: >> On 5/10/19 12:31 AM, Andrew Cooper wrote: >>> What we'll have to do is end up in a position where we can have some >>> real %dr settings given by the VMI agent, and some shadow %dr settings >>>

Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

On Thu, May 9, 2019 at 3:50 PM Razvan Cojocaru wrote: > > On 5/10/19 12:31 AM, Andrew Cooper wrote: > > What we'll have to do is end up in a position where we can have some > > real %dr settings given by the VMI agent, and some shadow %dr settings > > which the guest interacts with. Also I should

Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

On 09/05/2019 22:50, Razvan Cojocaru wrote: > On 5/10/19 12:31 AM, Andrew Cooper wrote: >> What we'll have to do is end up in a position where we can have some >> real %dr settings given by the VMI agent, and some shadow %dr settings >> which the guest interacts with.  Also I should warn you at thi

Re: [Xen-devel] [PATCH v2 0/3] mwait support for AMD processors

On Thu, Mar 28, 2019 at 03:04:32PM +, Brian Woods wrote: > This patch series add support and enablement for mwait on AMD Naples > and Rome processors. Newer AMD processors support mwait, but only for > c1, and for c2 halt is used. The mwait-idle driver is modified to be > able to use both mwa

Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

On 5/10/19 12:31 AM, Andrew Cooper wrote: > What we'll have to do is end up in a position where we can have some > real %dr settings given by the VMI agent, and some shadow %dr settings > which the guest interacts with.  Also I should warn you at this point > that, because of how the registers work

[Xen-devel] [xen-4.7-testing test] 135874: regressions - FAIL

flight 135874 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/135874/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 133596 build-i386-prev

Re: [Xen-devel] [PATCH v2 4/7] xen/arm: page: Clarify the Xen TLBs helpers name

Hi, On 09/05/2019 21:32, Julien Grall wrote: > Hi, > > On 09/05/2019 21:13, Stefano Stabellini wrote: >> On Wed, 8 May 2019, Julien Grall wrote: >>>   /* Release all __init and __initdata ranges to be reused */ >>> diff --git a/xen/include/asm-arm/arm32/page.h >>> b/xen/include/asm-arm/arm32/pag

Re: [Xen-devel] [PATCH v2 6/7] xen/arm: tlbflush: Rework TLB helpers

On Wed, 8 May 2019, Julien Grall wrote: > All the TLBs helpers invalidate all the TLB entries are using the same > pattern: > DSB SY > TLBI ... > DSB SY > ISB > > This pattern is following pattern recommended by the Arm Arm to ensure > visibility of updates to translation tables (s

Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

On 09/05/2019 22:10, Razvan Cojocaru wrote: > On 5/9/19 11:57 PM, Mathieu Tarral wrote: >> Hi, >> >> following a previous conversation, i would like to catch MOV-TO-DRx VMI >> events to prevent the guest from disabling my hardware breakpoints. >> >> @Tamas pointed me to this header: >> https://xen

Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

On 5/9/19 11:57 PM, Mathieu Tarral wrote: > Hi, > > following a previous conversation, i would like to catch MOV-TO-DRx VMI > events to prevent the guest from disabling my hardware breakpoints. > > @Tamas pointed me to this header: > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include

[Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

Hi, following a previous conversation, i would like to catch MOV-TO-DRx VMI events to prevent the guest from disabling my hardware breakpoints. @Tamas pointed me to this header: https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/vm_event.h;h=b2bafc0d77f9758e42b0d53c05a7e6bb86c

Re: [Xen-devel] [PATCH v2 6/7] xen/arm: tlbflush: Rework TLB helpers

On 09/05/2019 21:32, Stefano Stabellini wrote: > On Wed, 8 May 2019, Julien Grall wrote: > I agree with what you are trying to achieve with this patch and I like > the idea of reducing code duplication. As I look at the code, I was > hoping to find a way to avoid introducing macros and use static

Re: [Xen-devel] [PATCH v2 7/7] xen/arm: mm: Flush the TLBs even if a mapping failed in create_xen_entries

On Wed, 8 May 2019, Julien Grall wrote: > At the moment, create_xen_entries will only flush the TLBs if the full > range has successfully been updated. This may lead to leave unwanted > entries in the TLBs if we fail to update some entries. > > Signed-off-by: Julien Grall > Reviewed-by: Andrii An

Re: [Xen-devel] [PATCH v2 6/7] xen/arm: tlbflush: Rework TLB helpers

On Wed, 8 May 2019, Julien Grall wrote: > All the TLBs helpers invalidate all the TLB entries are using the same > pattern: > DSB SY > TLBI ... > DSB SY > ISB > > This pattern is following pattern recommended by the Arm Arm to ensure > visibility of updates to translation tables (s

Re: [Xen-devel] [PATCH v2 4/7] xen/arm: page: Clarify the Xen TLBs helpers name

Hi, On 09/05/2019 21:13, Stefano Stabellini wrote: > On Wed, 8 May 2019, Julien Grall wrote: >> /* Release all __init and __initdata ranges to be reused */ >> diff --git a/xen/include/asm-arm/arm32/page.h >> b/xen/include/asm-arm/arm32/page.h >> index 40a77daa9d..0b41b9214b 100644 >> --- a/xen/

Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Remove flush_xen_text_tlb_local()

Hi, On 09/05/2019 21:03, Stefano Stabellini wrote: > On Wed, 8 May 2019, Julien Grall wrote: >> The function flush_xen_text_tlb_local() has been misused and will result >> to invalidate the instruction cache more than necessary. >> >> For instance, there are no need to invalidate the instruction c

Re: [Xen-devel] [PATCH v2 5/7] xen/arm: Gather all TLB flush helpers in tlbflush.h

On Wed, 8 May 2019, Julien Grall wrote: > At the moment, TLB helpers are scattered in 2 headers: page.h (for > Xen TLB helpers) and tlbflush.h (for guest TLB helpers). > > This patch is gathering all of them in tlbflush. This will help to > uniformize and update the logic of the helpers in follow-

Re: [Xen-devel] [PATCH v2 4/7] xen/arm: page: Clarify the Xen TLBs helpers name

On Wed, 8 May 2019, Julien Grall wrote: > Now that we dropped flush_xen_text_tlb_local(), we have only one set of > helpers acting on Xen TLBs. There naming are quite confusing because the > TLB instructions used will act on both Data and Instruction TLBs. > > Take the opportunity to rework the do

Re: [Xen-devel] [PATCH v2 3/7] xen/arm: tlbflush: Clarify the TLB helpers name

On Wed, 8 May 2019, Julien Grall wrote: > TLB helpers in the headers tlbflush.h are currently quite confusing to > use the name may lead to think they are dealing with hypervisors TLBs > while they actually deal with guest TLBs. > > Rename them to make it clearer that we are dealing with guest TLB

Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Remove flush_xen_text_tlb_local()

On Wed, 8 May 2019, Julien Grall wrote: > The function flush_xen_text_tlb_local() has been misused and will result > to invalidate the instruction cache more than necessary. > > For instance, there are no need to invalidate the instruction cache if ^ is > we are setting SC

[Xen-devel] [qemu-upstream-4.11-testing test] 135869: regressions - FAIL

flight 135869 qemu-upstream-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/135869/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken in 134594 build-arm64-xsm

Re: [Xen-devel] [PATCH v2 1/7] xen/arm: mm: Consolidate setting SCTLR_EL2.WXN in a single place

On Wed, 8 May 2019, Julien Grall wrote: > The logic to set SCTLR_EL2.WXN is the same for the boot CPU and > non-boot CPU. So introduce a function to set the bit and clear TLBs. > > This new function will help us to document and update the logic in a > single place. > > Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call

On Thu, 9 May 2019, Julien Grall wrote: > Hi Stefano, > > On 5/9/19 7:16 PM, Stefano Stabellini wrote: > > On Thu, 9 May 2019, Julien Grall wrote: > > > Hi, > > > > > > On 5/9/19 7:06 PM, Stefano Stabellini wrote: > > > > On Tue, 7 May 2019, Julien Grall wrote: > > > > > diff --git a/xen/include/

[Xen-devel] [PATCH v2 4/5] xen: fix handling framebuffer located above 4GB

On some machines (for example Thinkpad P52), UEFI GOP reports framebuffer located above 4GB (0x40 on that machine). This address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base field, which is 32bit. The overflow here cause all kind of memory corruption when anything tries t

[Xen-devel] [PATCH v2 0/5] Fixes for large framebuffer, placed above 4GB

A bunch of fixes for booting Xen on Thinkpad P52, through grub2-efi + multiboot2. Most of them can be applied independently. --- cc: Andrew Cooper cc: George Dunlap cc: Ian Jackson cc: Jan Beulich cc: Julien Grall cc: Konrad Rzeszutek Wilk cc: Stefano Stabellini cc: Tim Deegan cc: Wei Liu

[Xen-devel] [PATCH v2 2/5] drivers/video: drop unused limits

MAX_BPP, MAX_FONT_W, MAX_FONT_H are not used in the code at all. Signed-off-by: Marek Marczykowski-Górecki Suggested-by: Jan Beulich Acked-by: Andrew Cooper --- xen/drivers/video/lfb.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c index

[Xen-devel] [PATCH v2 5/5] drivers/video: use vlfb_info consistently

vlfb_info is an alias for vga_console_info.u.vesa_lfb, so this change is purely cosmetic. But using the same name helps reading the code. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Andrew Cooper --- xen/drivers/video/vesa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --

[Xen-devel] [PATCH v2 3/5] drivers/video: Drop framebuffer size constraints

The limit 1900x1200 do not match real world devices (1900 looks like a typo, should be 1920). But in practice the limits are arbitrary and do not serve any real purpose. As discussed in "Increase framebuffer size to todays standards" thread, drop them completely. This fixes graphic console on devi

[Xen-devel] [PATCH v2 1/5] xen/bitmap: fix bitmap_fill with zero-sized bitmap

When bitmap_fill(..., 0) is called, do not try to write anything. Before this patch, it tried to write almost LONG_MAX, surely overwriting something. Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Andrew Cooper Reviewed-by: Jan Beulich --- xen/include/xen/bitmap.h | 2 ++ 1 file change

Re: [Xen-devel] [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call

Hi Stefano, On 5/9/19 7:16 PM, Stefano Stabellini wrote: On Thu, 9 May 2019, Julien Grall wrote: Hi, On 5/9/19 7:06 PM, Stefano Stabellini wrote: On Tue, 7 May 2019, Julien Grall wrote: diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index d1bfc82f57..f1761fe183 100644 --- a

Re: [Xen-devel] [PATCH 14/14] xen/mm: Provide dummy M2P-related helpers when !CONFIG_HAVE_M2P

On Tue, 7 May 2019, Julien Grall wrote: > At the moment, Arm is providing a dummy implementation for the M2P > helpers used in common code. However, they are quite isolated and could > be used by other architecture in the future. So move all the helpers in > xen/mm.h. > > Signed-off-by: Julien Gra

Re: [Xen-devel] [PATCH 13/14] xen/mm: Convert {s, g}et_gpfn_from_mfn() to use typesafe MFN

On Tue, 7 May 2019, Julien Grall wrote: > The first parameter of {s,g}et_gpfn_from_mfn() is an MFN, so it can be > switched to use the typesafe. > > At the same time, replace gpfn with pfn in the helpers as they all deal > with PFN and also turn the macros to static inline. > > Note that the retu

Re: [Xen-devel] [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call

On Tue, 7 May 2019, Julien Grall wrote: > While Arm never had a M2P, the implementation of mfn_to_gmfn is pretty > bogus as we directly return the MFN passed in parameter. > > Thankfully, the use of mfn_to_gmfn is pretty limited on Arm today. There > are only 3 callers: > - iommu_hwdom_init: m

Re: [Xen-devel] [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call

Hi, On 5/9/19 7:06 PM, Stefano Stabellini wrote: On Tue, 7 May 2019, Julien Grall wrote: diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index d1bfc82f57..f1761fe183 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -118,4 +118,12 @@ struct vnuma_info {

Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

On Thu, May 9, 2019 at 12:00 PM Andrew Cooper wrote: > > On 09/05/2019 18:46, Tamas K Lengyel wrote: > > On Thu, May 9, 2019 at 10:43 AM Andrew Cooper > > wrote: > >> On 09/05/2019 17:19, Mathieu Tarral wrote: > >>> Le mardi, mai 7, 2019 2:01 PM, Mathieu Tarral > >>> a écrit : > >>> > > Gi

Re: [Xen-devel] [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call

On Thu, 9 May 2019, Julien Grall wrote: > Hi, > > On 5/9/19 7:06 PM, Stefano Stabellini wrote: > > On Tue, 7 May 2019, Julien Grall wrote: > > > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h > > > index d1bfc82f57..f1761fe183 100644 > > > --- a/xen/include/xen/domain.h > > > +++

Re: [Xen-devel] [PATCH 06/14] xen: Convert hotplug page function to use typesafe MFN

Hi Stefano, On 5/9/19 7:01 PM, Stefano Stabellini wrote: On Tue, 7 May 2019, Julien Grall wrote: Convert online_page, offline_page and query_page_offline to use typesafe MFN. I would like to have a statement in the commit message mentioning the changes below to mci_action_add_pageoffline and

Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

On 09/05/2019 18:46, Tamas K Lengyel wrote: > On Thu, May 9, 2019 at 10:43 AM Andrew Cooper > wrote: >> On 09/05/2019 17:19, Mathieu Tarral wrote: >>> Le mardi, mai 7, 2019 2:01 PM, Mathieu Tarral >>> a écrit : >>> > Given how many EPT flushing bugs I've already found in this area, I >

Re: [Xen-devel] [PATCH 05/14] xen/grant-table: Make arch specific macros typesafe

On Tue, 7 May 2019, Julien Grall wrote: > This patch rework all the arch specific macros in grant_table.h to use > the typesafe MFN/GFN. > > At the same time, some functions are renamed s/gmfn/gfn/ to match the > current naming scheme (see include/mm.h). > > No functional changes intended. > > S

Re: [Xen-devel] [PATCH 06/14] xen: Convert hotplug page function to use typesafe MFN

On Tue, 7 May 2019, Julien Grall wrote: > Convert online_page, offline_page and query_page_offline to use > typesafe MFN. I would like to have a statement in the commit message mentioning the changes below to mci_action_add_pageoffline and mc_memerr_dhandler. From an ARM point of view, it is fine

Re: [Xen-devel] [PATCH 01/14] xen/arm: Use mfn_to_pdx instead of pfn_to_pdx when possible

On Tue, 7 May 2019, Julien Grall wrote: > mfn_to_pdx adds more safety than pfn_to_pdx. Replace all but on place in > the Arm code to use the former. > > No functional changes. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- > There are still one use of pfn_to_pdx in

Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

> I don't feel comfortable digging into Xen's code, especially for something as > complicated as page table and memory management, > increased by the complexity of altp2m. Unfortunately the reality is that you might very well have to become familiar with these areas if you hope to debug some of t

Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

On Thu, May 9, 2019 at 10:43 AM Andrew Cooper wrote: > > On 09/05/2019 17:19, Mathieu Tarral wrote: > > Le mardi, mai 7, 2019 2:01 PM, Mathieu Tarral > > a écrit : > > > >>> Given how many EPT flushing bugs I've already found in this area, I > >>> wouldn't be surprised if there are further ones

[Xen-devel] [RFC PATCH 15/16] xen/net: gnttab, evtchn, xenbus API changes

For the most part, we now pass xenhost_t * as parameter. Co-developed-by: Joao Martins Signed-off-by: Ankur Arora --- drivers/net/xen-netback/hash.c | 7 +- drivers/net/xen-netback/interface.c | 7 +- drivers/net/xen-netback/netback.c | 11 +-- drivers/net/xen-netback/rx.c|

[Xen-devel] [RFC PATCH 07/16] x86/xen: make vcpu_info part of xenhost_t

Abstract out xen_vcpu_id probing via (*probe_vcpu_id)(). Once that is availab,e the vcpu_info registration happens via the VCPUOP hypercall. Note that for the nested case, there are two vcpu_ids, and two vcpu_info areas, one each for the default xenhost and the remote xenhost. The vcpu_info is use

[Xen-devel] [RFC PATCH 08/16] x86/xen: irq/upcall handling with multiple xenhosts

For configurations with multiple xenhosts, we need to handle events generated from multiple xenhosts. Having more than one upcall handler might be quite hairy, and it would be simpler if the callback from L0-Xen could be bounced via L1-Xen. This will also mean simpler pv_irq_ops code because now t

[Xen-devel] [RFC PATCH 02/16] x86/xen: cpuid support in xenhost_t

xen_cpuid_base() is used to probe and setup features early in a guest's lifetime. We want this to behave differently depending on xenhost->type: for instance, local xenhosts cannot intercept the cpuid instruction at all. Add op (*cpuid_base)() in xenhost_ops_t. Signed-off-by: Ankur Arora --- a

[Xen-devel] [RFC PATCH 14/16] xen/blk: gnttab, evtchn, xenbus API changes

For the most part, we now pass xenhost_t * as a parameter. Co-developed-by: Joao Martins Signed-off-by: Ankur Arora --- drivers/block/xen-blkback/blkback.c | 34 + drivers/block/xen-blkback/common.h | 2 +- drivers/block/xen-blkback/xenbus.c | 63 - drivers/block/x

[Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t

Allow for different hypercall implementations for different xenhost types. Nested xenhost, which has two underlying xenhosts, can use both simultaneously. The hypercall macros (HYPERVISOR_*) implicitly use the default xenhost.x A new macro (hypervisor_*) takes xenhost_t * as a parameter and does t

[Xen-devel] [RFC PATCH 10/16] xen/balloon: support ballooning in xenhost_t

Xen ballooning uses hollow struct pages (with the underlying GFNs being populated/unpopulated via hypercalls) which are used by the grant logic to map grants from other domains. This patch allows the default xenhost to provide an alternate ballooning allocation mechanism. This is expected to be us

[Xen-devel] [RFC PATCH 01/16] x86/xen: add xenhost_t interface

Add xenhost_t which will serve as an abstraction over Xen interfaces. It co-exists with the PV/HVM/PVH abstractions (x86_init, hypervisor_x86, pv_ops etc) and is meant to capture mechanisms for communication with Xen so we could have different types of underlying Xen: regular, local, and nested. A

[Xen-devel] [RFC PATCH 11/16] xen/grant-table: make grant-table xenhost aware

Largely mechanical changes: the exported grant table symbols now take xenhost_t * as a parameter. Also, move the grant table global state inside xenhost_t. If there's more than one xenhost, then initialize both. Signed-off-by: Ankur Arora --- arch/x86/xen/grant-table.c | 71 +++-- drivers/xen/

[Xen-devel] [RFC PATCH 12/16] xen/xenbus: support xenbus frontend/backend with xenhost_t

As part of xenbus init, both frontend, backend interfaces need to talk on the correct xenbus. This might be a local xenstore (backend) or might be a XS_PV/XS_HVM interface (frontend) which needs to talk over xenbus with the remote xenstored. We bootstrap all of these with evtchn/gfn parameters from

[Xen-devel] [RFC PATCH 13/16] drivers/xen: gnttab, evtchn, xenbus API changes

Mechanical changes, now most of these calls take xenhost_t * as parameter. Co-developed-by: Joao Martins Signed-off-by: Ankur Arora --- drivers/xen/cpu_hotplug.c | 14 ++--- drivers/xen/gntalloc.c| 13 drivers/xen/gntdev.c | 16 +++ drivers/

[Xen-devel] [RFC PATCH 16/16] xen/grant-table: host_addr fixup in mapping on xenhost_r0

Xenhost type xenhost_r0 does not support standard GNTTABOP_map_grant_ref semantics (map a gref onto a specified host_addr). That's because since the hypervisor is local (same address space as the caller of GNTTABOP_map_grant_ref), there is no external entity that could map an arbitrary page underne

[Xen-devel] [RFC PATCH 03/16] x86/xen: make hypercall_page generic

Make hypercall_page a generic interface which can be implemented by other hypervisors. With this change, hypercall_page now points to the newly introduced xen_hypercall_page which is seeded by Xen, or to one that is filled in by a different hypervisor. Signed-off-by: Ankur Arora --- arch/x86/inc

[Xen-devel] [RFC PATCH 09/16] xen/evtchn: support evtchn in xenhost_t

Largely mechanical patch that adds a new param, xenhost_t * to the evtchn interfaces. The evtchn port instead of being domain unique, is now scoped to xenhost_t. As part of upcall handling we now look at all the xenhosts and, for evtchn_2l, the xenhost's shared_info and vcpu_info. Other than this

[Xen-devel] [RFC PATCH 00/16] xenhost support

Hi all, This is an RFC for xenhost support, outlined here by Juergen here: https://lkml.org/lkml/2019/4/8/67. The high level idea is to provide an abstraction of the Xen communication interface, as a xenhost_t. xenhost_t expose ops for communication between the guest and Xen (hypercall, cpuid, s

[Xen-devel] [RFC PATCH 06/16] x86/xen: add shared_info support to xenhost_t

HYPERVISOR_shared_info is used for irq/evtchn communication between the guest and the host. Abstract out the setup/reset in xenhost_t such that nested configurations can use both xenhosts simultaneously. In addition to irq/evtchn communication, shared_info is also used for pvclock and p2m related

[Xen-devel] [RFC PATCH 05/16] x86/xen: add feature support in xenhost_t

With nested xenhosts, both the xenhosts could have different supported xen_features. Add support for probing both. In addition, validate that features are compatible across xenhosts. For runtime feature checking, the code uses xen_feature() with the default xenhost. This should be good enough bec

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

flight 135859 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/135859/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133835 test-amd64-amd64-xl-qemuu-ws16-amd64 17 g

Re: [Xen-devel] [PATCH v2 1/3] x86/mm: short-circuit HVM-only mode flags when !HVM

On Thu, May 09, 2019 at 07:42:15AM -0600, Jan Beulich wrote: > #define-ing them to zero allows better code generation in this case, > and paves the way for more DCE, allowing to leave certain functions just > declared, but not defined. > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu __

Re: [Xen-devel] [PATCH v2 2/3] x86/mm: make guest_physmap_add_entry() HVM-only

On Thu, May 09, 2019 at 07:44:25AM -0600, Jan Beulich wrote: > Lift its !paging_mode_translate() part into guest_physmap_add_page() > (which is what common code calls), eliminating the dummy use of a > (HVM-only really) P2M type in the PV case. > > Suggested-by: George Dunlap > Signed-off-by: Jan

Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

On 09/05/2019 17:19, Mathieu Tarral wrote: > Le mardi, mai 7, 2019 2:01 PM, Mathieu Tarral > a écrit : > >>> Given how many EPT flushing bugs I've already found in this area, I >>> wouldn't be surprised if there are further ones lurking.  If it is an EPT >>> flushing bug, this delta should make

Re: [Xen-devel] Altp2m use with PML can deadlock Xen

On 09/05/2019 14:38, Tamas K Lengyel wrote: > Hi all, > I'm investigating an issue with altp2m that can easily be reproduced > and leads to a hypervisor deadlock when PML is available in hardware. > I haven't been able to trace down where the actual deadlock occurs. > > The problem seem to stem fro

Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

Le mardi, mai 7, 2019 2:01 PM, Mathieu Tarral a écrit : > > Given how many EPT flushing bugs I've already found in this area, I > > wouldn't be surprised if there are further ones lurking.  If it is an EPT > > flushing bug, this delta should make it go away, but it will come with a > > hefty

Re: [Xen-devel] [PATCH v2] libxl: fix migration of PV and PVH domUs with and without qemu

Am Thu, 9 May 2019 18:14:10 +0200 schrieb Roger Pau Monné : > The patch below looks sensible to me, and it's more like what I was > expecting would be needed to solve this issue. The remaining question is if a new state should be introduced, or if LIBXL_DEVICE_MODEL_VERSION_UNKNOWN would be good

Re: [Xen-devel] [PATCH v2] libxl: fix migration of PV and PVH domUs with and without qemu

On Thu, May 09, 2019 at 05:54:38PM +0200, Olaf Hering wrote: > Am Fri, 3 May 2019 17:29:53 +0200 > schrieb Roger Pau Monné : > > > On Fri, May 03, 2019 at 04:11:32PM +0200, Olaf Hering wrote: > > > Am Fri, 3 May 2019 13:04:11 +0200 > > > schrieb Roger Pau Monné : > > > > > > > Wouldn't it be ea

Re: [Xen-devel] [PATCH] xen/sched: fix csched2_deinit_pdata()

On Wed, 2019-05-08 at 13:31 +0200, Juergen Gross wrote: > Commit 753ba43d6d16e688 ("xen/sched: fix credit2 smt idle handling") > introduced a regression when switching cpus between cpupools. > > When assigning a cpu to a cpupool with credit2 being the default > scheduler csched2_deinit_pdata() is

[Xen-devel] [qemu-upstream-4.10-testing test] 135836: FAIL

flight 135836 qemu-upstream-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/135836/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken in 134

Re: [Xen-devel] [PATCH v2] libxl: fix migration of PV and PVH domUs with and without qemu

Am Fri, 3 May 2019 17:29:53 +0200 schrieb Roger Pau Monné : > On Fri, May 03, 2019 at 04:11:32PM +0200, Olaf Hering wrote: > > Am Fri, 3 May 2019 13:04:11 +0200 > > schrieb Roger Pau Monné : > > > > > Wouldn't it be easier to leave libxl__need_xenpv_qemu alone and just > > > use the contents of

Re: [Xen-devel] [PATCH v2] libxl: fix migration of PV and PVH domUs with and without qemu

On Thu, May 09, 2019 at 04:29:56PM +0200, Olaf Hering wrote: > Am Thu, 9 May 2019 15:56:21 +0200 > schrieb Olaf Hering : > > > Am Fri, 3 May 2019 13:04:11 +0200 > > schrieb Roger Pau Monné : > > > > > I think the above call is wrong, libxl__need_xenpv_qemu expects to get > > > the domid of the to

[Xen-devel] [PATCH v3 1/4] xen: add hypercall for reading runtime parameters

Add a sysctl hypercall to support reading hypervisor runtime parameters. Limitations: - Custom runtime parameters (OPT_CUSTOM) are not supported yet. - For integer parameters (OPT_UINT), only unsigned parameters are printed correctly. - The implementation only reads runtime parameters, but it can

[Xen-devel] [PATCH v3 2/4] libxc: add function to get hypervisor parameters

Add a new libxc function to get hypervisor parameters. Signed-off-by: Vasilis Liaskovitis --- tools/libxc/include/xenctrl.h | 1 + tools/libxc/xc_misc.c | 26 ++ 2 files changed, 27 insertions(+) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/x

[Xen-devel] [PATCH v3 4/4] xl: add new xl command get-parameters

Add a new xl command "get-parameters" to get hypervisor runtime parameters. Examples: xl get-parameters "gnttab_max_frames gnttab_max_maptrack_frames" gnttab_max_frames gnttab_max_maptrack_frames : 64 1024 xl set-parameters gnttab_max_frames=128 xl get-parameters gnttab_max_frames gnttab_max_fr

[Xen-devel] [PATCH v3 0/4] Support for reading runtime hypervisor parameters

Currently runtime parameters of the hypervisor cannot be inspected through an xl command, however they can be changed with the "xl set-parameter" command. Being able to check these parameters at runtime would be a useful diagnostic tool. This patch series implements a new xl command "xl get-parame

[Xen-devel] [PATCH v3 3/4] libxl: add libxl_get_parameters() function

Add a new libxl function to get hypervisor parameters. Signed-off-by: Vasilis Liaskovitis --- tools/libxl/libxl.c | 15 +++ tools/libxl/libxl.h | 1 + 2 files changed, 16 insertions(+) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index ec71574e99..124033e5a3 100644 --- a/

[Xen-devel] [xen-4.6-testing test] 135850: regressions - FAIL

flight 135850 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/135850/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-buildfail REGR. vs. 127792 build-amd64-xsm

Re: [Xen-devel] [PATCH v2] libxl: fix migration of PV and PVH domUs with and without qemu

Am Thu, 9 May 2019 16:29:56 +0200 schrieb Olaf Hering : > Are you saying the current users of libxl__need_xenpv_qemu > (libxl__dm_check_start, > spawn_stub_launch_dm and domcreate_launch_dm) do not only run in dom0, but > also somewhere else? And if it is indeed running somewhere else, would li

Re: [Xen-devel] [PATCH v2] libxl: fix migration of PV and PVH domUs with and without qemu

Am Thu, 9 May 2019 15:56:21 +0200 schrieb Olaf Hering : > Am Fri, 3 May 2019 13:04:11 +0200 > schrieb Roger Pau Monné : > > > I think the above call is wrong, libxl__need_xenpv_qemu expects to get > > the domid of the toolstack domain (ie: the domain running this code), > > not the domain being c

Re: [Xen-devel] [PATCH] page-alloc: detect double free earlier

On 09/05/2019 14:25, Jan Beulich wrote: On 09.05.19 at 14:50, wrote: >> On 09/05/2019 13:35, Jan Beulich wrote: >>> Right now this goes unnoticed until some subsequent page allocator >>> operation stumbles across the thus corrupted list. We can do better: >>> Only PGC_state_inuse and PGC_stat

Re: [Xen-devel] [PATCH v2] libxl: fix migration of PV and PVH domUs with and without qemu

Am Fri, 3 May 2019 13:04:11 +0200 schrieb Roger Pau Monné : > I think the above call is wrong, libxl__need_xenpv_qemu expects to get > the domid of the toolstack domain (ie: the domain running this code), > not the domain being created. So, how do I actually test such setups? It seems a driver do

[Xen-devel] [PATCH v2 3/3] x86/mm: subsume set_gpfn_from_mfn() into guest_physmap_add_page()

The two callers in common/memory.c currently call set_gpfn_from_mfn() themselves, so moving the call into guest_physmap_add_page() helps tidy their code. The two callers in common/grant_table.c fail to make that call alongside the one to guest_physmap_add_page(), so will actually get fixed by the

[Xen-devel] [PATCH v2 2/3] x86/mm: make guest_physmap_add_entry() HVM-only

Lift its !paging_mode_translate() part into guest_physmap_add_page() (which is what common code calls), eliminating the dummy use of a (HVM-only really) P2M type in the PV case. Suggested-by: George Dunlap Signed-off-by: Jan Beulich --- v2: New. --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm

[Xen-devel] [PATCH v2 1/3] x86/mm: short-circuit HVM-only mode flags when !HVM

#define-ing them to zero allows better code generation in this case, and paves the way for more DCE, allowing to leave certain functions just declared, but not defined. Signed-off-by: Jan Beulich --- v2: New. --- a/xen/arch/x86/mm/paging.c +++ b/xen/arch/x86/mm/paging.c @@ -837,7 +837,9 @@ int p

[Xen-devel] [PATCH v2 0/3] x86/mm: guest_physmap_add_*() adjustments

Patch 1 is really independent, but patch 2 relies on it being in place. Patch 2 itself was added as a result of the discussion of patch 3's v1 (which was previously a standalone one). 1: short-circuit HVM-only mode flags when !HVM 2: make guest_physmap_add_entry() HVM-only 3: subsume set_gpfn_from

[Xen-devel] Altp2m use with PML can deadlock Xen

Hi all, I'm investigating an issue with altp2m that can easily be reproduced and leads to a hypervisor deadlock when PML is available in hardware. I haven't been able to trace down where the actual deadlock occurs. The problem seem to stem from hvm/vmx/vmcs.c:vmx_vcpu_flush_pml_buffer that calls p

Re: [Xen-devel] [PATCH] page-alloc: detect double free earlier

>>> On 09.05.19 at 14:50, wrote: > On 09/05/2019 13:35, Jan Beulich wrote: >> Right now this goes unnoticed until some subsequent page allocator >> operation stumbles across the thus corrupted list. We can do better: >> Only PGC_state_inuse and PGC_state_offlining pages can legitimately be >> pass

Re: [Xen-devel] [PATCH RFC V2 01/45] xen/sched: add inline wrappers for calling per-scheduler functions

>>> On 09.05.19 at 14:44, wrote: > On 09/05/2019 14:31, Jan Beulich wrote: > On 09.05.19 at 14:03, wrote: >>> On 09/05/2019 13:50, Jan Beulich wrote: >>> On 09.05.19 at 12:56, wrote: > On 09/05/2019 12:04, George Dunlap wrote: >> On 5/9/19 6:32 AM, Juergen Gross wrote: >>> On

Re: [Xen-devel] [ANNOUNCE] Xen Project Community Call May 9th @15:00 UTC Call for agenda items

I added these to the agenda https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit# Feel free to add to it Lars > On 6 May 2019, at 09:23, Lars Kurth wrote: > > > >> On 6 Ma

Re: [Xen-devel] [PATCH] gitlab-ci: avoid deleting build-each-commit-gcc.log

On Tue, May 07, 2019 at 05:11:01PM +0100, Wei Liu wrote: > 072a96c4901 used `git clean -ffdx` which caused the log to be deleted. > > Generate the log in the parent directory then move it back. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein ___

Re: [Xen-devel] [PATCH] page-alloc: detect double free earlier

On 09/05/2019 13:35, Jan Beulich wrote: > Right now this goes unnoticed until some subsequent page allocator > operation stumbles across the thus corrupted list. We can do better: > Only PGC_state_inuse and PGC_state_offlining pages can legitimately be > passed to free_heap_pages(). > > Take the op

  1   2   >