Re: [Xen-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver
On 08/24/2017 10:04 AM, Oleksandr Andrushchenko wrote: Hello, On 08/24/2017 07:38 AM, Takashi Sakamoto wrote: On Aug 23 2017 23:51, Oleksandr Grytsov wrote: Hi, Thank you for detailed explanation. We understand that emulated interrupt on the frontend side is completely not acceptable and definitely we need to provide some feedback mechanism from Dom0 to DomU. In our case it is technically impossible to provide precise period interrupt (mostly because our backend is a user space application). The best we can implement it is provide number of frames (time, bytes etc.) consumed by real HW. This info will be outdated due to different delays but we can provide precise timestamps when this info was acquired. Stuffs of ALSA PCM in kernel land is an abstraction layer for actual hardware for data transmission. The stuffs get affects from a design of actual hardware. Furthermore, sound subsystems on the other operating systems such as Microsoft Windows are also designed with a consideration about actual hardware. When you design any interfaces as an abstraction for such software layer, it's better to understand actual hardware and design of low-level software layer somehow. Actually the 'sndif' has no good abstraction for actual hardware, therefore an idea to implement frontend driver as an ALSA driver is not reasonable at all. the reason for that is that you can use the same frontend driver for various DomUs without the need to write yet another HAL/application, e.g. if one of the DomUs has no PulseAudio (uses ALSA) and yet another DomU has PulseAudio, then using the same driver allows you to enable both out of the box with the same codebase. If we can imagine something else running on top of ALSA (say some other mixing software other than PulseAudio) then we will have to support that as well It's better to implement it as an application in the other software layer, e.g. sinks/sources of PulseAudio in DomU please see our reasoning above via Xenbus. This idea is nearer an original concept of Xen framework, I guess. But I don't know we can write any applications of Xenbus in user land of DomU or not. Anyway, it's not a good idea to have an ALSA driver for the present 'sndif', in my opinion. ok, so the main concern here is that we cannot properly synchronize Dom0-DomU. If we put this apart for a second are there any other concerns on having ALSA frontend driver? If not, can we have the driver with timer implementation upstreamed as experimental until we have some acceptable synchronization solution? This will allow broader audience to try and feel the solution and probably contribute? any thoughts on this? Regards Takashi Sakamoto Thank you very much for your time, Oleksandr Andrushchenko ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0
On Thu, Aug 31, 2017 at 11:09:48AM +0100, Roger Pau Monne wrote: >On Thu, Aug 31, 2017 at 04:45:23PM +0800, Chao Gao wrote: >> On Thu, Aug 31, 2017 at 10:03:19AM +0100, Roger Pau Monne wrote: >> >On Thu, Aug 31, 2017 at 03:32:42PM +0800, Chao Gao wrote: >> >> On Tue, Aug 29, 2017 at 08:33:25AM +0100, Roger Pau Monne wrote: >> >> >On Mon, Aug 28, 2017 at 06:18:13AM +, Tian, Kevin wrote: >> >> >> > From: Roger Pau Monne [mailto:roger@citrix.com] >> >> >> > Sent: Friday, August 25, 2017 9:59 PM >> >> >> > >> >> >> > On Fri, Aug 25, 2017 at 06:25:36AM -0600, Jan Beulich wrote: >> >> >> > > >>> On 25.08.17 at 14:15, wrote: >> >> >> > > > On Wed, Aug 23, 2017 at 02:16:38AM -0600, Jan Beulich wrote: >> >> >> > > >> >>> On 22.08.17 at 15:54, wrote: >> >> >> > > >> > On Tue, Aug 22, 2017 at 06:26:23AM -0600, Jan Beulich wrote: >> >> >> > > >> >> >>> On 11.08.17 at 18:43, wrote: >> >> >> > > >> >> > --- a/xen/arch/x86/dom0_build.c >> >> >> > > >> >> > +++ b/xen/arch/x86/dom0_build.c >> >> >> > > >> >> > @@ -440,6 +440,10 @@ int __init >> >> >> > dom0_setup_permissions(struct domain *d) >> >> >> > > >> >> > rc |= rangeset_add_singleton(mmio_ro_ranges, >> >> >> > > >> >> > mfn); >> >> >> > > >> >> > } >> >> >> > > >> >> > >> >> >> > > >> >> > +/* For PVH prevent access to the MMCFG areas. */ >> >> >> > > >> >> > +if ( dom0_pvh ) >> >> >> > > >> >> > +rc |= pci_mmcfg_set_domain_permissions(d); >> >> >> > > >> >> >> >> >> > > >> >> What about ones reported by Dom0 later on? Which then raises >> >> >> > > >> >> the >> >> >> > > >> >> question whether ... >> >> >> > > >> > >> >> >> > > >> > This should be dealt with in the PHYSDEVOP_pci_mmcfg_reserved >> >> >> > handler. >> >> >> > > >> > But since you propose to do white listing, I guess it doesn't >> >> >> > > >> > matter >> >> >> > > >> > that much anymore. >> >> >> > > >> >> >> >> > > >> Well, a fundamental question is whether white listing would >> >> >> > > >> work in >> >> >> > > >> the first place. I could see room for severe problems e.g. with >> >> >> > > >> ACPI >> >> >> > > >> methods wanting to access MMIO that's not described by any PCI >> >> >> > > >> devices' BARs. Typically that would be regions in the chipset >> >> >> > > >> which >> >> >> > > >> firmware is responsible for configuring/managing, the addresses >> >> >> > > >> of >> >> >> > > >> which can be found/set in custom config space registers. >> >> >> > > > >> >> >> > > > The question would also be what would Xen allow in such >> >> >> > > > white-listing. >> >> >> > > > Obviously you can get to map the same using both white-list and >> >> >> > > > black-listing (see below). >> >> >> > > >> >> >> > > Not really - what you've said there regarding MMCFG regions is >> >> >> > > a clear indication that we should _not_ map reserved regions, i.e. >> >> >> > > it would need to be full white listing with perhaps just the PCI >> >> >> > > device BARs being handled automatically. >> >> >> > >> >> >> > I've tried just mapping the BARs and that sadly doesn't work, the box >> >> >> > hangs after the IOMMU is enabled: >> >> >> > >> >> >> > [...] >> >> >> > (XEN) [VT-D]d0:PCI: map :3f:13.5 >> >> >> > (XEN) [VT-D]d0:PCI: map :3f:13.6 >> >> >> > (XEN) [VT-D]iommu_enable_translation: iommu->reg = 82c00021b000 >> >> >> > >> >> >> > I will park this ATM and leave it for the Intel guys to diagnose. >> >> >> > >> >> >> > For the reference, the specific box I'm testing ATM has a Xeon(R) CPU >> >> >> > E5-1607 0 @ 3.00GHz and a C600/X79 chipset. >> >> >> > >> >> >> >> >> >> +Chao who can help check whether we have such a box at hand. >> >> >> >> >> >> btw please also give your BIOS version. >> >> > >> >> >It's a Precision T3600 BIOS A14. >> >> >> >> Hi, Roger. >> >> >> >> I found a Ivy bridge box with E5-2697 v2 and tested with "dom0=pvh", and >> > >> >The ones I've seen issues with are Sandy Bridge or Nehalem, can you >> >find some of this hardware? >> >> As I expected, I was removed from recipents :(, which made me >> hard to notice your replies in time. > >Sorry, I have no idea why my MUA does that, it seems to be able to >deal fine with other recipients. > >> Yes. I will. But may take some time (for even Ivy Bridge is rare). >> >> > >> >I haven't tested Ivy Bridge, but all Haswell boxes I've tested seem to >> >work just fine. >> >> The reason why I chose Ivy Bridge partly is you said you found this bug on >> almost pre-haswell box. > >I tested Nehalem, Sandy Bridge and Haswell, but sadly not Ivy Bridge >(in fact I didn't even know about Ivy Bridge, that's why I said all >pre-Haswell). > >In fact I'm now trying with a Nehalem processor that seem to work, so >whatever this issue is it certainly doesn't affect all models or >chipsets. Hi, Roger. Last week, I borrowed a Sandy Bridge with Intel(R) Xeon(R) E5-2690 2.7GHz and tested with 'dom0=pvh'. But I didn't see the machine hang. I also tested on Haswell and found RMRRs in dmar are incorre
[Xen-devel] [PATCH v1 05/14] x86/np2m: add np2m_generation
Add np2m_generation element to both p2m_domain and nestedvcpu. np2m's generation will be incremented each time the np2m is flushed. This will allow to detect if a nested vcpu has the stale np2m. Signed-off-by: Sergey Dyasli --- xen/arch/x86/hvm/nestedhvm.c | 1 + xen/arch/x86/mm/p2m.c | 3 +++ xen/include/asm-x86/hvm/vcpu.h | 1 + xen/include/asm-x86/p2m.h | 1 + 4 files changed, 6 insertions(+) diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c index f2f7469d86..32b8acca6a 100644 --- a/xen/arch/x86/hvm/nestedhvm.c +++ b/xen/arch/x86/hvm/nestedhvm.c @@ -56,6 +56,7 @@ nestedhvm_vcpu_reset(struct vcpu *v) nv->nv_vvmcxaddr = INVALID_PADDR; nv->nv_flushp2m = 0; nv->nv_p2m = NULL; +nv->np2m_generation = 0; hvm_asid_flush_vcpu_asid(&nv->nv_n2asid); diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index b735950349..2999b858e4 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -73,6 +73,7 @@ static int p2m_initialise(struct domain *d, struct p2m_domain *p2m) p2m->p2m_class = p2m_host; p2m->np2m_base = P2M_BASE_EADDR; +p2m->np2m_generation = 0; for ( i = 0; i < ARRAY_SIZE(p2m->pod.mrp.list); ++i ) p2m->pod.mrp.list[i] = gfn_x(INVALID_GFN); @@ -1732,6 +1733,7 @@ p2m_flush_table_locked(struct p2m_domain *p2m) /* This is no longer a valid nested p2m for any address space */ p2m->np2m_base = P2M_BASE_EADDR; +p2m->np2m_generation++; /* Make sure nobody else is using this p2m table */ nestedhvm_vmcx_flushtlb(p2m); @@ -1806,6 +1808,7 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m) nv->nv_flushp2m = 0; nv->nv_p2m = p2m; +nv->np2m_generation = p2m->np2m_generation; cpumask_set_cpu(v->processor, p2m->dirty_cpumask); } diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h index 6c54773f1c..91651581db 100644 --- a/xen/include/asm-x86/hvm/vcpu.h +++ b/xen/include/asm-x86/hvm/vcpu.h @@ -115,6 +115,7 @@ struct nestedvcpu { bool_t nv_flushp2m; /* True, when p2m table must be flushed */ struct p2m_domain *nv_p2m; /* used p2m table for this vcpu */ +uint64_t np2m_generation; struct hvm_vcpu_asid nv_n2asid; diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h index 1d17fd5f97..1a7002cbcd 100644 --- a/xen/include/asm-x86/p2m.h +++ b/xen/include/asm-x86/p2m.h @@ -209,6 +209,7 @@ struct p2m_domain { * to set it to any other value. */ #define P2M_BASE_EADDR (~0ULL) uint64_t np2m_base; +uint64_t np2m_generation; /* Nested p2ms: linked list of n2pms allocated to this domain. * The host p2m hasolds the head of the list and the np2ms are -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 07/14] x86/vvmx: restart nested vmentry in case of stale_np2m
If an IPI flushes vCPU's np2m object just before nested vmentry, there will be a stale shadow EPTP value in VMCS02. Allow vmentry to be restarted in such cases and add nvmx_eptp_update() to perform an update. Signed-off-by: Sergey Dyasli --- xen/arch/x86/hvm/vmx/entry.S | 6 ++ xen/arch/x86/hvm/vmx/vmx.c | 8 +++- xen/arch/x86/hvm/vmx/vvmx.c | 14 ++ 3 files changed, 27 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S index 53eedc6363..9fb8f89220 100644 --- a/xen/arch/x86/hvm/vmx/entry.S +++ b/xen/arch/x86/hvm/vmx/entry.S @@ -79,6 +79,8 @@ UNLIKELY_END(realmode) mov %rsp,%rdi call vmx_vmenter_helper +cmp $0,%eax +jne .Lvmx_vmentry_restart mov VCPU_hvm_guest_cr2(%rbx),%rax pop %r15 @@ -117,6 +119,10 @@ ENTRY(vmx_asm_do_vmentry) GET_CURRENT(bx) jmp .Lvmx_do_vmentry +.Lvmx_vmentry_restart: +sti +jmp .Lvmx_do_vmentry + .Lvmx_goto_emulator: sti mov %rsp,%rdi diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index f6da119c9f..06509590b7 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -4223,13 +4223,17 @@ static void lbr_fixup(void) bdw_erratum_bdf14_fixup(); } -void vmx_vmenter_helper(const struct cpu_user_regs *regs) +int vmx_vmenter_helper(const struct cpu_user_regs *regs) { struct vcpu *curr = current; u32 new_asid, old_asid; struct hvm_vcpu_asid *p_asid; bool_t need_flush; +/* Shadow EPTP can't be updated here because irqs are disabled */ + if ( nestedhvm_vcpu_in_guestmode(curr) && vcpu_nestedhvm(curr).stale_np2m ) + return 1; + if ( curr->domain->arch.hvm_domain.pi_ops.do_resume ) curr->domain->arch.hvm_domain.pi_ops.do_resume(curr); @@ -4290,6 +4294,8 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs) __vmwrite(GUEST_RIP,regs->rip); __vmwrite(GUEST_RSP,regs->rsp); __vmwrite(GUEST_RFLAGS, regs->rflags | X86_EFLAGS_MBS); + +return 0; } /* diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index ea2da14489..26ce349c76 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1405,12 +1405,26 @@ static void virtual_vmexit(struct cpu_user_regs *regs) vmsucceed(regs); } +static void nvmx_eptp_update(void) +{ +if ( !nestedhvm_vcpu_in_guestmode(current) || + vcpu_nestedhvm(current).nv_vmexit_pending || + !vcpu_nestedhvm(current).stale_np2m || + !nestedhvm_paging_mode_hap(current) ) +return; + +__vmwrite(EPT_POINTER, get_shadow_eptp(current)); +vcpu_nestedhvm(current).stale_np2m = false; +} + void nvmx_switch_guest(void) { struct vcpu *v = current; struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v); struct cpu_user_regs *regs = guest_cpu_user_regs(); +nvmx_eptp_update(); + /* * A pending IO emulation may still be not finished. In this case, no * virtual vmswitch is allowed. Or else, the following IO emulation will -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 01/14] x86/np2m: refactor p2m_get_nestedp2m()
1. Add a helper function assign_np2m() 2. Remove useless volatile 3. Update function's comment in the header 4. Minor style fixes ('\n' and d) Signed-off-by: Sergey Dyasli --- xen/arch/x86/mm/p2m.c | 31 ++- xen/include/asm-x86/p2m.h | 6 +++--- 2 files changed, 21 insertions(+), 16 deletions(-) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index e8a57d118c..b8c8bba421 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1773,14 +1773,24 @@ p2m_flush_nestedp2m(struct domain *d) p2m_flush_table(d->arch.nested_p2m[i]); } +static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m) +{ +struct nestedvcpu *nv = &vcpu_nestedhvm(v); +struct domain *d = v->domain; + +/* Bring this np2m to the top of the LRU list */ +p2m_getlru_nestedp2m(d, p2m); + +nv->nv_flushp2m = 0; +nv->nv_p2m = p2m; +cpumask_set_cpu(v->processor, p2m->dirty_cpumask); +} + struct p2m_domain * p2m_get_nestedp2m(struct vcpu *v, uint64_t np2m_base) { -/* Use volatile to prevent gcc to cache nv->nv_p2m in a cpu register as - * this may change within the loop by an other (v)cpu. - */ -volatile struct nestedvcpu *nv = &vcpu_nestedhvm(v); -struct domain *d; +struct nestedvcpu *nv = &vcpu_nestedhvm(v); +struct domain *d = v->domain; struct p2m_domain *p2m; /* Mask out low bits; this avoids collisions with P2M_BASE_EADDR */ @@ -1790,7 +1800,6 @@ p2m_get_nestedp2m(struct vcpu *v, uint64_t np2m_base) nv->nv_p2m = NULL; } -d = v->domain; nestedp2m_lock(d); p2m = nv->nv_p2m; if ( p2m ) @@ -1798,15 +1807,13 @@ p2m_get_nestedp2m(struct vcpu *v, uint64_t np2m_base) p2m_lock(p2m); if ( p2m->np2m_base == np2m_base || p2m->np2m_base == P2M_BASE_EADDR ) { -nv->nv_flushp2m = 0; -p2m_getlru_nestedp2m(d, p2m); -nv->nv_p2m = p2m; if ( p2m->np2m_base == P2M_BASE_EADDR ) hvm_asid_flush_vcpu(v); p2m->np2m_base = np2m_base; -cpumask_set_cpu(v->processor, p2m->dirty_cpumask); +assign_np2m(v, p2m); p2m_unlock(p2m); nestedp2m_unlock(d); + return p2m; } p2m_unlock(p2m); @@ -1817,11 +1824,9 @@ p2m_get_nestedp2m(struct vcpu *v, uint64_t np2m_base) p2m = p2m_getlru_nestedp2m(d, NULL); p2m_flush_table(p2m); p2m_lock(p2m); -nv->nv_p2m = p2m; p2m->np2m_base = np2m_base; -nv->nv_flushp2m = 0; hvm_asid_flush_vcpu(v); -cpumask_set_cpu(v->processor, p2m->dirty_cpumask); +assign_np2m(v, p2m); p2m_unlock(p2m); nestedp2m_unlock(d); diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h index 6395e8fd1d..9086bb35dc 100644 --- a/xen/include/asm-x86/p2m.h +++ b/xen/include/asm-x86/p2m.h @@ -359,9 +359,9 @@ struct p2m_domain { /* get host p2m table */ #define p2m_get_hostp2m(d) ((d)->arch.p2m) -/* Get p2m table (re)usable for specified np2m base. - * Automatically destroys and re-initializes a p2m if none found. - * If np2m_base == 0 then v->arch.hvm_vcpu.guest_cr[3] is used. +/* + * Assigns an np2m with the specified np2m_base to the specified vCPU + * and returns that np2m. */ struct p2m_domain *p2m_get_nestedp2m(struct vcpu *v, uint64_t np2m_base); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 08/14] x86/np2m: add np2m_schedule()
np2m maintenance is required for a nested vcpu during scheduling: 1. On schedule-out: clear pCPU's bit in p2m->dirty_cpumask to prevent useless IPIs. 2. On schedule-in: check if np2m is up to date and wasn't flushed. Signed-off-by: Sergey Dyasli --- RFC --> v1: - np2m_schedule() now accepts NP2M_SCHEDLE_IN/OUT xen/arch/x86/mm/p2m.c | 43 +++ xen/include/asm-x86/p2m.h | 5 + 2 files changed, 48 insertions(+) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 053df0c9aa..e5d2fed361 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1875,6 +1875,49 @@ p2m_get_p2m(struct vcpu *v) return p2m_get_nestedp2m(v); } +void np2m_schedule(int dir) +{ +struct nestedvcpu *nv = &vcpu_nestedhvm(current); +struct p2m_domain *p2m; + +ASSERT(dir == NP2M_SCHEDLE_IN || dir == NP2M_SCHEDLE_OUT); + +if ( !nestedhvm_enabled(current->domain) || + !nestedhvm_vcpu_in_guestmode(current) || + !nestedhvm_paging_mode_hap(current) ) +return; + +p2m = nv->nv_p2m; +if ( p2m ) +{ +bool np2m_valid; + +p2m_lock(p2m); +np2m_valid = p2m->np2m_base == nhvm_vcpu_p2m_base(current) && + nv->np2m_generation == p2m->np2m_generation; +if ( dir == NP2M_SCHEDLE_OUT && np2m_valid ) +{ +/* + * The np2m is up to date but this vCPU will no longer use it, + * which means there are no reasons to send a flush IPI. + */ +cpumask_clear_cpu(current->processor, p2m->dirty_cpumask); +} +else if ( dir == NP2M_SCHEDLE_IN ) +{ +if ( !np2m_valid ) +{ +/* This vCPU's np2m was flushed while it was not runnable */ +hvm_asid_flush_core(); +vcpu_nestedhvm(current).nv_p2m = NULL; +} +else +cpumask_set_cpu(current->processor, p2m->dirty_cpumask); +} +p2m_unlock(p2m); +} +} + unsigned long paging_gva_to_gfn(struct vcpu *v, unsigned long va, uint32_t *pfec) diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h index 1a7002cbcd..f873dc4fd9 100644 --- a/xen/include/asm-x86/p2m.h +++ b/xen/include/asm-x86/p2m.h @@ -370,6 +370,11 @@ struct p2m_domain *p2m_get_nestedp2m(struct vcpu *v); */ struct p2m_domain *p2m_get_p2m(struct vcpu *v); +#define NP2M_SCHEDLE_IN 0 +#define NP2M_SCHEDLE_OUT 1 + +void np2m_schedule(int dir); + static inline bool_t p2m_is_hostp2m(const struct p2m_domain *p2m) { return p2m->p2m_class == p2m_host; -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 09/14] x86/np2m: add p2m_get_nestedp2m_locked()
The new function returns still write-locked np2m. Signed-off-by: Sergey Dyasli --- xen/arch/x86/mm/p2m.c | 12 +--- xen/include/asm-x86/p2m.h | 2 ++ 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index e5d2fed361..15dedef33b 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1819,7 +1819,7 @@ static void nvcpu_flush(struct vcpu *v) } struct p2m_domain * -p2m_get_nestedp2m(struct vcpu *v) +p2m_get_nestedp2m_locked(struct vcpu *v) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); struct domain *d = v->domain; @@ -1844,7 +1844,6 @@ p2m_get_nestedp2m(struct vcpu *v) nvcpu_flush(v); p2m->np2m_base = np2m_base; assign_np2m(v, p2m); -p2m_unlock(p2m); nestedp2m_unlock(d); return p2m; @@ -1860,12 +1859,19 @@ p2m_get_nestedp2m(struct vcpu *v) p2m->np2m_base = np2m_base; nvcpu_flush(v); assign_np2m(v, p2m); -p2m_unlock(p2m); nestedp2m_unlock(d); return p2m; } +struct p2m_domain *p2m_get_nestedp2m(struct vcpu *v) +{ +struct p2m_domain *p2m = p2m_get_nestedp2m_locked(v); +p2m_unlock(p2m); + +return p2m; +} + struct p2m_domain * p2m_get_p2m(struct vcpu *v) { diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h index f873dc4fd9..790635ec0b 100644 --- a/xen/include/asm-x86/p2m.h +++ b/xen/include/asm-x86/p2m.h @@ -364,6 +364,8 @@ struct p2m_domain { * Updates vCPU's n2pm to match its np2m_base in VMCX12 and returns that np2m. */ struct p2m_domain *p2m_get_nestedp2m(struct vcpu *v); +/* Similar to the above except that returned p2m is still write-locked */ +struct p2m_domain *p2m_get_nestedp2m_locked(struct vcpu *v); /* If vcpu is in host mode then behaviour matches p2m_get_hostp2m(). * If vcpu is in guest mode then behaviour matches p2m_get_nestedp2m(). -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 06/14] x86/np2m: add stale_np2m flag
The new element will indicate if update of a shadow p2m_base is needed prior to vmentry. Update is required if a nested vcpu gets a new np2m or if its np2m was flushed by an IPI. Add nvcpu_flush() helper function. Signed-off-by: Sergey Dyasli --- xen/arch/x86/hvm/nestedhvm.c | 2 ++ xen/arch/x86/mm/p2m.c | 10 -- xen/include/asm-x86/hvm/vcpu.h | 1 + 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c index 32b8acca6a..5b012568c4 100644 --- a/xen/arch/x86/hvm/nestedhvm.c +++ b/xen/arch/x86/hvm/nestedhvm.c @@ -57,6 +57,7 @@ nestedhvm_vcpu_reset(struct vcpu *v) nv->nv_flushp2m = 0; nv->nv_p2m = NULL; nv->np2m_generation = 0; +nv->stale_np2m = false; hvm_asid_flush_vcpu_asid(&nv->nv_n2asid); @@ -108,6 +109,7 @@ nestedhvm_flushtlb_ipi(void *info) */ hvm_asid_flush_core(); vcpu_nestedhvm(v).nv_p2m = NULL; +vcpu_nestedhvm(v).stale_np2m = true; } void diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 2999b858e4..053df0c9aa 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1812,6 +1812,12 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m) cpumask_set_cpu(v->processor, p2m->dirty_cpumask); } +static void nvcpu_flush(struct vcpu *v) +{ +hvm_asid_flush_vcpu(v); +vcpu_nestedhvm(v).stale_np2m = true; +} + struct p2m_domain * p2m_get_nestedp2m(struct vcpu *v) { @@ -1835,7 +1841,7 @@ p2m_get_nestedp2m(struct vcpu *v) if ( p2m->np2m_base == np2m_base || p2m->np2m_base == P2M_BASE_EADDR ) { if ( p2m->np2m_base == P2M_BASE_EADDR ) -hvm_asid_flush_vcpu(v); +nvcpu_flush(v); p2m->np2m_base = np2m_base; assign_np2m(v, p2m); p2m_unlock(p2m); @@ -1852,7 +1858,7 @@ p2m_get_nestedp2m(struct vcpu *v) p2m_flush_table(p2m); p2m_lock(p2m); p2m->np2m_base = np2m_base; -hvm_asid_flush_vcpu(v); +nvcpu_flush(v); assign_np2m(v, p2m); p2m_unlock(p2m); nestedp2m_unlock(d); diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h index 91651581db..16af97942f 100644 --- a/xen/include/asm-x86/hvm/vcpu.h +++ b/xen/include/asm-x86/hvm/vcpu.h @@ -116,6 +116,7 @@ struct nestedvcpu { bool_t nv_flushp2m; /* True, when p2m table must be flushed */ struct p2m_domain *nv_p2m; /* used p2m table for this vcpu */ uint64_t np2m_generation; +bool stale_np2m; /* True when p2m_base in VMCX02 is no longer valid */ struct hvm_vcpu_asid nv_n2asid; -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 02/14] x86/np2m: add np2m_flush_base()
The new function finds all np2m objects with the specified np2m_base and flushes them. Convert p2m_flush_table() into p2m_flush_table_locked() in order not to release the p2m_lock after np2m_base check. Signed-off-by: Sergey Dyasli --- RFC --> v1: - p2m_unlock(p2m) is moved from p2m_flush_table_locked() to p2m_flush_table() for balanced lock/unlock - np2m_flush_eptp() is renamed to np2m_flush_base() xen/arch/x86/mm/p2m.c | 35 +-- xen/include/asm-x86/p2m.h | 2 ++ 2 files changed, 31 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index b8c8bba421..94a42400ad 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1708,15 +1708,14 @@ p2m_getlru_nestedp2m(struct domain *d, struct p2m_domain *p2m) return p2m; } -/* Reset this p2m table to be empty */ static void -p2m_flush_table(struct p2m_domain *p2m) +p2m_flush_table_locked(struct p2m_domain *p2m) { struct page_info *top, *pg; struct domain *d = p2m->domain; mfn_t mfn; -p2m_lock(p2m); +ASSERT(p2m_locked_by_me(p2m)); /* * "Host" p2m tables can have shared entries &c that need a bit more care @@ -1729,10 +1728,7 @@ p2m_flush_table(struct p2m_domain *p2m) /* No need to flush if it's already empty */ if ( p2m_is_nestedp2m(p2m) && p2m->np2m_base == P2M_BASE_EADDR ) -{ -p2m_unlock(p2m); return; -} /* This is no longer a valid nested p2m for any address space */ p2m->np2m_base = P2M_BASE_EADDR; @@ -1752,7 +1748,14 @@ p2m_flush_table(struct p2m_domain *p2m) d->arch.paging.free_page(d, pg); } page_list_add(top, &p2m->pages); +} +/* Reset this p2m table to be empty */ +static void +p2m_flush_table(struct p2m_domain *p2m) +{ +p2m_lock(p2m); +p2m_flush_table_locked(p2m); p2m_unlock(p2m); } @@ -1773,6 +1776,26 @@ p2m_flush_nestedp2m(struct domain *d) p2m_flush_table(d->arch.nested_p2m[i]); } +void np2m_flush_base(struct vcpu *v, unsigned long np2m_base) +{ +struct domain *d = v->domain; +struct p2m_domain *p2m; +unsigned int i; + +np2m_base &= ~(0xfffull); + +nestedp2m_lock(d); +for ( i = 0; i < MAX_NESTEDP2M; i++ ) +{ +p2m = d->arch.nested_p2m[i]; +p2m_lock(p2m); +if ( p2m->np2m_base == np2m_base ) +p2m_flush_table_locked(p2m); +p2m_unlock(p2m); +} +nestedp2m_unlock(d); +} + static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h index 9086bb35dc..cfb00591cd 100644 --- a/xen/include/asm-x86/p2m.h +++ b/xen/include/asm-x86/p2m.h @@ -779,6 +779,8 @@ int p2m_pt_handle_deferred_changes(uint64_t gpa); void p2m_flush(struct vcpu *v, struct p2m_domain *p2m); /* Flushes all nested p2m tables */ void p2m_flush_nestedp2m(struct domain *d); +/* Flushes all np2m objects with the specified np2m_base */ +void np2m_flush_base(struct vcpu *v, unsigned long np2m_base); void nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p, l1_pgentry_t new, unsigned int level); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 04/14] x86/np2m: remove np2m_base from p2m_get_nestedp2m()
Remove np2m_base parameter as it should always match the value of np2m_base in VMCX12. Signed-off-by: Sergey Dyasli --- RFC --> v1: - Nested SVM: added early update of ns_vmcb_hostcr3 xen/arch/x86/hvm/svm/nestedsvm.c | 6 +- xen/arch/x86/hvm/vmx/vvmx.c | 3 +-- xen/arch/x86/mm/hap/nested_hap.c | 2 +- xen/arch/x86/mm/p2m.c| 8 xen/include/asm-x86/p2m.h| 5 ++--- 5 files changed, 13 insertions(+), 11 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 8fd9c23a02..629d5ea497 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -411,7 +411,11 @@ static void nestedsvm_vmcb_set_nestedp2m(struct vcpu *v, ASSERT(v != NULL); ASSERT(vvmcb != NULL); ASSERT(n2vmcb != NULL); -p2m = p2m_get_nestedp2m(v, vvmcb->_h_cr3); + +/* This will allow nsvm_vcpu_hostcr3() to return correct np2m_base */ +vcpu_nestedsvm(v).ns_vmcb_hostcr3 = vvmcb->_h_cr3; + +p2m = p2m_get_nestedp2m(v); n2vmcb->_h_cr3 = pagetable_get_paddr(p2m_get_pagetable(p2m)); } diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 3c5f560aec..ea2da14489 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1109,8 +1109,7 @@ static void load_shadow_guest_state(struct vcpu *v) uint64_t get_shadow_eptp(struct vcpu *v) { -uint64_t np2m_base = nvmx_vcpu_eptp_base(v); -struct p2m_domain *p2m = p2m_get_nestedp2m(v, np2m_base); +struct p2m_domain *p2m = p2m_get_nestedp2m(v); struct ept_data *ept = &p2m->ept; ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m)); diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c index 162afed46b..ed137fa784 100644 --- a/xen/arch/x86/mm/hap/nested_hap.c +++ b/xen/arch/x86/mm/hap/nested_hap.c @@ -212,7 +212,7 @@ nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t *L2_gpa, uint8_t p2ma_21 = p2m_access_rwx; p2m = p2m_get_hostp2m(d); /* L0 p2m */ -nested_p2m = p2m_get_nestedp2m(v, nhvm_vcpu_p2m_base(v)); +nested_p2m = p2m_get_nestedp2m(v); /* walk the L1 P2M table */ rv = nestedhap_walk_L1_p2m(v, *L2_gpa, &L1_gpa, &page_order_21, &p2ma_21, diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 94a42400ad..b735950349 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1810,11 +1810,12 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m) } struct p2m_domain * -p2m_get_nestedp2m(struct vcpu *v, uint64_t np2m_base) +p2m_get_nestedp2m(struct vcpu *v) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); struct domain *d = v->domain; struct p2m_domain *p2m; +uint64_t np2m_base = nhvm_vcpu_p2m_base(v); /* Mask out low bits; this avoids collisions with P2M_BASE_EADDR */ np2m_base &= ~(0xfffull); @@ -1862,7 +1863,7 @@ p2m_get_p2m(struct vcpu *v) if (!nestedhvm_is_n2(v)) return p2m_get_hostp2m(v->domain); -return p2m_get_nestedp2m(v, nhvm_vcpu_p2m_base(v)); +return p2m_get_nestedp2m(v); } unsigned long paging_gva_to_gfn(struct vcpu *v, @@ -1877,13 +1878,12 @@ unsigned long paging_gva_to_gfn(struct vcpu *v, unsigned long l2_gfn, l1_gfn; struct p2m_domain *p2m; const struct paging_mode *mode; -uint64_t np2m_base = nhvm_vcpu_p2m_base(v); uint8_t l1_p2ma; unsigned int l1_page_order; int rv; /* translate l2 guest va into l2 guest gfn */ -p2m = p2m_get_nestedp2m(v, np2m_base); +p2m = p2m_get_nestedp2m(v); mode = paging_get_nestedmode(v); l2_gfn = mode->gva_to_gfn(v, p2m, va, pfec); diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h index cfb00591cd..1d17fd5f97 100644 --- a/xen/include/asm-x86/p2m.h +++ b/xen/include/asm-x86/p2m.h @@ -360,10 +360,9 @@ struct p2m_domain { #define p2m_get_hostp2m(d) ((d)->arch.p2m) /* - * Assigns an np2m with the specified np2m_base to the specified vCPU - * and returns that np2m. + * Updates vCPU's n2pm to match its np2m_base in VMCX12 and returns that np2m. */ -struct p2m_domain *p2m_get_nestedp2m(struct vcpu *v, uint64_t np2m_base); +struct p2m_domain *p2m_get_nestedp2m(struct vcpu *v); /* If vcpu is in host mode then behaviour matches p2m_get_hostp2m(). * If vcpu is in guest mode then behaviour matches p2m_get_nestedp2m(). -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 03/14] x86/vvmx: use np2m_flush_base() for INVEPT_SINGLE_CONTEXT
nvmx_handle_invept() updates current's np2m just to flush it. Instead, use the new np2m_flush_base() directly for this purpose. Signed-off-by: Sergey Dyasli --- xen/arch/x86/hvm/vmx/vvmx.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index e2361a1394..3c5f560aec 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1910,12 +1910,7 @@ int nvmx_handle_invept(struct cpu_user_regs *regs) { case INVEPT_SINGLE_CONTEXT: { -struct p2m_domain *p2m = p2m_get_nestedp2m(current, eptp); -if ( p2m ) -{ -p2m_flush(current, p2m); -ept_sync_domain(p2m); -} +np2m_flush_base(current, eptp); break; } case INVEPT_ALL_CONTEXT: -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 00/14] Nested p2m: allow sharing between vCPUs
Nested p2m (shadow EPT) is an object that stores memory address translations from L2 GPA directly to L0 HPA. This is achieved by combining together L1 EPT with L0 EPT during L2 EPT violations. In the usual case, L1 uses the same EPTP value in VMCS12 for all vCPUs of a L2 guest. But unfortunately, in current Xen's implementation, each vCPU has its own n2pm object which cannot be shared with other vCPUs. This leads to the following issues if a nested guest has SMP: 1. There will be multiple np2m objects (1 per nested vCPU) with the same np2m_base (L1 EPTP value in VMCS12). 2. Same EPT violations will be processed independently by each vCPU. 3. Since MAX_NESTEDP2M is defined as 10, if a domain has more than 10 nested vCPUs, performance will be extremely degraded due to constant np2m LRU list thrashing and np2m flushing. This patch series makes it possible to share one np2m object between different vCPUs that have the same np2m_base. Sharing of np2m objects improves scalability of a domain from 10 nested vCPUs to 10 nested guests (with arbitrary number of vCPUs per guest). RFC --> v1: - Some commit messages are updated based on George's comments - Replaced VMX's terminology in common code with HVM's one - Patch "x86/vvmx: add stale_eptp flag" is split into "x86/np2m: add stale_np2m flag" and "x86/vvmx: restart nested vmentry in case of stale_np2m" - Added "x86/np2m: refactor p2m_get_nestedp2m_locked()" patch - I've done some light nested SVM testing and fixed 1 regression (see patch #4) Sergey Dyasli (14): x86/np2m: refactor p2m_get_nestedp2m() x86/np2m: add np2m_flush_base() x86/vvmx: use np2m_flush_base() for INVEPT_SINGLE_CONTEXT x86/np2m: remove np2m_base from p2m_get_nestedp2m() x86/np2m: add np2m_generation x86/np2m: add stale_np2m flag x86/vvmx: restart nested vmentry in case of stale_np2m x86/np2m: add np2m_schedule() x86/np2m: add p2m_get_nestedp2m_locked() x86/np2m: improve nestedhvm_hap_nested_page_fault() x86/np2m: implement sharing of np2m between vCPUs x86/np2m: refactor p2m_get_nestedp2m_locked() x86/np2m: add break to np2m_flush_eptp() x86/vvmx: remove EPTP write from ept_handle_violation() xen/arch/x86/domain.c| 2 + xen/arch/x86/hvm/nestedhvm.c | 3 + xen/arch/x86/hvm/svm/nestedsvm.c | 6 +- xen/arch/x86/hvm/vmx/entry.S | 6 ++ xen/arch/x86/hvm/vmx/vmx.c | 14 ++-- xen/arch/x86/hvm/vmx/vvmx.c | 28 +-- xen/arch/x86/mm/hap/nested_hap.c | 29 +++ xen/arch/x86/mm/p2m.c| 174 --- xen/include/asm-x86/hvm/vcpu.h | 2 + xen/include/asm-x86/p2m.h| 17 +++- 10 files changed, 211 insertions(+), 70 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 10/14] x86/np2m: improve nestedhvm_hap_nested_page_fault()
There is a possibility for nested_p2m to became stale between nestedhvm_hap_nested_page_fault() and nestedhap_fix_p2m(). Simply use p2m_get_nestedp2m_lock() to guarantee that correct np2m is used. Signed-off-by: Sergey Dyasli --- xen/arch/x86/mm/hap/nested_hap.c | 29 +++-- 1 file changed, 11 insertions(+), 18 deletions(-) diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c index ed137fa784..96afe632b5 100644 --- a/xen/arch/x86/mm/hap/nested_hap.c +++ b/xen/arch/x86/mm/hap/nested_hap.c @@ -101,28 +101,21 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m, unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma) { int rc = 0; +unsigned long gfn, mask; +mfn_t mfn; + ASSERT(p2m); ASSERT(p2m->set_entry); +ASSERT(p2m_locked_by_me(p2m)); -p2m_lock(p2m); - -/* If this p2m table has been flushed or recycled under our feet, - * leave it alone. We'll pick up the right one as we try to - * vmenter the guest. */ -if ( p2m->np2m_base == nhvm_vcpu_p2m_base(v) ) -{ -unsigned long gfn, mask; -mfn_t mfn; - -/* If this is a superpage mapping, round down both addresses - * to the start of the superpage. */ -mask = ~((1UL << page_order) - 1); +/* If this is a superpage mapping, round down both addresses + * to the start of the superpage. */ +mask = ~((1UL << page_order) - 1); -gfn = (L2_gpa >> PAGE_SHIFT) & mask; -mfn = _mfn((L0_gpa >> PAGE_SHIFT) & mask); +gfn = (L2_gpa >> PAGE_SHIFT) & mask; +mfn = _mfn((L0_gpa >> PAGE_SHIFT) & mask); -rc = p2m_set_entry(p2m, gfn, mfn, page_order, p2mt, p2ma); -} +rc = p2m_set_entry(p2m, gfn, mfn, page_order, p2mt, p2ma); p2m_unlock(p2m); @@ -212,7 +205,6 @@ nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t *L2_gpa, uint8_t p2ma_21 = p2m_access_rwx; p2m = p2m_get_hostp2m(d); /* L0 p2m */ -nested_p2m = p2m_get_nestedp2m(v); /* walk the L1 P2M table */ rv = nestedhap_walk_L1_p2m(v, *L2_gpa, &L1_gpa, &page_order_21, &p2ma_21, @@ -278,6 +270,7 @@ nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t *L2_gpa, p2ma_10 &= (p2m_access_t)p2ma_21; /* fix p2m_get_pagetable(nested_p2m) */ +nested_p2m = p2m_get_nestedp2m_locked(v); nestedhap_fix_p2m(v, nested_p2m, *L2_gpa, L0_gpa, page_order_20, p2mt_10, p2ma_10); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 11/14] x86/np2m: implement sharing of np2m between vCPUs
Modify p2m_get_nestedp2m() to allow sharing a np2m between multiple vcpus with the same np2m_base (L1 np2m_base value in VMCX12). np2m_schedule() callbacks are added to context_switch() as well as pseudo schedule-out is performed during vvmx's virtual_vmexit(). Signed-off-by: Sergey Dyasli --- xen/arch/x86/domain.c | 2 ++ xen/arch/x86/hvm/vmx/vvmx.c | 4 xen/arch/x86/mm/p2m.c | 29 +++-- 3 files changed, 33 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index dbddc536d3..c8c26dad4e 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1647,6 +1647,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next) { _update_runstate_area(prev); vpmu_switch_from(prev); +np2m_schedule(NP2M_SCHEDLE_OUT); } if ( is_hvm_domain(prevd) && !list_empty(&prev->arch.hvm_vcpu.tm_list) ) @@ -1695,6 +1696,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next) /* Must be done with interrupts enabled */ vpmu_switch_to(next); +np2m_schedule(NP2M_SCHEDLE_IN); } /* Ensure that the vcpu has an up-to-date time base. */ diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 26ce349c76..49733af62b 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1201,6 +1201,7 @@ static void virtual_vmentry(struct cpu_user_regs *regs) /* Setup virtual ETP for L2 guest*/ if ( nestedhvm_paging_mode_hap(v) ) +/* This will setup the initial np2m for the nested vCPU */ __vmwrite(EPT_POINTER, get_shadow_eptp(v)); else __vmwrite(EPT_POINTER, get_host_eptp(v)); @@ -1367,6 +1368,9 @@ static void virtual_vmexit(struct cpu_user_regs *regs) !(v->arch.hvm_vcpu.guest_efer & EFER_LMA) ) shadow_to_vvmcs_bulk(v, ARRAY_SIZE(gpdpte_fields), gpdpte_fields); +/* This will clear current pCPU bit in p2m->dirty_cpumask */ +np2m_schedule(NP2M_SCHEDLE_OUT); + vmx_vmcs_switch(v->arch.hvm_vmx.vmcs_pa, nvcpu->nv_n1vmcx_pa); nestedhvm_vcpu_exit_guestmode(v); diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 15dedef33b..d6a474fa20 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1825,6 +1825,7 @@ p2m_get_nestedp2m_locked(struct vcpu *v) struct domain *d = v->domain; struct p2m_domain *p2m; uint64_t np2m_base = nhvm_vcpu_p2m_base(v); +unsigned int i; /* Mask out low bits; this avoids collisions with P2M_BASE_EADDR */ np2m_base &= ~(0xfffull); @@ -1838,10 +1839,34 @@ p2m_get_nestedp2m_locked(struct vcpu *v) if ( p2m ) { p2m_lock(p2m); -if ( p2m->np2m_base == np2m_base || p2m->np2m_base == P2M_BASE_EADDR ) +if ( p2m->np2m_base == np2m_base ) { -if ( p2m->np2m_base == P2M_BASE_EADDR ) +/* Check if np2m was flushed just before the lock */ +if ( nv->np2m_generation != p2m->np2m_generation ) nvcpu_flush(v); +/* np2m is up-to-date */ +p2m->np2m_base = np2m_base; +assign_np2m(v, p2m); +nestedp2m_unlock(d); + +return p2m; +} +else if ( p2m->np2m_base != P2M_BASE_EADDR ) +{ +/* vCPU is switching from some other valid np2m */ +cpumask_clear_cpu(v->processor, p2m->dirty_cpumask); +} +p2m_unlock(p2m); +} + +/* Share a np2m if possible */ +for ( i = 0; i < MAX_NESTEDP2M; i++ ) +{ +p2m = d->arch.nested_p2m[i]; +p2m_lock(p2m); +if ( p2m->np2m_base == np2m_base ) +{ +nvcpu_flush(v); p2m->np2m_base = np2m_base; assign_np2m(v, p2m); nestedp2m_unlock(d); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 12/14] x86/np2m: refactor p2m_get_nestedp2m_locked()
Remove some code duplication. Suggested-by: George Dunlap Signed-off-by: Sergey Dyasli --- xen/arch/x86/mm/p2m.c | 25 ++--- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index d6a474fa20..f783f25fa8 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1826,6 +1826,7 @@ p2m_get_nestedp2m_locked(struct vcpu *v) struct p2m_domain *p2m; uint64_t np2m_base = nhvm_vcpu_p2m_base(v); unsigned int i; +bool needs_flush = true; /* Mask out low bits; this avoids collisions with P2M_BASE_EADDR */ np2m_base &= ~(0xfffull); @@ -1842,14 +1843,10 @@ p2m_get_nestedp2m_locked(struct vcpu *v) if ( p2m->np2m_base == np2m_base ) { /* Check if np2m was flushed just before the lock */ -if ( nv->np2m_generation != p2m->np2m_generation ) -nvcpu_flush(v); +if ( nv->np2m_generation == p2m->np2m_generation ) +needs_flush = false; /* np2m is up-to-date */ -p2m->np2m_base = np2m_base; -assign_np2m(v, p2m); -nestedp2m_unlock(d); - -return p2m; +goto found; } else if ( p2m->np2m_base != P2M_BASE_EADDR ) { @@ -1864,15 +1861,10 @@ p2m_get_nestedp2m_locked(struct vcpu *v) { p2m = d->arch.nested_p2m[i]; p2m_lock(p2m); + if ( p2m->np2m_base == np2m_base ) -{ -nvcpu_flush(v); -p2m->np2m_base = np2m_base; -assign_np2m(v, p2m); -nestedp2m_unlock(d); +goto found; -return p2m; -} p2m_unlock(p2m); } @@ -1881,8 +1873,11 @@ p2m_get_nestedp2m_locked(struct vcpu *v) p2m = p2m_getlru_nestedp2m(d, NULL); p2m_flush_table(p2m); p2m_lock(p2m); + + found: +if ( needs_flush ) +nvcpu_flush(v); p2m->np2m_base = np2m_base; -nvcpu_flush(v); assign_np2m(v, p2m); nestedp2m_unlock(d); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 13/14] x86/np2m: add break to np2m_flush_eptp()
Now that np2m sharing is implemented, there can be only one np2m object with the same np2m_base. Break from loop if the required np2m was found during np2m_flush_eptp(). Signed-off-by: Sergey Dyasli --- xen/arch/x86/mm/p2m.c | 4 xen/include/asm-x86/p2m.h | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index f783f25fa8..f11355b0d1 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1792,7 +1792,11 @@ void np2m_flush_base(struct vcpu *v, unsigned long np2m_base) p2m = d->arch.nested_p2m[i]; p2m_lock(p2m); if ( p2m->np2m_base == np2m_base ) +{ p2m_flush_table_locked(p2m); +p2m_unlock(p2m); +break; +} p2m_unlock(p2m); } nestedp2m_unlock(d); diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h index 790635ec0b..a17e589c07 100644 --- a/xen/include/asm-x86/p2m.h +++ b/xen/include/asm-x86/p2m.h @@ -786,7 +786,7 @@ int p2m_pt_handle_deferred_changes(uint64_t gpa); void p2m_flush(struct vcpu *v, struct p2m_domain *p2m); /* Flushes all nested p2m tables */ void p2m_flush_nestedp2m(struct domain *d); -/* Flushes all np2m objects with the specified np2m_base */ +/* Flushes the np2m specified by np2m_base (if it exists) */ void np2m_flush_base(struct vcpu *v, unsigned long np2m_base); void nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header
On 03/09/17 10:38, Nicolas Iooss wrote: > Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until > shared_info is initialized") moved xen_init_time_ops() from __init to > __ref without updating xen-ops.h accordingly. Fix this. > > Fixes: d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until > shared_info is initialized") > Signed-off-by: Nicolas Iooss > --- > arch/x86/xen/xen-ops.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h > index 0d5004477db6..b2a5d48a2c2a 100644 > --- a/arch/x86/xen/xen-ops.h > +++ b/arch/x86/xen/xen-ops.h > @@ -69,7 +69,7 @@ void xen_setup_runstate_info(int cpu); > void xen_teardown_timer(int cpu); > u64 xen_clocksource_read(void); > void xen_setup_cpu_clockevents(void); > -void __init xen_init_time_ops(void); > +void __ref xen_init_time_ops(void); > void __init xen_hvm_init_time_ops(void); When correcting this could you please modify the prototypes to comply to the intended form as noted in include/linux/init.h (the __ref or __init annotations should be just before the ending semicolon)? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 14/14] x86/vvmx: remove EPTP write from ept_handle_violation()
Now there is no need to update shadow EPTP after handling L2 EPT violation since all EPTP updates are handled by nvmx_eptp_update(). Signed-off-by: Sergey Dyasli --- xen/arch/x86/hvm/vmx/vmx.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 06509590b7..6a2553cc58 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3269,12 +3269,6 @@ static void ept_handle_violation(ept_qual_t q, paddr_t gpa) case 0: // Unhandled L1 EPT violation break; case 1: // This violation is handled completly -/*Current nested EPT maybe flushed by other vcpus, so need - * to re-set its shadow EPTP pointer. - */ -if ( nestedhvm_vcpu_in_guestmode(current) && -nestedhvm_paging_mode_hap(current ) ) -__vmwrite(EPT_POINTER, get_shadow_eptp(current)); return; case -1:// This vioaltion should be injected to L1 VMM vcpu_nestedhvm(current).nv_vmexit_pending = 1; -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH V2 4/4] xl/libacpi: extend lapic_id() to uint32_t
On Fri, Sep 01, 2017 at 04:41:48PM +0100, Wei Liu wrote: > On Thu, Aug 31, 2017 at 01:01:49AM -0400, Lan Tianyu wrote: > > From: Chao Gao > > > > This patch is to extend lapic_id() to support more vcpus. > > > > Signed-off-by: Chao Gao > > Signed-off-by: Lan Tianyu > > Acked-by: Wei Liu > > Please remember to pick up my ack next time around -- I believed I > already acked this in the previous version. No, my memory messed up, I didn't actually give my ack. Sorry for the noise. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-sid test] 72058: regressions - trouble: blocked/broken/fail/pass
flight 72058 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72058/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-armhf-sid-netboot-pygrub 7 xen-boot fail REGR. vs. 72031 test-amd64-amd64-i386-sid-netboot-pygrub 11 guest-start fail REGR. vs. 72031 Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a build-arm64-pvops 2 hosts-allocate broken like 72031 build-arm64 2 hosts-allocate broken like 72031 build-arm64-pvops 3 capture-logs broken like 72031 build-arm64 3 capture-logs broken like 72031 test-amd64-i386-i386-sid-netboot-pvgrub 11 guest-start fail like 72031 test-amd64-amd64-amd64-sid-netboot-pvgrub 11 guest-start fail like 72031 baseline version: flight 72031 jobs: build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub fail test-amd64-i386-amd64-sid-netboot-pygrub pass test-arm64-arm64-armhf-sid-netboot-pygrubblocked test-armhf-armhf-armhf-sid-netboot-pygrubfail test-amd64-amd64-i386-sid-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: add arch specific public headers to arch file groups
On Fri, Sep 01, 2017 at 04:45:12AM -0600, Jan Beulich wrote: > I've recently got sufficiently annoyed by people not applying enough > common sense to get_maintainer.pl output, Cc-ing all REST maintainers > on ARM-only public interface changes. > > Sort ARM's xen/ groups of path specifications at the same time. > > Signed-off-by: Jan Beulich I tried to apply this patch from a downloaded maildir but it got rejected. I manually committed the changes, copied the commit message over and pushed it, but it turns out I forgot to change the authorship to you. I hope you don't mind. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build
>>> On 01.09.17 at 19:04, wrote: > Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): >> On 01.09.17 at 17:28, wrote: >> > Do you mean parallel build in which two makes enter libxl? Is that >> > possible? >> >> No, only a single entry into that subtree. > > Are you sure ? Yes. >> > Why does libacpi matter? All dependencies files (*.o.d) should be local >> > to libxl anyway. >> >> Did you check? My .build.o.d has: > > AFAICT you must mean tools/firmware/hvmloader/.build.o.d ? No, I mean the libxl instance of the file (remember that the same libacpi source file is being compiled twice). The hvmloader instance looks similar, but doesn't cause the same problem (because there are no auto-generated headers). >> build.o: \ >> /build/xen/unstable-hg/2017-08-10/tools/libxl/../../tools/libacpi/build.c \ >> /build/xen/unstable-hg/2017-08-10/tools/libxl/../../tools/config.h \ >> /build/xen/unstable-hg/2017-08-10/tools/libxl/libxl_x86_acpi.h \ >> [...] >> _libxl_list.h \ >> /build/xen/unstable-hg/2017-08-10/tools/libxl/_libxl_types.h \ >> libxl_event.h libxl.h \ >> [...] >> >> and it is this non-local _libxl_types.h dependency which breaks >> things. I've noted this with gcc 4.3.x, in case that matters (e.g. >> if newer compilers are smarter in how they write out deps). > > This suggests that perhaps the problem is that something is reentering > libxl. Again, I've verified (multiple times) that this is not the case, as I too did initially suspect this to be what is happening. > With recursive make, it is necessary for the overall structure of the > makefiles to sequence things so that each directory is entered exactly > once, before its dependent directories are entered. (It is possible > to violate this rule without creating races but it is tricky and > inadvisable.) I understand that. > Can you provide a complete log of a failing build ? With the above, is that really needed? And if so, do you mean just normal make output, or output from additionally passing -p. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 08/15] tools: create general interfaces to support psr allocation features
On Mon, Sep 04, 2017 at 10:09:48AM +0800, Yi Sun wrote: > On 17-08-31 09:37:45, Roger Pau Monn� wrote: > > On Thu, Aug 31, 2017 at 10:38:46AM +0800, Yi Sun wrote: > > > On 17-08-30 09:42:56, Roger Pau Monn� wrote: > > > > On Thu, Aug 24, 2017 at 09:14:42AM +0800, Yi Sun wrote: > > > > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > > > > > index 6e80d36..ab847f8 100644 > > > > > --- a/tools/libxl/libxl_types.idl > > > > > +++ b/tools/libxl/libxl_types.idl > > > > > @@ -977,6 +977,7 @@ libxl_psr_cbm_type = Enumeration("psr_cbm_type", [ > > > > > (2, "L3_CBM_CODE"), > > > > > (3, "L3_CBM_DATA"), > > > > > (4, "L2_CBM"), > > > > > +(5, "MBA_THRTL"), > > > > > > > > Is this really a CBM type? > > > > > > > This is not CBM type. The 'libxl_psr_cbm_type' name is not good enough. > > > But I > > > have to introduce a new generic interface here if we want to make the > > > name be > > > generic. I think it is not so valuable. So, I reuse the > > > 'libxl_psr_cbm_type' > > > to cover MBA. How do you think? > > > > Maybe you could introduce a new typedef, so that old code call still > > work, ie: > > > > typedef enum libxl_psr_cbm_type libxl_psr_type; > > > Is there a way in '.idl' to make such 'typedef'? Thanks! > No (or not yet?). Please do it in libxl.h. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass
On 09/02/2017 04:39 PM, Julien Grall wrote: > Hi, > > Sorry for the late reply and formatting, writing from my phone. > > On Wed, 30 Aug 2017, 15:17 George Dunlap wrote: > >> On 08/30/2017 02:54 PM, Andrew Cooper wrote: >>> On 30/08/17 14:49, osstest service owner wrote: flight 112957 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112957/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 12 guest-start fail REGR. >> vs. 112956 >>> >>> (XEN) Assertion 'cpu == smp_processor_id()' failed at softirq.c:35 >>> (XEN) [ Xen-4.10-unstable arm32 debug=y Not tainted ] >>> (XEN) CPU:1 >>> (XEN) PC: 0023b710 softirq.c#__do_softirq+0x3c/0x134 >>> (XEN) CPSR: 805a MODE:Hypervisor >>> (XEN) R0: 4003d000 R1: 0001 R2: 3fcffd00 R3: 0001 >>> (XEN) R4: 002e5f74 R5: R6: 0031d694 R7: 0031a224 >>> (XEN) R8: 002e1f80 R9: 0029b880 R10:0001 R11:40037f3c >> R12: >>> (XEN) HYP: SP: 40037f04 LR: 0025826c >>> (XEN) >>> (XEN) VTCR_EL2: 80003558 >>> (XEN) VTTBR_EL2: 0001bff1e000 >>> (XEN) >>> (XEN) SCTLR_EL2: 30cd187f >>> (XEN)HCR_EL2: 0038663f >>> (XEN) TTBR0_EL2: ba016000 >>> (XEN) >>> (XEN)ESR_EL2: >>> (XEN) HPFAR_EL2: 00104810 >>> (XEN) HDFAR: df000f00 >>> (XEN) HIFAR: >>> (XEN) >>> (XEN) Xen stack trace from sp=40037f04: >>> (XEN) 0004 002e1f80 002e1f80 0031d694 >> 002e1f80 >>> (XEN)c1203098 0001 c11151a8 40037f44 0023b87c >> 40037f54 >>> (XEN)0026b320 c120 c1203034 40037f58 0026ef40 0001 >> 0001 >>> (XEN)c031c520 c120 c1203034 c1203098 0001 >> c11151a8 >>> (XEN)c12030a0 192b8000 7f5706d3 c031c528 6093 07e0 >> bebcd108 >>> (XEN)c1318ac0 c030d0a0 c1201fa0 c030928c c1318acc c030d420 c1318ad8 >> c030d4e0 >>> (XEN) c1318ae4 c1318ae4 >> 6013 >>> (XEN)60010193 2093 6193 >>> (XEN) Xen call trace: >>> (XEN)[<0023b710>] softirq.c#__do_softirq+0x3c/0x134 (PC) >>> (XEN)[<0025826c>] domain.c#schedule_tail+0x2f4/0x308 (LR) >>> (XEN)[<0023b87c>] do_softirq+0x18/0x28 >>> (XEN)[<0026b320>] leave_hypervisor_tail+0x84/0xb8 >>> (XEN)[<0026ef40>] entry.o#return_to_guest+0xc/0xb8 >>> (XEN) >>> (XEN) >>> (XEN) >>> (XEN) Panic on CPU 1: >>> (XEN) Assertion 'cpu == smp_processor_id()' failed at softirq.c:35 >>> (XEN) >>> (XEN) >>> (XEN) Manual reset required ('noreboot' specified) >>> >>> At a guess, I'd say the reasoning behind >>> >> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=57450cfe48b56db90166c52d45a411a9279a12e1 >>> is false. >> >> Wow -- I actually rather doubt that the reasoning is wrong; I can't see >> anywhere in the context switch path that could possibly move the >> hypervisor stack to another processor. I'd be more inclined to suspect >> that smp_processor_id() returns the wrong value under certain conditions >> -- e.g., between a schedule() softirq and the next VMENTER (whatever >> it's called on ARM). >> >> Stefano, any ideas? >> > > If I am not mistaken the hypervisor stack is per-vCPU. So when you move the > vCPU to another pCPU, the stack will be moved. > This means the smp_processor_id() will return a different value. Isn't it > the same on x86? No, the hypervisor stack on x86 has always been per-pcpu. Apparently the powerpc port was per-vcpu, which is why the smp_processor_id() was there. I (and apparently Dario) assumed the ARM implementation was the same as x86, which is why I checked in this change. I guess we'd better leave the patch reverted for now. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] domctl: improve locking during domain destruction
>>> On 01.09.17 at 18:28, wrote: > On 01/09/17 17:18, Jan Beulich wrote: >> There is no need to hold the global domctl lock while across >> domain_kill() - the domain lock is fully sufficient here. >> >> Signed-off-by: Jan Beulich >> --- >> Sadly so far we haven't had any feedback on this change from the people >> who observed an issue apparently resulting from heavy contention here. >> Hence the RFC. >> >> Obviously other domctl-s could benefit from similar adjustments, so >> this is meant to be just a start. > > What is the expected ordering of the global domctl lock and perdomain > domctl locks? I'd expect the domain locks to nest inside the global domctl one, but I wouldn't want to spell this out anywhere until we actually have a case where both need to be acquired (and I would hope such a case to never arise). Or (I didn't check this) maybe we already have cases where the per-domain lock is being acquired with the global domctl one being held, even without this suggested adjustment. > The current uses appear a little ad-hoc. Is there anything we can do to > more strongly enforce the expected behaviour? Expected behavior of what? >> --- a/xen/common/domain.c >> +++ b/xen/common/domain.c >> @@ -619,13 +619,16 @@ int domain_kill(struct domain *d) >> if ( d == current->domain ) >> return -EINVAL; >> >> -/* Protected by domctl_lock. */ >> +/* Protected by d->domain_lock. */ >> switch ( d->is_dying ) >> { >> case DOMDYING_alive: >> +domain_unlock(d); >> domain_pause(d); >> +domain_lock(d); >> +if ( d->is_dying != DOMDYING_alive ) >> +return domain_kill(d); > > Comment about recursion safety? I can certainly add one, albeit in the case here I'm not really convinced it is necessary. Would you be happy with /* * With the domain lock dropped, d->is_dying may have changed. Call * ourselves recursively if so, which is safe as then we won't come * back here. */ ? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] tools: remove unnecessary PSR macros
On Mon, Sep 04, 2017 at 11:08:56AM +0800, Yi Sun wrote: > The libxl interfaces and related functions are not necessary to be included by > 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So remove them. > > Suggested-by: Roger Pau Monné > Signed-off-by: Yi Sun Thinking about this a bit more, it is not that simple. LIBXL_HAVE_PSR_CMT is enclosed by __i386__ and __x86_64__, libxl_psr.o is only built on x86. I'm afraid we do need these macros in libxl and xl otherwise arm build is going to be broken. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0
On Mon, Sep 04, 2017 at 02:25:10PM +0800, Chao Gao wrote: > On Thu, Aug 31, 2017 at 11:09:48AM +0100, Roger Pau Monne wrote: > >I tested Nehalem, Sandy Bridge and Haswell, but sadly not Ivy Bridge > >(in fact I didn't even know about Ivy Bridge, that's why I said all > >pre-Haswell). > > > >In fact I'm now trying with a Nehalem processor that seem to work, so > >whatever this issue is it certainly doesn't affect all models or > >chipsets. > > Hi, Roger. > > Last week, I borrowed a Sandy Bridge with Intel(R) Xeon(R) E5-2690 > 2.7GHz and tested with 'dom0=pvh'. But I didn't see the machine hang. > > I also tested on Haswell and found RMRRs in dmar are incorrect on my > haswell. The e820 on that machine is: > (XEN) [0.00] Xen-e820 RAM map: > (XEN) [0.00] - 0009a400 (usable) > (XEN) [0.00] 0009a400 - 000a (reserved) > (XEN) [0.00] 000e - 0010 (reserved) > (XEN) [0.00] 0010 - 6ff84000 (usable) > (XEN) [0.00] 6ff84000 - 7ac51000 (reserved) > (XEN) [0.00] 7ac51000 - 7b681000 (ACPI NVS) > (XEN) [0.00] 7b681000 - 7b7cf000 (ACPI data) > (XEN) [0.00] 7b7cf000 - 7b80 (usable) > (XEN) [0.00] 7b80 - 9000 (reserved) > (XEN) [0.00] fed1c000 - fed2 (reserved) > (XEN) [0.00] ff40 - 0001 (reserved) > (XEN) [0.00] 0001 - 00208000 (usable) > > And the RMRRs in DMAR are: > (XEN) [0.00] [VT-D]found ACPI_DMAR_RMRR: > (XEN) [0.00] [VT-D] endpoint: :05:00.0 > (XEN) [0.00] [VT-D]dmar.c:638: RMRR region: base_addr 723b4000 > end_addr 7a3f3fff > (XEN) [0.00] [VT-D]found ACPI_DMAR_RMRR: > (XEN) [0.00] [VT-D] endpoint: :00:1d.0 > (XEN) [0.00] [VT-D] endpoint: :00:1a.0 > (XEN) [0.00] [VT-D]dmar.c:638: RMRR region: base_addr 723ac000 > end_addr 723aefff > (Endpoint 05:00.0 is a RAID bus controller. Endpoints 00.1d.0 and 00.1a.0 > are USB controllers.) > > After DMA remapping is enabled, two DMA translation faults are reported > by VT-d: > (XEN) [9.547924] [VT-D]iommu_enable_translation: iommu->reg = > 82c00021b000 > (XEN) [9.550620] [VT-D]iommu_enable_translation: iommu->reg = > 82c00021d000 > (XEN) [9.553327] [VT-D]iommu.c:921: iommu_fault_status: Primary > Pending Fault > (XEN) [9.555906] [VT-D]DMAR:[DMA Read] Request device [:00:1a.0] > fault addr 7a3f5000, iommu reg = 82c00021d000 > (XEN) [9.558537] [VT-D]DMAR: reason 06 - PTE Read access is not set > (XEN) [9.559860] print_vtd_entries: iommu #1 dev :00:1a.0 gmfn > 7a3f5 > (XEN) [9.561179] root_entry[00] = 107277c001 > (XEN) [9.562447] context[d0] = 2_1072c06001 > (XEN) [9.563776] l4[000] = 9c202f171107 > (XEN) [9.565125] l3[001] = 9c202f152107 > (XEN) [9.566483] l2[1d1] = 9c10727ce107 > (XEN) [9.567821] l1[1f5] = 8000 > (XEN) [9.569168] l1[1f5] not present > (XEN) [9.570502] [VT-D]DMAR:[DMA Read] Request device [:00:1d.0] > fault addr 7a3f4000, iommu reg = 82c00021d000 > (XEN) [9.573147] [VT-D]DMAR: reason 06 - PTE Read access is not set > (XEN) [9.574488] print_vtd_entries: iommu #1 dev :00:1d.0 gmfn > 7a3f4 > (XEN) [9.575819] root_entry[00] = 107277c001 > (XEN) [9.577129] context[e8] = 2_1072c06001 > (XEN) [9.578439] l4[000] = 9c202f171107 > (XEN) [9.579778] l3[001] = 9c202f152107 > (XEN) [9.58] l2[1d1] = 9c10727ce107 > (XEN) [9.582482] l1[1f4] = 8000 > (XEN) [9.583812] l1[1f4] not present > (XEN) [ 10.520172] Unable to find XEN_ELFNOTE_PHYS32_ENTRY address > (XEN) [ 10.521499] Failed to load Dom0 kernel > (XEN) [ 10.532171] > (XEN) [ 10.535464] > (XEN) [ 10.542636] Panic on CPU 0: > (XEN) [ 10.547394] Could not set up DOM0 guest OS > (XEN) [ 10.553605] > > The fault address the devices failed to access is marked as reserved in > e820 and isn't reserved for the devices according to the RMRRs in DMAR. > So I think we can draw a conclusion that some existing BIOSs don't > expose correct RMRR to OS by DMAR. And we need a workaround such as > iommu_inclusive_mapping to deal with such kind of BIOS for both pv dom0 > and pvh dom0. So your box seems to be capable of generating faults. Missing RMRR regions is (sadly) expected, but at least you get faults and not a complete hang. Which chipset does this box have? Is it a C600/X79? > > As to the machine hang Roger observed, I have no idea on the cause. Roger, > have you ever seen the VT-d on that machine reporting a DMA > translation fault? If not, can you create one fault in native? I
Re: [Xen-devel] [RFC PATCH V2 2/4] Tool/ACPI: DSDT extension to support more vcpus
On Mon, Sep 04, 2017 at 11:07:14AM +0800, Lan Tianyu wrote: > On 2017年09月01日 17:41, Roger Pau Monné wrote: > > On Fri, Sep 01, 2017 at 10:54:02AM +0800, Lan Tianyu wrote: > >> On 2017年08月31日 23:38, Roger Pau Monné wrote: > >>> On Thu, Aug 31, 2017 at 01:01:47AM -0400, Lan Tianyu wrote: > This patch is to change DSDT table for processor object to support >128 > vcpus > accroding to ACPI spec 8.4 Declaring Processors > > Signed-off-by: Lan Tianyu > --- > tools/libacpi/mk_dsdt.c | 18 -- > 1 file changed, 12 insertions(+), 6 deletions(-) > > diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c > index 2daf32c..6c4c325 100644 > --- a/tools/libacpi/mk_dsdt.c > +++ b/tools/libacpi/mk_dsdt.c > @@ -24,6 +24,8 @@ > #include > #endif > > +#define CPU_NAME_FMT "P%.03X" > + > static unsigned int indent_level; > static bool debug = false; > > @@ -196,10 +198,14 @@ int main(int argc, char **argv) > /* Define processor objects and control methods. */ > for ( cpu = 0; cpu < max_cpus; cpu++) > { > -push_block("Processor", "PR%02X, %d, 0xb010, 0x06", cpu, > cpu); > +unsigned int apic_id = cpu * 2; > >>> > >>> This is fragile, ideally there should be a single point where the APIC > >>> ID is calculated. Although there are already two places where the APIC > >>> ID is calculated, in hvmloader and libxl. > >>> > >>> And I'm not sure how to use any of those here in order to avoid > >>> introducing a third one. > >> > >> The mk_dsdt is independent tool to build dsdt table. It wasn't linked > >> with libxl and hvmloader. We can't reuse old function to do that. > >> > >> But I think we may introduce a new LAPIC_ID(vcpu) in the arch head > >> file(i.e, #include ) and replace old ones. > > > > There's already a LAPIC_ID macro in hvmloader headers which should be > > placed somewhere suitable. > > Yes, this is what I mentioned. Jan has expressed some concerns with removing the hook, see: <59a94e32027800176...@prv-mh.provo.novell.com> > > What about removing the lapic_id hook from > > acpi_config and placing the LAPIC_ID macro in the libacpi.h header? > > I think this should be ARCH specific. I am not sure whether ARM follows > rule of "apic_id = vcpu_id *2". > > Julien, could you give some inputs? Thanks. AFAIK ARM doesn't have a local APIC, so there are no xAPIC/x2APIC entries in the ARM MADT. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: add arch specific public headers to arch file groups
>>> On 04.09.17 at 10:33, wrote: > On Fri, Sep 01, 2017 at 04:45:12AM -0600, Jan Beulich wrote: >> I've recently got sufficiently annoyed by people not applying enough >> common sense to get_maintainer.pl output, Cc-ing all REST maintainers >> on ARM-only public interface changes. >> >> Sort ARM's xen/ groups of path specifications at the same time. >> >> Signed-off-by: Jan Beulich > > I tried to apply this patch from a downloaded maildir but it got > rejected. > > I manually committed the changes, copied the commit message over and > pushed it, but it turns out I forgot to change the authorship to you. I > hope you don't mind. No problem at all - the main thing is that the change is in place. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: use vMSI related #define-s from public interface
>>> On 01.09.17 at 20:20, wrote: > On Fri, Sep 01, 2017 at 10:25:42AM -0600, Jan Beulich wrote: >> Xen and qemu having identical #define-s (with different names) is a >> strong hint that these should have been part of the public interface >> from the very start. Use them if they're available, falling back to >> privately defined values only when using older headers. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Roger Pau Monné Thanks. >> --- a/hw/xen/xen_pt_msi.c >> +++ b/hw/xen/xen_pt_msi.c >> @@ -18,6 +18,11 @@ >> >> #define XEN_PT_AUTO_ASSIGN -1 >> >> +#ifndef XEN_DOMCTL_VMSI_X86_DEST_ID_MASK >> +#if XEN_DOMCTL_INTERFACE_VERSION >= 0x000e > > XEN_DOMCTL_INTERFACE_VERSION is already 0xe (without you added > defines), I guess it doesn't matter much because we only care for > stable releases. Well, that's if you build qemu against master Xen. What about people building against older Xen versions/headers? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] tools: change the type of '*nr' in 'libxl_psr_cat_get_info'
On Fri, Sep 01, 2017 at 08:15:05PM +0800, Yi Sun wrote: > Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info' > is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes > this and does related changes. > > Suggested-by: Roger Pau Monné > Signed-off-by: Yi Sun > --- > - This patch depends on patch 'tools: remove unnecessary PSR macros'. I suppose you want to resend this patch because its dependence should be dropped? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] tools: remove unnecessary PSR macros
On 17-09-04 09:49:40, Wei Liu wrote: > On Mon, Sep 04, 2017 at 11:08:56AM +0800, Yi Sun wrote: > > The libxl interfaces and related functions are not necessary to be included > > by > > 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So remove them. > > > > Suggested-by: Roger Pau Monn? > > Signed-off-by: Yi Sun > > Thinking about this a bit more, it is not that simple. > > LIBXL_HAVE_PSR_CMT is enclosed by __i386__ and __x86_64__, libxl_psr.o > is only built on x86. > > I'm afraid we do need these macros in libxl and xl otherwise arm build > is going to be broken. Good point. Shall we use '#if defined(__i386__) || defined(__x86_64__)' to include all PSR interfaces? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] tools: remove unnecessary PSR macros
On Mon, Sep 04, 2017 at 05:10:21PM +0800, Yi Sun wrote: > On 17-09-04 09:49:40, Wei Liu wrote: > > On Mon, Sep 04, 2017 at 11:08:56AM +0800, Yi Sun wrote: > > > The libxl interfaces and related functions are not necessary to be > > > included by > > > 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So remove them. > > > > > > Suggested-by: Roger Pau Monn? > > > Signed-off-by: Yi Sun > > > > Thinking about this a bit more, it is not that simple. > > > > LIBXL_HAVE_PSR_CMT is enclosed by __i386__ and __x86_64__, libxl_psr.o > > is only built on x86. > > > > I'm afraid we do need these macros in libxl and xl otherwise arm build > > is going to be broken. > > Good point. Shall we use '#if defined(__i386__) || defined(__x86_64__)' to > include all PSR interfaces? Yes. There is no arm counterpart as far as I can tell. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] tools: remove unnecessary PSR macros
On Mon, Sep 04, 2017 at 09:49:40AM +0100, Wei Liu wrote: > On Mon, Sep 04, 2017 at 11:08:56AM +0800, Yi Sun wrote: > > The libxl interfaces and related functions are not necessary to be included > > by > > 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So remove them. > > > > Suggested-by: Roger Pau Monné > > Signed-off-by: Yi Sun > > Thinking about this a bit more, it is not that simple. > > LIBXL_HAVE_PSR_CMT is enclosed by __i386__ and __x86_64__, libxl_psr.o > is only built on x86. > > I'm afraid we do need these macros in libxl and xl otherwise arm build > is going to be broken. OK, I though ARM would have it's own empty stubs. Maybe it would be cleaner to simply don't compile xl_psr on ARM, rather than having a bunch of defines in the file which basically renders it empty when compiled on ARM. In any case, this would not be much better than what we have now, so I guess we should leave it as-is. Sorry for the miss-guidance. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: use vMSI related #define-s from public interface
On Mon, Sep 04, 2017 at 03:04:41AM -0600, Jan Beulich wrote: > >>> On 01.09.17 at 20:20, wrote: > > On Fri, Sep 01, 2017 at 10:25:42AM -0600, Jan Beulich wrote: > >> Xen and qemu having identical #define-s (with different names) is a > >> strong hint that these should have been part of the public interface > >> from the very start. Use them if they're available, falling back to > >> privately defined values only when using older headers. > >> > >> Signed-off-by: Jan Beulich > > > > Reviewed-by: Roger Pau Monné > > Thanks. > > >> --- a/hw/xen/xen_pt_msi.c > >> +++ b/hw/xen/xen_pt_msi.c > >> @@ -18,6 +18,11 @@ > >> > >> #define XEN_PT_AUTO_ASSIGN -1 > >> > >> +#ifndef XEN_DOMCTL_VMSI_X86_DEST_ID_MASK > >> +#if XEN_DOMCTL_INTERFACE_VERSION >= 0x000e > > > > XEN_DOMCTL_INTERFACE_VERSION is already 0xe (without you added > > defines), I guess it doesn't matter much because we only care for > > stable releases. > > Well, that's if you build qemu against master Xen. What about > people building against older Xen versions/headers? Sorry, I think I haven't explained myself clearly. What I mean is that if this change gets committed before the Xen side one, QEMU would not compile against current Xen. As said, this is only a transitory issue, and it's never going to be a problem in stable branches. This is because of the "#error" that you add. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
On 03/09/17 13:01, Tim Deegan wrote: > At 18:07 +0100 on 01 Sep (1504289261), Andrew Cooper wrote: >> if ( unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) ) >> { >> -l4_pgentry_t *next = &l4tab[ROOT_PAGETABLE_FIRST_XEN_SLOT + >> -root_pgt_pv_xen_slots]; >> +/* >> + * If using highmem-start=, artificially shorten the directmap to >> + * simulate very large machines. >> + */ >> +l4_pgentry_t *next; >> + >> +memcpy(&l4t[l4_table_offset(XEN_VIRT_START)], >> + &idle_pg_table[l4_table_offset(XEN_VIRT_START)], >> + (ROOT_PAGETABLE_FIRST_XEN_SLOT + root_pgt_pv_xen_slots - >> +l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); >> + >> +next = &l4t[ROOT_PAGETABLE_FIRST_XEN_SLOT + root_pgt_pv_xen_slots]; >> >> if ( l4e_get_intpte(split_l4e) ) >> *next++ = split_l4e; >> >> memset(next, 0, >> - _p(&l4tab[ROOT_PAGETABLE_LAST_XEN_SLOT + 1]) - _p(next)); >> + _p(&l4t[ROOT_PAGETABLE_LAST_XEN_SLOT + 1]) - _p(next)); >> } >> -#else >> -BUILD_BUG_ON(root_pgt_pv_xen_slots != ROOT_PAGETABLE_PV_XEN_SLOTS); >> +else >> #endif >> -l4tab[l4_table_offset(LINEAR_PT_VIRT_START)] = >> -l4e_from_pfn(domain_page_map_to_mfn(l4tab), __PAGE_HYPERVISOR_RW); >> -l4tab[l4_table_offset(PERDOMAIN_VIRT_START)] = >> -l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); >> -if ( zap_ro_mpt || is_pv_32bit_domain(d) ) >> -l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty(); >> +{ >> +/* >> + * For PV guests, provide the shortened directmap, up to >> PV_XEN_SLOTS. >> + * For HVM guests and the idle vcpus, provide the extended >> directmap. >> + */ >> +unsigned int slots = ((d && !paging_mode_external(d)) >> + ? ROOT_PAGETABLE_PV_XEN_SLOTS >> + : ROOT_PAGETABLE_XEN_SLOTS); >> + >> +memcpy(&l4t[l4_table_offset(XEN_VIRT_START)], >> + &idle_pg_table[l4_table_offset(XEN_VIRT_START)], >> + (ROOT_PAGETABLE_FIRST_XEN_SLOT + slots - >> +l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); > Does this branch need a memset(0) for the PV case, to zap the higher > directmap slots? init_xen_l4_slots() is called after all the guest entries have been validated. Zapping them here will get us into some reference counting fun. :) > > The shadow changes all look fine, so: > Acked-by: Tim Deegan Thanks, ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0
(Adding Chao again because my MUA seems to drop him each time) On Mon, Sep 04, 2017 at 10:00:00AM +0100, Roger Pau Monné wrote: > On Mon, Sep 04, 2017 at 02:25:10PM +0800, Chao Gao wrote: > > On Thu, Aug 31, 2017 at 11:09:48AM +0100, Roger Pau Monne wrote: > > >I tested Nehalem, Sandy Bridge and Haswell, but sadly not Ivy Bridge > > >(in fact I didn't even know about Ivy Bridge, that's why I said all > > >pre-Haswell). > > > > > >In fact I'm now trying with a Nehalem processor that seem to work, so > > >whatever this issue is it certainly doesn't affect all models or > > >chipsets. > > > > Hi, Roger. > > > > Last week, I borrowed a Sandy Bridge with Intel(R) Xeon(R) E5-2690 > > 2.7GHz and tested with 'dom0=pvh'. But I didn't see the machine hang. > > > > I also tested on Haswell and found RMRRs in dmar are incorrect on my > > haswell. The e820 on that machine is: > > (XEN) [0.00] Xen-e820 RAM map: > > (XEN) [0.00] - 0009a400 (usable) > > (XEN) [0.00] 0009a400 - 000a (reserved) > > (XEN) [0.00] 000e - 0010 (reserved) > > (XEN) [0.00] 0010 - 6ff84000 (usable) > > (XEN) [0.00] 6ff84000 - 7ac51000 (reserved) > > (XEN) [0.00] 7ac51000 - 7b681000 (ACPI NVS) > > (XEN) [0.00] 7b681000 - 7b7cf000 (ACPI data) > > (XEN) [0.00] 7b7cf000 - 7b80 (usable) > > (XEN) [0.00] 7b80 - 9000 (reserved) > > (XEN) [0.00] fed1c000 - fed2 (reserved) > > (XEN) [0.00] ff40 - 0001 (reserved) > > (XEN) [0.00] 0001 - 00208000 (usable) > > > > And the RMRRs in DMAR are: > > (XEN) [0.00] [VT-D]found ACPI_DMAR_RMRR: > > (XEN) [0.00] [VT-D] endpoint: :05:00.0 > > (XEN) [0.00] [VT-D]dmar.c:638: RMRR region: base_addr 723b4000 > > end_addr 7a3f3fff > > (XEN) [0.00] [VT-D]found ACPI_DMAR_RMRR: > > (XEN) [0.00] [VT-D] endpoint: :00:1d.0 > > (XEN) [0.00] [VT-D] endpoint: :00:1a.0 > > (XEN) [0.00] [VT-D]dmar.c:638: RMRR region: base_addr 723ac000 > > end_addr 723aefff > > (Endpoint 05:00.0 is a RAID bus controller. Endpoints 00.1d.0 and 00.1a.0 > > are USB controllers.) > > > > After DMA remapping is enabled, two DMA translation faults are reported > > by VT-d: > > (XEN) [9.547924] [VT-D]iommu_enable_translation: iommu->reg = > > 82c00021b000 > > (XEN) [9.550620] [VT-D]iommu_enable_translation: iommu->reg = > > 82c00021d000 > > (XEN) [9.553327] [VT-D]iommu.c:921: iommu_fault_status: Primary > > Pending Fault > > (XEN) [9.555906] [VT-D]DMAR:[DMA Read] Request device [:00:1a.0] > > fault addr 7a3f5000, iommu reg = 82c00021d000 > > (XEN) [9.558537] [VT-D]DMAR: reason 06 - PTE Read access is not set > > (XEN) [9.559860] print_vtd_entries: iommu #1 dev :00:1a.0 gmfn > > 7a3f5 > > (XEN) [9.561179] root_entry[00] = 107277c001 > > (XEN) [9.562447] context[d0] = 2_1072c06001 > > (XEN) [9.563776] l4[000] = 9c202f171107 > > (XEN) [9.565125] l3[001] = 9c202f152107 > > (XEN) [9.566483] l2[1d1] = 9c10727ce107 > > (XEN) [9.567821] l1[1f5] = 8000 > > (XEN) [9.569168] l1[1f5] not present > > (XEN) [9.570502] [VT-D]DMAR:[DMA Read] Request device [:00:1d.0] > > fault addr 7a3f4000, iommu reg = 82c00021d000 > > (XEN) [9.573147] [VT-D]DMAR: reason 06 - PTE Read access is not set > > (XEN) [9.574488] print_vtd_entries: iommu #1 dev :00:1d.0 gmfn > > 7a3f4 > > (XEN) [9.575819] root_entry[00] = 107277c001 > > (XEN) [9.577129] context[e8] = 2_1072c06001 > > (XEN) [9.578439] l4[000] = 9c202f171107 > > (XEN) [9.579778] l3[001] = 9c202f152107 > > (XEN) [9.58] l2[1d1] = 9c10727ce107 > > (XEN) [9.582482] l1[1f4] = 8000 > > (XEN) [9.583812] l1[1f4] not present > > (XEN) [ 10.520172] Unable to find XEN_ELFNOTE_PHYS32_ENTRY address > > (XEN) [ 10.521499] Failed to load Dom0 kernel > > (XEN) [ 10.532171] > > (XEN) [ 10.535464] > > (XEN) [ 10.542636] Panic on CPU 0: > > (XEN) [ 10.547394] Could not set up DOM0 guest OS > > (XEN) [ 10.553605] > > > > The fault address the devices failed to access is marked as reserved in > > e820 and isn't reserved for the devices according to the RMRRs in DMAR. > > So I think we can draw a conclusion that some existing BIOSs don't > > expose correct RMRR to OS by DMAR. And we need a workaround such as > > iommu_inclusive_mapping to deal with such kind of BIOS for both pv dom0 > > and pvh dom0. > > So your box seems to be capable of generating faults. Missing RMRR > regions is (sadly) expected,
Re: [Xen-devel] [PATCH] xen: use vMSI related #define-s from public interface
>>> On 04.09.17 at 11:23, wrote: > On Mon, Sep 04, 2017 at 03:04:41AM -0600, Jan Beulich wrote: >> >>> On 01.09.17 at 20:20, wrote: >> > On Fri, Sep 01, 2017 at 10:25:42AM -0600, Jan Beulich wrote: >> >> Xen and qemu having identical #define-s (with different names) is a >> >> strong hint that these should have been part of the public interface >> >> from the very start. Use them if they're available, falling back to >> >> privately defined values only when using older headers. >> >> >> >> Signed-off-by: Jan Beulich >> > >> > Reviewed-by: Roger Pau Monné >> >> Thanks. >> >> >> --- a/hw/xen/xen_pt_msi.c >> >> +++ b/hw/xen/xen_pt_msi.c >> >> @@ -18,6 +18,11 @@ >> >> >> >> #define XEN_PT_AUTO_ASSIGN -1 >> >> >> >> +#ifndef XEN_DOMCTL_VMSI_X86_DEST_ID_MASK >> >> +#if XEN_DOMCTL_INTERFACE_VERSION >= 0x000e >> > >> > XEN_DOMCTL_INTERFACE_VERSION is already 0xe (without you added >> > defines), I guess it doesn't matter much because we only care for >> > stable releases. >> >> Well, that's if you build qemu against master Xen. What about >> people building against older Xen versions/headers? > > Sorry, I think I haven't explained myself clearly. What I mean is > that if this change gets committed before the Xen side one, QEMU would > not compile against current Xen. As said, this is only a transitory > issue, and it's never going to be a problem in stable branches. This > is because of the "#error" that you add. Oh, yes, that's the case. I can't see an easy way around it, but I'm pretty sure the qemu side of it will see some further delay anyway. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0
On Mon, Sep 04, 2017 at 10:26:04AM +0100, Roger Pau Monné wrote: >(Adding Chao again because my MUA seems to drop him each time) > >On Mon, Sep 04, 2017 at 10:00:00AM +0100, Roger Pau Monné wrote: >> On Mon, Sep 04, 2017 at 02:25:10PM +0800, Chao Gao wrote: >> > On Thu, Aug 31, 2017 at 11:09:48AM +0100, Roger Pau Monne wrote: >> > >I tested Nehalem, Sandy Bridge and Haswell, but sadly not Ivy Bridge >> > >(in fact I didn't even know about Ivy Bridge, that's why I said all >> > >pre-Haswell). >> > > >> > >In fact I'm now trying with a Nehalem processor that seem to work, so >> > >whatever this issue is it certainly doesn't affect all models or >> > >chipsets. >> > >> > Hi, Roger. >> > >> > Last week, I borrowed a Sandy Bridge with Intel(R) Xeon(R) E5-2690 >> > 2.7GHz and tested with 'dom0=pvh'. But I didn't see the machine hang. >> > >> > I also tested on Haswell and found RMRRs in dmar are incorrect on my >> > haswell. The e820 on that machine is: >> > (XEN) [0.00] Xen-e820 RAM map: >> > (XEN) [0.00] - 0009a400 (usable) >> > (XEN) [0.00] 0009a400 - 000a (reserved) >> > (XEN) [0.00] 000e - 0010 (reserved) >> > (XEN) [0.00] 0010 - 6ff84000 (usable) >> > (XEN) [0.00] 6ff84000 - 7ac51000 (reserved) >> > (XEN) [0.00] 7ac51000 - 7b681000 (ACPI NVS) >> > (XEN) [0.00] 7b681000 - 7b7cf000 (ACPI data) >> > (XEN) [0.00] 7b7cf000 - 7b80 (usable) >> > (XEN) [0.00] 7b80 - 9000 (reserved) >> > (XEN) [0.00] fed1c000 - fed2 (reserved) >> > (XEN) [0.00] ff40 - 0001 (reserved) >> > (XEN) [0.00] 0001 - 00208000 (usable) >> > >> > And the RMRRs in DMAR are: >> > (XEN) [0.00] [VT-D]found ACPI_DMAR_RMRR: >> > (XEN) [0.00] [VT-D] endpoint: :05:00.0 >> > (XEN) [0.00] [VT-D]dmar.c:638: RMRR region: base_addr 723b4000 >> > end_addr 7a3f3fff >> > (XEN) [0.00] [VT-D]found ACPI_DMAR_RMRR: >> > (XEN) [0.00] [VT-D] endpoint: :00:1d.0 >> > (XEN) [0.00] [VT-D] endpoint: :00:1a.0 >> > (XEN) [0.00] [VT-D]dmar.c:638: RMRR region: base_addr 723ac000 >> > end_addr 723aefff >> > (Endpoint 05:00.0 is a RAID bus controller. Endpoints 00.1d.0 and 00.1a.0 >> > are USB controllers.) >> > >> > After DMA remapping is enabled, two DMA translation faults are reported >> > by VT-d: >> > (XEN) [9.547924] [VT-D]iommu_enable_translation: iommu->reg = >> > 82c00021b000 >> > (XEN) [9.550620] [VT-D]iommu_enable_translation: iommu->reg = >> > 82c00021d000 >> > (XEN) [9.553327] [VT-D]iommu.c:921: iommu_fault_status: Primary >> > Pending Fault >> > (XEN) [9.555906] [VT-D]DMAR:[DMA Read] Request device [:00:1a.0] >> > fault addr 7a3f5000, iommu reg = 82c00021d000 >> > (XEN) [9.558537] [VT-D]DMAR: reason 06 - PTE Read access is not set >> > (XEN) [9.559860] print_vtd_entries: iommu #1 dev :00:1a.0 gmfn >> > 7a3f5 >> > (XEN) [9.561179] root_entry[00] = 107277c001 >> > (XEN) [9.562447] context[d0] = 2_1072c06001 >> > (XEN) [9.563776] l4[000] = 9c202f171107 >> > (XEN) [9.565125] l3[001] = 9c202f152107 >> > (XEN) [9.566483] l2[1d1] = 9c10727ce107 >> > (XEN) [9.567821] l1[1f5] = 8000 >> > (XEN) [9.569168] l1[1f5] not present >> > (XEN) [9.570502] [VT-D]DMAR:[DMA Read] Request device [:00:1d.0] >> > fault addr 7a3f4000, iommu reg = 82c00021d000 >> > (XEN) [9.573147] [VT-D]DMAR: reason 06 - PTE Read access is not set >> > (XEN) [9.574488] print_vtd_entries: iommu #1 dev :00:1d.0 gmfn >> > 7a3f4 >> > (XEN) [9.575819] root_entry[00] = 107277c001 >> > (XEN) [9.577129] context[e8] = 2_1072c06001 >> > (XEN) [9.578439] l4[000] = 9c202f171107 >> > (XEN) [9.579778] l3[001] = 9c202f152107 >> > (XEN) [9.58] l2[1d1] = 9c10727ce107 >> > (XEN) [9.582482] l1[1f4] = 8000 >> > (XEN) [9.583812] l1[1f4] not present >> > (XEN) [ 10.520172] Unable to find XEN_ELFNOTE_PHYS32_ENTRY address >> > (XEN) [ 10.521499] Failed to load Dom0 kernel >> > (XEN) [ 10.532171] >> > (XEN) [ 10.535464] >> > (XEN) [ 10.542636] Panic on CPU 0: >> > (XEN) [ 10.547394] Could not set up DOM0 guest OS >> > (XEN) [ 10.553605] >> > >> > The fault address the devices failed to access is marked as reserved in >> > e820 and isn't reserved for the devices according to the RMRRs in DMAR. >> > So I think we can draw a conclusion that some existing BIOSs don't >> > expose correct RMRR to OS by DMAR. And we need a workaround such as >> > iommu_inclusive_mapping to deal wit
Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature
Hi Julien, On 09/04/2017 08:07 AM, Julien Grall wrote: > Hello, > > Sorry for the formatting, writing from my phone. Ki > > On Thu, 31 Aug 2017, 22:18 Sergej Proskurin wrote: > [...] > > On your first mail, you started with "smc injection doesn't work", then "I > replace instruction" and now you mention about single-stepping. > > This doesn't help at all to understand what you are doing and really not > related to this thread. > > So can you please details exactly what you are doing rather than giving > bits by bits? > I will provide more information in a separate thread soon so that the actual issue, hopefully, will become clearer. Thank you. >> I use SMC instructions as the guest can register for BRK events. The >> guest cannot register for SMC events. So, in order stay stealthy towards >> the guest and also not to cope with BRK re-injections, SMC's seemed to >> be the right choice : > > I have already said that using SMC is a pretty bad idea when Tamas added > the trapping and you guys still seem to think it is a good idea... I did not know about this conversation with Tamas. Why do you believe that using SMC instructions is not a good idea? Could you please refer me to the particular thread? Thank you. > Current code in hypervisor will always inject undefined instruction > exception when you call SMC (unless you installed VM monitor for the > guest). Also, it will not increase PC. So, if you'll try to remove > inject_undef_exception() call, you'll get into an infinite loop. > I have a registered SMC monitor running in dom0 that does not reinject the undefined instruction exception in do_trap_smc(). So there is no indefinite loop at this point. What I see is that as soon as my code in xen-access (dom0) increments the trapped guest PC by 4 (and also if it doesn't) the next instruction inside the guest will be inside the undef instruction handler (I can see that because I have implemented a single stepping mechanism for AArch64 in Xen that gets activated right after the guest executes the injected SMC instruction). >>> That's strange. Can you print whole vCPU state to determine that PC >>> points to the right place? Also you can check DFAR. Probably you can >>> even dump memory pointed by DFAR to make sure that you written back >>> correct instruction. >> Yea, I do that. And both the SMC injection, as well as further vCPU >> state seems to be correct at this point. >> >> Today, I saw an interesting behavior in my single-stepping >> implementation, which is the reason for my late reply. I can't explain >> what is going wrong, yet. So I will need to further investigate this >> behavior and post and RFC for the single-stepping mechanism as to put >> more eyes on the issue. Maybe, this will help solve it. >> >> But anyway, thank you very much for your help! I really appreciate it :) >> > You probably want to look at > https://lists.xen.org/archives/html/xen-devel/2017-08/msg00661.html and > maybe sync-up with this person if you are not working with him. Thanks, for mentioning that. Florian is a student of mine who has also looked at single-stepping on ARMv8. We have collaborated on this topic together. I will take over on that, as his work goes slightly into a different direction. Thanks, ~Sergej ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/mm: Use static inlines for {, un}adjust_guest_l?e()
There is no need for these to be macros, and the result is easier to read. No functional change, but bloat-o-meter reports the following improvement: add/remove: 1/0 grow/shrink: 2/3 up/down: 235/-427 (-192) function old new delta __get_page_type 52315351+120 adjust_guest_l1e.isra - 96 +96 free_page_type 15401559 +19 ptwr_emulated_update1008 957 -51 create_grant_pv_mapping 13421186-156 mod_l1_entry18921672-220 adjust_guest_l1e(), now being a compiler-visible single unit, is chosen for out-of-line'ing from its several callsites. The other helpers remain inline. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu --- xen/arch/x86/mm.c | 137 +- 1 file changed, 74 insertions(+), 63 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e5b0cce..b82cec4 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1219,52 +1219,63 @@ get_page_from_l4e( return rc; } -#define adjust_guest_l1e(pl1e, d)\ -do { \ -if ( likely(l1e_get_flags((pl1e)) & _PAGE_PRESENT) &&\ - likely(!is_pv_32bit_domain(d)) )\ -{\ -/* _PAGE_GUEST_KERNEL page cannot have the Global bit set. */\ -if ( (l1e_get_flags((pl1e)) & (_PAGE_GUEST_KERNEL|_PAGE_GLOBAL)) \ - == (_PAGE_GUEST_KERNEL|_PAGE_GLOBAL) ) \ -gdprintk(XENLOG_WARNING, \ - "Global bit is set to kernel page %lx\n", \ - l1e_get_pfn((pl1e))); \ -if ( !(l1e_get_flags((pl1e)) & _PAGE_USER) ) \ -l1e_add_flags((pl1e), (_PAGE_GUEST_KERNEL|_PAGE_USER)); \ -if ( !(l1e_get_flags((pl1e)) & _PAGE_GUEST_KERNEL) ) \ -l1e_add_flags((pl1e), (_PAGE_GLOBAL|_PAGE_USER));\ -}\ -} while ( 0 ) - -#define adjust_guest_l2e(pl2e, d) \ -do {\ -if ( likely(l2e_get_flags((pl2e)) & _PAGE_PRESENT) && \ - likely(!is_pv_32bit_domain(d)) ) \ -l2e_add_flags((pl2e), _PAGE_USER); \ -} while ( 0 ) - -#define adjust_guest_l3e(pl3e, d) \ -do {\ -if ( likely(l3e_get_flags((pl3e)) & _PAGE_PRESENT) )\ -l3e_add_flags((pl3e), likely(!is_pv_32bit_domain(d)) ? \ - _PAGE_USER : \ - _PAGE_USER|_PAGE_RW); \ -} while ( 0 ) - -#define adjust_guest_l4e(pl4e, d) \ -do {\ -if ( likely(l4e_get_flags((pl4e)) & _PAGE_PRESENT) && \ - likely(!is_pv_32bit_domain(d)) ) \ -l4e_add_flags((pl4e), _PAGE_USER); \ -} while ( 0 ) - -#define unadjust_guest_l3e(pl3e, d) \ -do {\ -if ( unlikely(is_pv_32bit_domain(d)) && \ - likely(l3e_get_flags((pl3e)) & _PAGE_PRESENT) )\ -l3e_remove_flags((pl3e), _PAGE_USER|_PAGE_RW|_PAGE_ACCESSED); \ -} while ( 0 ) +static l1_pgentry_t adjust_guest_l1e(l1_pgentry_t l1e, const struct domain *d) +{ +if ( likely(l1e_get_flags(l1e) & _PAGE_PRESENT) && + likely(!is_pv_32bit_domain(d)) ) +{ +/* _PAGE_GUEST_KERNEL page cannot have the Global bit set. */ +if ( (l1e_get_flags(l1e) & (_PAGE_GUEST_KERNEL | _PAGE_GLOBAL)) == + (_PAGE_GUEST_KERNEL | _PAGE_GLOBAL) ) +gdprintk(XENLOG_WARNING, + "Global bit is set in kernel page %lx\n", + l1e_get_pfn(l1e)); + +if ( !(l1e_get_flags(l1e) & _PAGE_USER) ) +l1e_add_flags(l1e, (_PAGE_GUEST_KERNEL | _PAGE_USER)); + +if ( !(l1e_get_flags(l1e) & _PAGE_GUEST_KERNEL) ) +l1e_add_flags(l1e, (_PAGE_GLOBAL | _PAGE_USER)); +} + +return l1e; +} + +static l2_pgentry_t adjust_guest_l2e(l2_pgentry_t l2e, const struct domain *d) +{ +i
Re: [Xen-devel] [PATCH] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
>>> On 01.09.17 at 19:07, wrote: > Having all of this logic together makes it easier to follow Xen's virtual > setup across the whole system. > > No practical changes to the resulting L4, although the logic has been > rearanged to avoid rewriting some slots. This changes the zap_ro_mpt > parameter to simply ro_mpt. Another side effect is that highmem-start= is > applied consistently to all L4 tables, not just PV ones. Is this side effect really a good idea to have? I.e. are you certain HVM-only code (i.e. such known to only ever run in HVM or idle vCPU context) is all prepared to not have everything direct- mapped, and is using map_domain_page() et al everywhere? > +void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, > + const struct domain *d, mfn_t sl4mfn, bool ro_mpt) > +{ > +/* Slot 256: RO M2P (if applicable). */ > +l4t[l4_table_offset(RO_MPT_VIRT_START)] = > +ro_mpt ? idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)] > + : l4e_empty(); While the patch in general looks correct, I'm also not convinced having the slot numbers here as well as doing the operation in an open-coded slot-by-slot fashion is a good idea: The comments and the intended ordering here can easily go stale with future adjustments to the virtual address layout. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header
>>> On 04.09.17 at 10:17, wrote: > On 03/09/17 10:38, Nicolas Iooss wrote: >> Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until >> shared_info is initialized") moved xen_init_time_ops() from __init to >> __ref without updating xen-ops.h accordingly. Fix this. >> >> Fixes: d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until >> shared_info is initialized") >> Signed-off-by: Nicolas Iooss >> --- >> arch/x86/xen/xen-ops.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h >> index 0d5004477db6..b2a5d48a2c2a 100644 >> --- a/arch/x86/xen/xen-ops.h >> +++ b/arch/x86/xen/xen-ops.h >> @@ -69,7 +69,7 @@ void xen_setup_runstate_info(int cpu); >> void xen_teardown_timer(int cpu); >> u64 xen_clocksource_read(void); >> void xen_setup_cpu_clockevents(void); >> -void __init xen_init_time_ops(void); >> +void __ref xen_init_time_ops(void); >> void __init xen_hvm_init_time_ops(void); > > When correcting this could you please modify the prototypes to comply to > the intended form as noted in include/linux/init.h (the __ref or __init > annotations should be just before the ending semicolon)? Why would these annotations be kept on the declarations anyway? Attributes affecting code/data placement generally belong on the definitions only. I also question the suggested placement, despite init.h saying so. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 113029: all pass - PUSHED
flight 113029 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/113029/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c00ad62378b1594c9af0f9ebbcc2e30d05a2121e baseline version: ovmf db52890926b6ecff9a416b3beda9c97c83f9fc60 Last test of basis 113005 2017-09-01 21:47:50 Z2 days Testing same since 113029 2017-09-04 01:20:13 Z0 days1 attempts People who touched revisions under test: Hao Wu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=ovmf + revision=c00ad62378b1594c9af0f9ebbcc2e30d05a2121e + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf c00ad62378b1594c9af0f9ebbcc2e30d05a2121e + branch=ovmf + revision=c00ad62378b1594c9af0f9ebbcc2e30d05a2121e + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.9-testing + '[' xc00ad62378b1594c9af0f9ebbcc2e30d05a2121e = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/xtf.git ++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git ++ : git://xenbits.xen.org/xtf.git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/osstest/rumprun.git ++ : git ++ : git://xenbits.xen.org/osstest/rumprun.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git ++ : git://git.seabios.org/seabios.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git ++ : git://xenbits.xen.org/osstest/seabios.git ++ : https://github.com/tianocore/edk2.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git ++ : git://xenbits.xen.org/osstest/ovmf.git ++ : git://xenbits.xen.org/osstest/linux-firmware.git ++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git ++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git ++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git +
Re: [Xen-devel] [PATCH] xen: Drop asmlinkage everywhere
>>> On 01.09.17 at 20:27, wrote: > asmlinkage is defined as nothing on all architectures, and not used > consistently anywhere, even in common code. Remove it all. > > Signed-off-by: Andrew Cooper Surprisingly few instances were left. Non-ARM bits Acked-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/paravirt: remove no longer used paravirt functions
With removal of lguest some of the paravirt functions are no longer needed. Remove them. Signed-off-by: Juergen Gross --- arch/x86/include/asm/desc.h | 3 +-- arch/x86/include/asm/paravirt.h | 37 --- arch/x86/include/asm/paravirt_types.h | 9 - arch/x86/include/asm/pgtable.h| 27 - arch/x86/include/asm/special_insns.h | 10 +- arch/x86/kernel/paravirt.c| 5 - arch/x86/kvm/vmx.c| 2 +- arch/x86/mm/pgtable.c | 7 +-- arch/x86/xen/enlighten_pv.c | 2 -- arch/x86/xen/mmu_pv.c | 2 -- 10 files changed, 12 insertions(+), 92 deletions(-) diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h index d0a21b12dd58..f6630e73843c 100644 --- a/arch/x86/include/asm/desc.h +++ b/arch/x86/include/asm/desc.h @@ -128,7 +128,6 @@ static inline int desc_empty(const void *ptr) #define load_ldt(ldt) asm volatile("lldt %0"::"m" (ldt)) #define store_gdt(dtr) native_store_gdt(dtr) -#define store_idt(dtr) native_store_idt(dtr) #define store_tr(tr) (tr = native_store_tr()) #define load_TLS(t, cpu) native_load_tls(t, cpu) @@ -248,7 +247,7 @@ static inline void native_store_gdt(struct desc_ptr *dtr) asm volatile("sgdt %0":"=m" (*dtr)); } -static inline void native_store_idt(struct desc_ptr *dtr) +static inline void store_idt(struct desc_ptr *dtr) { asm volatile("sidt %0":"=m" (*dtr)); } diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 9ccac1926587..c5e3e4d6ac16 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -71,11 +71,6 @@ static inline void write_cr3(unsigned long x) PVOP_VCALL1(pv_mmu_ops.write_cr3, x); } -static inline unsigned long __read_cr4(void) -{ - return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr4); -} - static inline void __write_cr4(unsigned long x) { PVOP_VCALL1(pv_cpu_ops.write_cr4, x); @@ -228,10 +223,6 @@ static inline void set_ldt(const void *addr, unsigned entries) { PVOP_VCALL2(pv_cpu_ops.set_ldt, addr, entries); } -static inline void store_idt(struct desc_ptr *dtr) -{ - PVOP_VCALL1(pv_cpu_ops.store_idt, dtr); -} static inline unsigned long paravirt_store_tr(void) { return PVOP_CALL0(unsigned long, pv_cpu_ops.store_tr); @@ -365,12 +356,6 @@ static inline void paravirt_release_p4d(unsigned long pfn) PVOP_VCALL1(pv_mmu_ops.release_p4d, pfn); } -static inline void pte_update(struct mm_struct *mm, unsigned long addr, - pte_t *ptep) -{ - PVOP_VCALL3(pv_mmu_ops.pte_update, mm, addr, ptep); -} - static inline pte_t __pte(pteval_t val) { pteval_t ret; @@ -472,28 +457,6 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, PVOP_VCALL4(pv_mmu_ops.set_pte_at, mm, addr, ptep, pte.pte); } -static inline void set_pmd_at(struct mm_struct *mm, unsigned long addr, - pmd_t *pmdp, pmd_t pmd) -{ - if (sizeof(pmdval_t) > sizeof(long)) - /* 5 arg words */ - pv_mmu_ops.set_pmd_at(mm, addr, pmdp, pmd); - else - PVOP_VCALL4(pv_mmu_ops.set_pmd_at, mm, addr, pmdp, - native_pmd_val(pmd)); -} - -static inline void set_pud_at(struct mm_struct *mm, unsigned long addr, - pud_t *pudp, pud_t pud) -{ - if (sizeof(pudval_t) > sizeof(long)) - /* 5 arg words */ - pv_mmu_ops.set_pud_at(mm, addr, pudp, pud); - else - PVOP_VCALL4(pv_mmu_ops.set_pud_at, mm, addr, pudp, - native_pud_val(pud)); -} - static inline void set_pmd(pmd_t *pmdp, pmd_t pmd) { pmdval_t val = native_pmd_val(pmd); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 9ffc36bfe4cd..680624a13c69 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -107,7 +107,6 @@ struct pv_cpu_ops { unsigned long (*read_cr0)(void); void (*write_cr0)(unsigned long); - unsigned long (*read_cr4)(void); void (*write_cr4)(unsigned long); #ifdef CONFIG_X86_64 @@ -119,8 +118,6 @@ struct pv_cpu_ops { void (*load_tr_desc)(void); void (*load_gdt)(const struct desc_ptr *); void (*load_idt)(const struct desc_ptr *); - /* store_gdt has been removed. */ - void (*store_idt)(struct desc_ptr *); void (*set_ldt)(const void *desc, unsigned entries); unsigned long (*store_tr)(void); void (*load_tls)(struct thread_struct *t, unsigned int cpu); @@ -248,12 +245,6 @@ struct pv_mmu_ops { void (*set_pte_at)(struct mm_struct *mm, unsigned long addr
Re: [Xen-devel] [PATCH] x86/mm: Use static inlines for {, un}adjust_guest_l?e()
>>> On 04.09.17 at 12:02, wrote: > +static l1_pgentry_t adjust_guest_l1e(l1_pgentry_t l1e, const struct domain > *d) > +{ > +if ( likely(l1e_get_flags(l1e) & _PAGE_PRESENT) && > + likely(!is_pv_32bit_domain(d)) ) > +{ > +/* _PAGE_GUEST_KERNEL page cannot have the Global bit set. */ > +if ( (l1e_get_flags(l1e) & (_PAGE_GUEST_KERNEL | _PAGE_GLOBAL)) == > + (_PAGE_GUEST_KERNEL | _PAGE_GLOBAL) ) > +gdprintk(XENLOG_WARNING, > + "Global bit is set in kernel page %lx\n", Looks like this could be a single line now. > +static l4_pgentry_t adjust_guest_l4e(l4_pgentry_t l4e, const struct domain > *d) > +{ > +if ( likely(l4e_get_flags(l4e) & _PAGE_PRESENT) && > + likely(!is_pv_32bit_domain(d)) ) Would it be reasonable to move this 2nd condition out of the if() into an ASSERT()? With or without that adjustment Reviewed-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header
On 04/09/17 11:15, Jan Beulich wrote: On 04.09.17 at 10:17, wrote: >> On 03/09/17 10:38, Nicolas Iooss wrote: >>> Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until >>> shared_info is initialized") moved xen_init_time_ops() from __init to >>> __ref without updating xen-ops.h accordingly. Fix this. >>> >>> Fixes: d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until >>> shared_info is initialized") >>> Signed-off-by: Nicolas Iooss >>> --- >>> arch/x86/xen/xen-ops.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h >>> index 0d5004477db6..b2a5d48a2c2a 100644 >>> --- a/arch/x86/xen/xen-ops.h >>> +++ b/arch/x86/xen/xen-ops.h >>> @@ -69,7 +69,7 @@ void xen_setup_runstate_info(int cpu); >>> void xen_teardown_timer(int cpu); >>> u64 xen_clocksource_read(void); >>> void xen_setup_cpu_clockevents(void); >>> -void __init xen_init_time_ops(void); >>> +void __ref xen_init_time_ops(void); >>> void __init xen_hvm_init_time_ops(void); >> When correcting this could you please modify the prototypes to comply to >> the intended form as noted in include/linux/init.h (the __ref or __init >> annotations should be just before the ending semicolon)? > Why would these annotations be kept on the declarations anyway? > Attributes affecting code/data placement generally belong on the > definitions only. Because: a) That’s what the coding style says, and b) So various static analysis can be done (e.g. sparse) on an individual translation unit basis. Your objection to having annotations on declarations is why I've never got around to adding sparse to the hypervisor build. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.9 test] 113028: tolerable trouble: blocked/broken/fail/pass - PUSHED
flight 113028 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/113028/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail in 113014 pass in 113028 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail in 113014 pass in 113028 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 113022 pass in 113014 test-amd64-i386-libvirt-xsm 7 xen-boot fail in 113022 pass in 113028 test-amd64-amd64-xl 18 guest-localmigrate/x10 fail pass in 113014 test-armhf-armhf-xl-arndale 6 xen-installfail pass in 113022 test-armhf-armhf-xl-xsm 7 xen-boot fail pass in 113022 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail pass in 113022 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 2 hosts-allocate broken like 113007 build-arm64 2 hosts-allocate broken like 113007 build-arm64-pvops 2 hosts-allocate broken like 113007 build-arm64 3 capture-logsbroken like 113007 build-arm64-pvops 3 capture-logsbroken like 113007 build-arm64-xsm 3 capture-logs broken never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 113014 like 112996 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 113014 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 113014 never pass test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 113014 never pass test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 113014 never pass test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 112996 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112996 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 113007 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 113007 test-amd64-amd64-xl-rtds 10 debian-install fail like 113007 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 113007 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail
Re: [Xen-devel] [PATCH] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
On 04/09/17 11:09, Jan Beulich wrote: On 01.09.17 at 19:07, wrote: >> Having all of this logic together makes it easier to follow Xen's virtual >> setup across the whole system. >> >> No practical changes to the resulting L4, although the logic has been >> rearanged to avoid rewriting some slots. This changes the zap_ro_mpt >> parameter to simply ro_mpt. Another side effect is that highmem-start= is >> applied consistently to all L4 tables, not just PV ones. > Is this side effect really a good idea to have? Yes. Otherwise the value of highmem-start= as a debugging mechanism is rather stunted. > I.e. are you certain > HVM-only code (i.e. such known to only ever run in HVM or idle > vCPU context) is all prepared to not have everything direct- > mapped, and is using map_domain_page() et al everywhere? I'm not aware of any places which would violate this. Then again, as highmem-start= is too bitrotten to function, I can't test. > >> +void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, >> + const struct domain *d, mfn_t sl4mfn, bool ro_mpt) >> +{ >> +/* Slot 256: RO M2P (if applicable). */ >> +l4t[l4_table_offset(RO_MPT_VIRT_START)] = >> +ro_mpt ? idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)] >> + : l4e_empty(); > While the patch in general looks correct, I'm also not convinced > having the slot numbers here as well as doing the operation in an > open-coded slot-by-slot fashion is a good idea: The comments > and the intended ordering here can easily go stale with future > adjustments to the virtual address layout. The point of having all of this in one place is that there is only one place to change if the virtual address layout changes, so the chances of it getting stale are reduced. The slot-by-slot fashion is how the old function was implemented after optimisation, except this version is shorter because we don't rewrite several slots. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: Use static inlines for {, un}adjust_guest_l?e()
On Mon, Sep 04, 2017 at 11:02:53AM +0100, Andrew Cooper wrote: > There is no need for these to be macros, and the result is easier to read. > > No functional change, but bloat-o-meter reports the following improvement: > > add/remove: 1/0 grow/shrink: 2/3 up/down: 235/-427 (-192) > function old new delta > __get_page_type 52315351+120 > adjust_guest_l1e.isra - 96 +96 > free_page_type 15401559 +19 > ptwr_emulated_update1008 957 -51 > create_grant_pv_mapping 13421186-156 > mod_l1_entry18921672-220 > > adjust_guest_l1e(), now being a compiler-visible single unit, is chosen for > out-of-line'ing from its several callsites. The other helpers remain inline. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 03/12] tools/libxenforeignmemory: add support for resource mapping
On Thu, Aug 31, 2017 at 10:35:56AM +0100, Paul Durrant wrote: > A previous patch introduced a new HYPERVISOR_memory_op to acquire guest > resources for direct priv-mapping. > > This patch adds new functionality into libxenforeignmemory to make use > of a new privcmd ioctl [1] that uses the new memory op to make such > resources available via mmap(2). > > [1] > http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce59a05e6712 > > Signed-off-by: Paul Durrant LGTM: Reviewed-by: Roger Pau Monné Just some very minor nits. [...] > diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c > index a6897dc561..838640aa84 100644 > --- a/tools/libs/foreignmemory/core.c > +++ b/tools/libs/foreignmemory/core.c > @@ -17,6 +17,8 @@ > #include > #include > > +#include > + > #include "private.h" > > xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger, > @@ -120,6 +122,55 @@ int xenforeignmemory_restrict(xenforeignmemory_handle > *fmem, > return osdep_xenforeignmemory_restrict(fmem, domid); > } > > +xenforeignmemory_resource_handle *xenforeignmemory_map_resource( > +xenforeignmemory_handle *fmem, domid_t domid, unsigned int type, > +unsigned int id, unsigned long frame, unsigned long nr_frames, > +void **paddr, int prot, int flags) > +{ > +xenforeignmemory_resource_handle *fres; > +int rc; > + > +/* Check flags only contains POSIX defined values */ > +if ( flags & ~(MAP_SHARED | MAP_PRIVATE) ) > +{ > +errno = EINVAL; > +return NULL; > +} > + > +fres = calloc(1, sizeof(*fres)); > +if ( !fres ) errno = ENOMEM? > +return NULL; > + > +fres->domid = domid; > +fres->type = type; > +fres->id = id; > +fres->frame = frame; > +fres->nr_frames = nr_frames; > +fres->addr = *paddr; > +fres->prot = prot; > +fres->flags = flags; > + > +rc = osdep_xenforeignmemory_map_resource(fmem, fres); > +if ( rc ) > +goto fail; > + > +*paddr = fres->addr; > +return fres; > + > +fail: Not really sure you need a label, this error path is used only once. > +free(fres); > + > +return NULL; > +} > + > +void xenforeignmemory_unmap_resource( > +xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres) > +{ > +osdep_xenforeignmemory_unmap_resource(fmem, fres); > + Spurious newline? > +free(fres); > +} > + > /* > * Local variables: > * mode: C [...] > diff --git a/tools/libs/foreignmemory/libxenforeignmemory.map > b/tools/libs/foreignmemory/libxenforeignmemory.map > index 716ecaf15c..d5323c87d9 100644 > --- a/tools/libs/foreignmemory/libxenforeignmemory.map > +++ b/tools/libs/foreignmemory/libxenforeignmemory.map > @@ -14,3 +14,8 @@ VERS_1.2 { > global: > xenforeignmemory_map2; > } VERS_1.1; > +VERS_1.3 { > + global: > + xenforeignmemory_map_resource; > + xenforeignmemory_unmap_resource; > +} VERS_1.2; > diff --git a/tools/libs/foreignmemory/linux.c > b/tools/libs/foreignmemory/linux.c > index 374e45aed5..4447723cb1 100644 > --- a/tools/libs/foreignmemory/linux.c > +++ b/tools/libs/foreignmemory/linux.c > @@ -277,6 +277,51 @@ int > osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem, > return ioctl(fmem->fd, IOCTL_PRIVCMD_RESTRICT, &domid); > } > > +void osdep_xenforeignmemory_unmap_resource( > +xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres) > +{ > +(void) munmap(fres->addr, fres->nr_frames << PAGE_SHIFT); Do you really need the void cast? Or should this really be a void function? Other unmap functions (osdep_xenforeignmemory_unmap) return the error to the caller. > +} > + > +int osdep_xenforeignmemory_map_resource( > +xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres) > +{ > +privcmd_mmap_resource_t mr; > +int rc; > + > +fres->addr = mmap(fres->addr, fres->nr_frames << PAGE_SHIFT, > + fres->prot, fres->flags | MAP_SHARED, fmem->fd, 0); > +if ( fres->addr == MAP_FAILED ) > +return -1; > + > +memset(&mr, 0, sizeof(mr)); No need for the memset, you are setting all fields below anyway. > +mr.dom = fres->domid; > +mr.type = fres->type; > +mr.id = fres->id; > +mr.idx = fres->frame; > +mr.num = fres->nr_frames; > +mr.addr = (uintptr_t)fres->addr; [...] > diff --git a/tools/libs/foreignmemory/private.h > b/tools/libs/foreignmemory/private.h > index c5c07cc4c4..9ff94b724d 100644 > --- a/tools/libs/foreignmemory/private.h > +++ b/tools/libs/foreignmemory/private.h > @@ -42,6 +42,36 @@ void *compat_mapforeign_batch(xenforeignmem_handle *fmem, > uint32_t dom, >xen_pfn_t *arr, int num); > #endif > > +struct xenforeignmemory_resource_handle { > +domid_t domid; > +unsigned int type; > +unsigned int id; > +unsigned long frame; > +unsigned long nr_frames; > +v
Re: [Xen-devel] [PATCH v3 04/12] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint
On Thu, Aug 31, 2017 at 10:35:57AM +0100, Paul Durrant wrote: > By using a static inline stub in private.h for OS where this functionality > is not implemented, the various duplicate stubs in the OS-specific source > modules can be avoided. Ouch, forget my comment in the previous patch, haven't seen that one. > > Signed-off-by: Paul Durrant > --- > Cc: Ian Jackson > Cc: Wei Liu > > v3: > - Patch added in response to review comments. > --- > tools/libs/foreignmemory/minios.c | 7 --- > tools/libs/foreignmemory/netbsd.c | 7 --- > tools/libs/foreignmemory/private.h | 12 +--- > tools/libs/foreignmemory/solaris.c | 7 --- You forgot the one in freebsd.c. With that added (or rather removed): Reviewed-by: Roger Pau Monné Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 113035: tolerable trouble: broken/pass - PUSHED
flight 113035 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113035/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113003 build-arm64-pvops 3 capture-logsbroken like 113003 build-arm64 2 hosts-allocate broken like 113003 build-arm64 3 capture-logsbroken like 113003 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen fdc6cef85734662e32c91fee2a191d2b26a682f4 baseline version: xen ee2c1fc48ac14a4c8b9eb9224753591fa5e7 Last test of basis 113003 2017-09-01 18:01:33 Z2 days Testing same since 113035 2017-09-04 09:02:44 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Wei Liu jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs Pushing revision : + branch=xen-unstable-smoke + revision=fdc6cef85734662e32c91fee2a191d2b26a682f4 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke fdc6cef85734662e32c91fee2a191d2b26a682f4 + branch=xen-unstable-smoke + revision=fdc6cef85734662e32c91fee2a191d2b26a682f4 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-4.9-testing + '[' xfdc6cef85734662e32c91fee2a191d2b26a682f4 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/xtf.git ++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git ++ : git:/
Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build
Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): > On 01.09.17 at 19:04, wrote: > > AFAICT you must mean tools/firmware/hvmloader/.build.o.d ? > > No, I mean the libxl instance of the file (remember that the same > libacpi source file is being compiled twice). The hvmloader instance > looks similar, but doesn't cause the same problem (because there > are no auto-generated headers). I had an out of date tree somehow, so I didn't find the build.o. > > Can you provide a complete log of a failing build ? > > With the above, is that really needed? And if so, do you mean > just normal make output, or output from additionally passing -p. I still think it would be helpful. But in the meantime I'm looking again at this log of a successful build. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH V2 3/4] hvmload: Add x2apic entry support in the MADT build
On 2017年09月01日 17:57, Roger Pau Monné wrote: > On Thu, Aug 31, 2017 at 01:01:48AM -0400, Lan Tianyu wrote: >> This patch is to add x2apic entry support for ACPI MADT table >> according to ACPI spec 5.2.12.12 Processor Local x2APIC Structure >> >> Signed-off-by: Chao Gao >> Signed-off-by: Lan Tianyu >> --- >> tools/libacpi/acpi2_0.h | 10 + >> tools/libacpi/build.c | 59 >> +++-- >> 2 files changed, 52 insertions(+), 17 deletions(-) >> >> diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h >> index 758a823..caa3682 100644 >> --- a/tools/libacpi/acpi2_0.h >> +++ b/tools/libacpi/acpi2_0.h >> @@ -322,6 +322,7 @@ struct acpi_20_waet { >> #define ACPI_IO_SAPIC 0x06 >> #define ACPI_PROCESSOR_LOCAL_SAPIC 0x07 >> #define ACPI_PLATFORM_INTERRUPT_SOURCES 0x08 >> +#define ACPI_PROCESSOR_LOCAL_X2APIC 0x09 >> >> /* >> * APIC Structure Definitions. >> @@ -338,6 +339,15 @@ struct acpi_20_madt_lapic { >> uint32_t flags; >> }; >> >> +struct acpi_20_madt_x2apic { >> +uint8_t type; >> +uint8_t length; >> +uint16_t reserved; /* reserved - must be zero */ >> +uint32_t apic_id; /* Processor x2APIC ID */ >> +uint32_t flags; >> +uint32_t acpi_processor_id; /* ACPI processor UID */ >> +}; >> + >> /* >> * Local APIC Flags. All other bits are reserved and must be 0. >> */ >> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c >> index c7cc784..0c95850 100644 >> --- a/tools/libacpi/build.c >> +++ b/tools/libacpi/build.c >> @@ -82,9 +82,9 @@ static struct acpi_20_madt *construct_madt(struct >> acpi_ctxt *ctxt, >> struct acpi_20_madt *madt; >> struct acpi_20_madt_intsrcovr *intsrcovr; >> struct acpi_20_madt_ioapic*io_apic; >> -struct acpi_20_madt_lapic *lapic; >> const struct hvm_info_table *hvminfo = config->hvminfo; >> int i, sz; >> +void *end; >> >> if ( config->lapic_id == NULL ) >> return NULL; >> @@ -92,7 +92,12 @@ static struct acpi_20_madt *construct_madt(struct >> acpi_ctxt *ctxt, >> sz = sizeof(struct acpi_20_madt); >> sz += sizeof(struct acpi_20_madt_intsrcovr) * 16; >> sz += sizeof(struct acpi_20_madt_ioapic); >> -sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus; >> + >> +if (hvminfo->nr_vcpus < 128) > > This should be done based on APIC ID. There will be a problem how to get max apic id. Should we use the max vcpu index to get max APIC id? > >> +sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus; >> +else >> +sz += sizeof(struct acpi_20_madt_lapic) * 128 + >> + sizeof(struct acpi_20_madt_x2apic) * (hvminfo->nr_vcpus - >> 128); >> >> madt = ctxt->mem_ops.alloc(ctxt, sz, 16); >> if (!madt) return NULL; >> @@ -109,7 +114,7 @@ static struct acpi_20_madt *construct_madt(struct >> acpi_ctxt *ctxt, >> madt->flags = ACPI_PCAT_COMPAT; >> >> if ( config->table_flags & ACPI_HAS_IOAPIC ) >> -{ >> +{ > > Spurious cleanup? > >> intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1); >> for ( i = 0; i < 16; i++ ) >> { >> @@ -146,27 +151,47 @@ static struct acpi_20_madt *construct_madt(struct >> acpi_ctxt *ctxt, >> io_apic->ioapic_id = config->ioapic_id; >> io_apic->ioapic_addr = config->ioapic_base_address; >> >> -lapic = (struct acpi_20_madt_lapic *)(io_apic + 1); >> +end = (struct acpi_20_madt_lapic *)(io_apic + 1); >> } >> else >> -lapic = (struct acpi_20_madt_lapic *)(madt + 1); >> +end = (struct acpi_20_madt_lapic *)(madt + 1); >> + >> +info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, end); >> >> -info->nr_cpus = hvminfo->nr_vcpus; > > Why are you moving this? AFAICT the value of nr_vpcus is not changed, > so you might as well leave it as-is. OK. > >> -info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic); >> for ( i = 0; i < hvminfo->nr_vcpus; i++ ) >> { >> -memset(lapic, 0, sizeof(*lapic)); >> -lapic->type= ACPI_PROCESSOR_LOCAL_APIC; >> -lapic->length = sizeof(*lapic); >> -/* Processor ID must match processor-object IDs in the DSDT. */ >> -lapic->acpi_processor_id = i; >> -lapic->apic_id = config->lapic_id(i); >> -lapic->flags = (test_bit(i, hvminfo->vcpu_online) >> -? ACPI_LOCAL_APIC_ENABLED : 0); >> -lapic++; >> +unsigned int apic_id = config->lapic_id(i); >> + >> +if ( apic_id < 255 ) { >> +struct acpi_20_madt_lapic *lapic = end; >> + >> +memset(lapic, 0, sizeof(*lapic)); >> +lapic->type= ACPI_PROCESSOR_LOCAL_APIC; >> +lapic->length = sizeof(*lapic); >> +/* Processor ID must match processor-object IDs in the DSDT. */ >> +lapic->acpi_processor_id =
Re: [Xen-devel] [PATCH v3 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table
On Thu, Aug 31, 2017 at 10:35:58AM +0100, Paul Durrant wrote: > A previous patch added support for priv-mapping guest resources directly > (rather than having to foreign-map, which requires P2M modification for > HVM guests). > > This patch makes use of the new API to seed the guest grant table unless > the underlying infrastructure (i.e. privcmd) doesn't support it, in which > case the old scheme is used. > > NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was > actually unnecessary, as the grant table has already been seeded > by a prior call to xc_dom_gnttab_init() made by libxl__build_dom(). > > Signed-off-by: Paul Durrant > Acked-by: Marek Marczykowski-Górecki Reviewed-by: Roger Pau Monné [...] > +int xc_dom_gnttab_init(struct xc_dom_image *dom) > +{ > +xc_interface *xch = dom->xch; > +domid_t guest_domid = dom->guest_domid; > +bool is_hvm = xc_dom_translated(dom); > +xen_pfn_t console_gmfn = xc_dom_p2m(dom, dom->console_pfn); > +xen_pfn_t xenstore_gmfn = xc_dom_p2m(dom, dom->xenstore_pfn); > +domid_t console_domid = dom->console_domid; > +domid_t xenstore_domid = dom->xenstore_domid; It looks weird to have all this local variables that are used only once. I would probably remove the dom->... ones. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH V2 3/4] hvmload: Add x2apic entry support in the MADT build
On Mon, Sep 04, 2017 at 06:59:24PM +0800, Lan Tianyu wrote: > On 2017年09月01日 17:57, Roger Pau Monné wrote: > > On Thu, Aug 31, 2017 at 01:01:48AM -0400, Lan Tianyu wrote: > >> @@ -92,7 +92,12 @@ static struct acpi_20_madt *construct_madt(struct > >> acpi_ctxt *ctxt, > >> sz = sizeof(struct acpi_20_madt); > >> sz += sizeof(struct acpi_20_madt_intsrcovr) * 16; > >> sz += sizeof(struct acpi_20_madt_ioapic); > >> -sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus; > >> + > >> +if (hvminfo->nr_vcpus < 128) > > > > This should be done based on APIC ID. > > There will be a problem how to get max apic id. Should we use the max > vcpu index to get max APIC id? IMHO, this should become a loop that iterates over each vCPU getting it's APIC ID, and add either a lapic or x2apic struct size to sz. > >> -info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic); > >> for ( i = 0; i < hvminfo->nr_vcpus; i++ ) > >> { > >> -memset(lapic, 0, sizeof(*lapic)); > >> -lapic->type= ACPI_PROCESSOR_LOCAL_APIC; > >> -lapic->length = sizeof(*lapic); > >> -/* Processor ID must match processor-object IDs in the DSDT. */ > >> -lapic->acpi_processor_id = i; > >> -lapic->apic_id = config->lapic_id(i); > >> -lapic->flags = (test_bit(i, hvminfo->vcpu_online) > >> -? ACPI_LOCAL_APIC_ENABLED : 0); > >> -lapic++; > >> +unsigned int apic_id = config->lapic_id(i); > >> + > >> +if ( apic_id < 255 ) { > >> +struct acpi_20_madt_lapic *lapic = end; > >> + > >> +memset(lapic, 0, sizeof(*lapic)); > >> +lapic->type= ACPI_PROCESSOR_LOCAL_APIC; > >> +lapic->length = sizeof(*lapic); > >> +/* Processor ID must match processor-object IDs in the DSDT. > >> */ > >> +lapic->acpi_processor_id = i; > >> +lapic->apic_id = config->lapic_id(i); > >> +lapic->flags = ((i < hvminfo->nr_vcpus) && > > > > I don't understand why you have added this. > > If apic_id < 255, still use xapic structure and use x2apic structure for > others. I think this is following your comment on last version. I'm complaining about the (i < hvminfo->nr_vcpus) check, from the loop above i is bounded to hvminfo->nr_vpcu, so this check is useless AFAICT. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 1/2] tools: use '__i386__' and '__x86_64__' to replace PSR macros
The libxl interfaces and related functions are not necessary to be included by 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86 macros. Furthermore, only compile 'xl_psr.c' under x86. Suggested-by: Roger Pau Monné Suggested-by: Wei Liu Signed-off-by: Yi Sun --- - This patch is not tested to be compiled under ARM. v3: - replace PSR macros to '__i386__' and '__x86_64__'. (suggested by Wei Liu) - only compile 'xl_psr.c' under x86. (suggested by Roger Pau Monné) v2: - remove the macros in xl.h. (suggested by Roger Pau Monné) --- tools/libxl/libxl.h| 6 +- tools/xl/Makefile | 5 +++-- tools/xl/xl.h | 4 +--- tools/xl/xl_cmdtable.c | 5 + tools/xl/xl_psr.c | 5 - 5 files changed, 6 insertions(+), 19 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 229e289..6c087dd 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -2166,7 +2166,7 @@ bool libxl_ms_vm_genid_is_zero(const libxl_ms_vm_genid *id); void libxl_ms_vm_genid_copy(libxl_ctx *ctx, libxl_ms_vm_genid *dst, const libxl_ms_vm_genid *src); -#ifdef LIBXL_HAVE_PSR_CMT +#if defined(__i386__) || defined(__x86_64__) int libxl_psr_cmt_attach(libxl_ctx *ctx, uint32_t domid); int libxl_psr_cmt_detach(libxl_ctx *ctx, uint32_t domid); int libxl_psr_cmt_domain_attached(libxl_ctx *ctx, uint32_t domid); @@ -2179,9 +2179,7 @@ int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid, uint32_t socketid, uint32_t *l3_cache_occupancy); -#endif -#ifdef LIBXL_HAVE_PSR_MBM int libxl_psr_cmt_type_supported(libxl_ctx *ctx, libxl_psr_cmt_type type); int libxl_psr_cmt_get_sample(libxl_ctx *ctx, uint32_t domid, @@ -2189,9 +2187,7 @@ int libxl_psr_cmt_get_sample(libxl_ctx *ctx, uint64_t scope, uint64_t *sample_r, uint64_t *tsc_r); -#endif -#ifdef LIBXL_HAVE_PSR_CAT /* * Function to set a domain's cbm. It operates on a single or multiple * target(s) defined in 'target_map'. The definition of 'target_map' is diff --git a/tools/xl/Makefile b/tools/xl/Makefile index c868899..ff85d48 100644 --- a/tools/xl/Makefile +++ b/tools/xl/Makefile @@ -15,11 +15,12 @@ LDFLAGS += $(PTHREAD_LDFLAGS) CFLAGS_XL += $(CFLAGS_libxenlight) CFLAGS_XL += -Wshadow -XL_OBJS = xl.o xl_cmdtable.o xl_sxp.o xl_utils.o +XL_OBJS-$(CONFIG_X86) = xl_psr.o +XL_OBJS = xl.o xl_cmdtable.o xl_sxp.o xl_utils.o $(XL_OBJS-y) XL_OBJS += xl_tmem.o xl_parse.o xl_cpupool.o xl_flask.o XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o XL_OBJS += xl_sched.o xl_pci.o xl_vcpu.o xl_cdrom.o xl_mem.o -XL_OBJS += xl_psr.o xl_info.o xl_console.o xl_misc.o +XL_OBJS += xl_info.o xl_console.o xl_misc.o XL_OBJS += xl_vmcontrol.o xl_saverestore.o xl_migrate.o $(XL_OBJS): CFLAGS += $(CFLAGS_libxentoollog) diff --git a/tools/xl/xl.h b/tools/xl/xl.h index aa95b77..8d7b957 100644 --- a/tools/xl/xl.h +++ b/tools/xl/xl.h @@ -197,13 +197,11 @@ int main_loadpolicy(int argc, char **argv); int main_remus(int argc, char **argv); #endif int main_devd(int argc, char **argv); -#ifdef LIBXL_HAVE_PSR_CMT +#if defined(__i386__) || defined(__x86_64__) int main_psr_hwinfo(int argc, char **argv); int main_psr_cmt_attach(int argc, char **argv); int main_psr_cmt_detach(int argc, char **argv); int main_psr_cmt_show(int argc, char **argv); -#endif -#ifdef LIBXL_HAVE_PSR_CAT int main_psr_cat_cbm_set(int argc, char **argv); int main_psr_cat_show(int argc, char **argv); #endif diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c index 2c71a9f..6baaed2 100644 --- a/tools/xl/xl_cmdtable.c +++ b/tools/xl/xl_cmdtable.c @@ -517,7 +517,7 @@ struct cmd_spec cmd_table[] = { "-F Run in the foreground.\n" "-p, --pidfile [FILE]Write PID to pidfile when daemonizing.", }, -#ifdef LIBXL_HAVE_PSR_CMT +#if defined(__i386__) || defined(__x86_64__) { "psr-hwinfo", &main_psr_hwinfo, 0, 1, "Show hardware information for Platform Shared Resource", @@ -544,8 +544,6 @@ struct cmd_spec cmd_table[] = { "\"total-mem-bandwidth\": Show total memory bandwidth(KB/s)\n" "\"local-mem-bandwidth\": Show local memory bandwidth(KB/s)\n", }, -#endif -#ifdef LIBXL_HAVE_PSR_CAT { "psr-cat-set", &main_psr_cat_cbm_set, 0, 1, "Set cache capacity bitmasks(CBM) for a domain", @@ -561,7 +559,6 @@ struct cmd_spec cmd_table[] = { "[options] ", "-l Specify the cache level to process, otherwise L3 cache is processed\n" }, - #endif { "usbctrl-attach", &main_usbctrl_attach, 0, 1, diff --git a/tools/xl/xl_psr.c b/tools/xl/xl_psr.c index 7309d4f..544f6f0 100644 --- a/tools/xl/xl_psr.c +++ b/tools/xl/xl_psr.c @@ -25,7 +25,6 @@
Re: [Xen-devel] [RFC PATCH V2 2/4] Tool/ACPI: DSDT extension to support more vcpus
On 2017年09月04日 17:05, Roger Pau Monné wrote: > On Mon, Sep 04, 2017 at 11:07:14AM +0800, Lan Tianyu wrote: >> On 2017年09月01日 17:41, Roger Pau Monné wrote: >>> On Fri, Sep 01, 2017 at 10:54:02AM +0800, Lan Tianyu wrote: On 2017年08月31日 23:38, Roger Pau Monné wrote: > On Thu, Aug 31, 2017 at 01:01:47AM -0400, Lan Tianyu wrote: >> This patch is to change DSDT table for processor object to support >128 >> vcpus >> accroding to ACPI spec 8.4 Declaring Processors >> >> Signed-off-by: Lan Tianyu >> --- >> tools/libacpi/mk_dsdt.c | 18 -- >> 1 file changed, 12 insertions(+), 6 deletions(-) >> >> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c >> index 2daf32c..6c4c325 100644 >> --- a/tools/libacpi/mk_dsdt.c >> +++ b/tools/libacpi/mk_dsdt.c >> @@ -24,6 +24,8 @@ >> #include >> #endif >> >> +#define CPU_NAME_FMT "P%.03X" >> + >> static unsigned int indent_level; >> static bool debug = false; >> >> @@ -196,10 +198,14 @@ int main(int argc, char **argv) >> /* Define processor objects and control methods. */ >> for ( cpu = 0; cpu < max_cpus; cpu++) >> { >> -push_block("Processor", "PR%02X, %d, 0xb010, 0x06", cpu, >> cpu); >> +unsigned int apic_id = cpu * 2; > > This is fragile, ideally there should be a single point where the APIC > ID is calculated. Although there are already two places where the APIC > ID is calculated, in hvmloader and libxl. > > And I'm not sure how to use any of those here in order to avoid > introducing a third one. The mk_dsdt is independent tool to build dsdt table. It wasn't linked with libxl and hvmloader. We can't reuse old function to do that. But I think we may introduce a new LAPIC_ID(vcpu) in the arch head file(i.e, #include ) and replace old ones. >>> >>> There's already a LAPIC_ID macro in hvmloader headers which should be >>> placed somewhere suitable. >> >> Yes, this is what I mentioned. > > Jan has expressed some concerns with removing the hook, see: > > <59a94e32027800176...@prv-mh.provo.novell.com> So we still need to introduce LAPIC_ID() here, right? > >>> What about removing the lapic_id hook from >>> acpi_config and placing the LAPIC_ID macro in the libacpi.h header? >> >> I think this should be ARCH specific. I am not sure whether ARM follows >> rule of "apic_id = vcpu_id *2". >> >> Julien, could you give some inputs? Thanks. > > AFAIK ARM doesn't have a local APIC, so there are no xAPIC/x2APIC > entries in the ARM MADT. > -- Best regards Tianyu Lan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/2] tools: change the type of '*nr' in 'libxl_psr_cat_get_info'
Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info' is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes this and does related changes. Suggested-by: Roger Pau Monné Signed-off-by: Yi Sun --- - This patch depends on patch "tools: use '__i386__' and '__x86_64__' to replace PSR". v2: - assign 'num' to '*nr' if return value is success. (suggested by Roger Pau Monné) --- tools/libxl/libxl.h | 2 +- tools/libxl/libxl_psr.c | 7 +-- tools/xl/xl_psr.c | 9 - 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 6c087dd..484b5b7 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -2211,7 +2211,7 @@ int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid, * and the length in 'nr'. */ int libxl_psr_cat_get_info(libxl_ctx *ctx, libxl_psr_cat_info **info, - int *nr, unsigned int lvl); + unsigned int *nr, unsigned int lvl); int libxl_psr_cat_get_l3_info(libxl_ctx *ctx, libxl_psr_cat_info **info, int *nr); void libxl_psr_cat_info_list_free(libxl_psr_cat_info *list, int nr); diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c index f55ba1e..197505a 100644 --- a/tools/libxl/libxl_psr.c +++ b/tools/libxl/libxl_psr.c @@ -362,7 +362,7 @@ int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid, } int libxl_psr_cat_get_info(libxl_ctx *ctx, libxl_psr_cat_info **info, - int *nr, unsigned int lvl) + unsigned int *nr, unsigned int lvl) { GC_INIT(ctx); int rc; @@ -410,8 +410,11 @@ int libxl_psr_cat_get_l3_info(libxl_ctx *ctx, libxl_psr_cat_info **info, int *nr) { int rc; +unsigned int num; -rc = libxl_psr_cat_get_info(ctx, info, nr, 3); +rc = libxl_psr_cat_get_info(ctx, info, &num, 3); +if (!rc) +*nr = num; return rc; } diff --git a/tools/xl/xl_psr.c b/tools/xl/xl_psr.c index 544f6f0..ef00048 100644 --- a/tools/xl/xl_psr.c +++ b/tools/xl/xl_psr.c @@ -294,8 +294,8 @@ int main_psr_cmt_show(int argc, char **argv) static int psr_l3_cat_hwinfo(void) { -int rc, nr; -unsigned int i; +int rc; +unsigned int i, nr; uint32_t l3_cache_size; libxl_psr_cat_info *info; @@ -424,7 +424,7 @@ static int psr_cat_print_socket(uint32_t domid, libxl_psr_cat_info *info, static int psr_cat_show(uint32_t domid, unsigned int lvl) { -int i, nr; +unsigned int i, nr; int rc; libxl_psr_cat_info *info; @@ -453,8 +453,7 @@ out: static int psr_l2_cat_hwinfo(void) { int rc; -unsigned int i; -int nr; +unsigned int i, nr; libxl_psr_cat_info *info; rc = libxl_psr_cat_get_info(ctx, &info, &nr, 2); -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build
I have investigated this further and have made the following discoveries: 1. make distinguishes targets purely textually. It will canonicalise a target name by removing ./ before comparison (so `foo' and `./foo' are considered the same target) but it won't examine the filesystem AFAICT. So `foo' and `../../this/subdir/foo' are different targets. (You seem to have already observed or known this.) 2. If you use gcc -MMD to generate a .d file, and say -I. to include things from the cwd, but invoke gcc to compile a file elsewhere, eg gcc -MMD -I -o build.o /other/path/build.c and build.c #includes `foo.h', then the -MMD output mentions `/absolute/path/to/this/subdir/foo.h', even though it could refer to `foo.h'. (VPATH and vpath are obvious ways for this to happen.) This is presumably because gcc has noticed that `.' in this context must mean relative to the invocation cwd, not relative to build.c. 3. If foo.h is autogenerated using some kind of pattern rule, you end up with two `copies' of the rule, which can run simultaneously, once for build.c -> build.o and once for normal files in the same cwd. I think (2) is a bug in gcc. But we can't sensibly expect to fix that. Sadly I think the right fix is to seddery the pointless paths out of the .d files. I don't think going round all our Makefiles adding rules of the form $(ABS_PATH_TO_HERE)/auto-%-generated.: auto-%-generated.h is sensible. There are too many and this is too ad-hoc. Do people agree ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/mm: use put_page_type_preemptible in put_page_from_l{3, 4}e
No functional change. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper Cc: George Dunlap --- xen/arch/x86/mm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e5b0cceae4..314da84720 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1376,7 +1376,7 @@ static int put_page_from_l3e(l3_pgentry_t l3e, unsigned long pfn, if ( unlikely(partial > 0) ) { ASSERT(!defer); -return __put_page_type(pg, 1); +return put_page_type_preemptible(pg); } if ( defer ) @@ -1399,7 +1399,7 @@ static int put_page_from_l4e(l4_pgentry_t l4e, unsigned long pfn, if ( unlikely(partial > 0) ) { ASSERT(!defer); -return __put_page_type(pg, 1); +return put_page_type_preemptible(pg); } if ( defer ) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: use put_page_type_preemptible in put_page_from_l{3, 4}e
On Mon, Sep 04, 2017 at 12:42:06PM +0100, Wei Liu wrote: > No functional change. > > Signed-off-by: Wei Liu > --- > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: George Dunlap > --- > xen/arch/x86/mm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index e5b0cceae4..314da84720 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c In fact the forward declaration for __put_page_type here can also be deleted. > @@ -1376,7 +1376,7 @@ static int put_page_from_l3e(l3_pgentry_t l3e, unsigned > long pfn, > if ( unlikely(partial > 0) ) > { > ASSERT(!defer); > -return __put_page_type(pg, 1); > +return put_page_type_preemptible(pg); > } > > if ( defer ) > @@ -1399,7 +1399,7 @@ static int put_page_from_l4e(l4_pgentry_t l4e, unsigned > long pfn, > if ( unlikely(partial > 0) ) > { > ASSERT(!defer); > -return __put_page_type(pg, 1); > +return put_page_type_preemptible(pg); > } > > if ( defer ) > -- > 2.11.0 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: use put_page_type_preemptible in put_page_from_l{3, 4}e
On 04/09/17 12:45, Wei Liu wrote: > On Mon, Sep 04, 2017 at 12:42:06PM +0100, Wei Liu wrote: >> No functional change. >> >> Signed-off-by: Wei Liu >> --- >> Cc: Jan Beulich >> Cc: Andrew Cooper >> Cc: George Dunlap >> --- >> xen/arch/x86/mm.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c >> index e5b0cceae4..314da84720 100644 >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c > In fact the forward declaration for __put_page_type here can also be > deleted. With this done, Reviewed-by: Andrew Cooper >> @@ -1376,7 +1376,7 @@ static int put_page_from_l3e(l3_pgentry_t l3e, >> unsigned long pfn, >> if ( unlikely(partial > 0) ) >> { >> ASSERT(!defer); >> -return __put_page_type(pg, 1); >> +return put_page_type_preemptible(pg); >> } >> >> if ( defer ) >> @@ -1399,7 +1399,7 @@ static int put_page_from_l4e(l4_pgentry_t l4e, >> unsigned long pfn, >> if ( unlikely(partial > 0) ) >> { >> ASSERT(!defer); >> -return __put_page_type(pg, 1); >> +return put_page_type_preemptible(pg); >> } >> >> if ( defer ) >> -- >> 2.11.0 >> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: Use static inlines for {, un}adjust_guest_l?e()
On 04/09/17 11:33, Jan Beulich wrote: On 04.09.17 at 12:02, wrote: >> +static l1_pgentry_t adjust_guest_l1e(l1_pgentry_t l1e, const struct domain >> *d) >> +{ >> +if ( likely(l1e_get_flags(l1e) & _PAGE_PRESENT) && >> + likely(!is_pv_32bit_domain(d)) ) >> +{ >> +/* _PAGE_GUEST_KERNEL page cannot have the Global bit set. */ >> +if ( (l1e_get_flags(l1e) & (_PAGE_GUEST_KERNEL | _PAGE_GLOBAL)) == >> + (_PAGE_GUEST_KERNEL | _PAGE_GLOBAL) ) >> +gdprintk(XENLOG_WARNING, >> + "Global bit is set in kernel page %lx\n", > Looks like this could be a single line now. So it can. > >> +static l4_pgentry_t adjust_guest_l4e(l4_pgentry_t l4e, const struct domain >> *d) >> +{ >> +if ( likely(l4e_get_flags(l4e) & _PAGE_PRESENT) && >> + likely(!is_pv_32bit_domain(d)) ) > Would it be reasonable to move this 2nd condition out of the if() > into an ASSERT()? With or without that adjustment > Reviewed-by: Jan Beulich I'll do a separate patch clarifying the correctness of 32bit PV guests in a number of places. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 72059: all pass
This run is configured for baseline tests only. flight 72059 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72059/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c00ad62378b1594c9af0f9ebbcc2e30d05a2121e baseline version: ovmf db52890926b6ecff9a416b3beda9c97c83f9fc60 Last test of basis72054 2017-09-02 09:46:56 Z2 days Testing same since72059 2017-09-04 10:47:42 Z0 days1 attempts People who touched revisions under test: Hao Wu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit c00ad62378b1594c9af0f9ebbcc2e30d05a2121e Author: Hao Wu Date: Fri Sep 1 09:32:10 2017 +0800 SourceLevelDebugPkg: Use Pcd for the revision of transfer protocol V3 changes: Add detailed description for the usage of the Pcd in package DEC file. Update the comment for the introduced Pcd in module INF files. V2 changes: Instead of using a global variable, use a Pcd for transfer protocol revision. Previously, the revision of the debug agent transfer protocol is reflected by a macro. This commit introduces a Pcd to reflect the revision in order to avoid the comparison of two macros, which will generate a constant result detected by code checkers. Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu Reviewed-by: Ruiyu Ni ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] UEFI Secure Boot Xen 4.9
On Wed, Aug 30, 2017 at 10:16:23AM -0600, Tamas K Lengyel wrote: > On Tue, Aug 29, 2017 at 2:01 PM, Daniel Kiper wrote: > > Hey Tamas, > > > > Sorry for late reply. I was on vacation. > > > > On Tue, Aug 22, 2017 at 09:01:06PM -0600, Tamas K Lengyel wrote: > >> On Tue, May 16, 2017 at 5:04 AM, Daniel Kiper > >> wrote: > > > > [...] > > > >> > UEFI will verify shim secure boot signature then shim will verify GRUB2 > >> > signature then GRUB2 will verify (with shim protocol) Xen signature and > >> > finally Xen will verify (with shim protocol) Linux kernel signature. Then > >> > your kernel can verify modules using whatever you want. > >> > > >> >> I would be happy to work to help achieve this. > >> > > >> > There is a chance that I will have something very raw at the beginning > >> > of June. If you wish to do tests drop me a line. > >> > >> Hi Daniel, > >> is there any news on this? I would be interested in giving this a shot too. > > > > Please look at > > > > https://lists.xen.org/archives/html/xen-devel/2017-07/msg00982.html > > > > and at > > > > https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html > > > > Attachments contain the same patches as above but rebased on latest > > GRUB2 and Xen git repositories. > > > > Due to some travel I am going to restart work on this in the second > > half of September. > > > > If you have any questions please drop me a line. > > > > Hi Daniel, > thanks for the update, I'll give it a shot today to set it up. In a > somewhat related note, are you aware of any work on getting secure > boot + UEFI working in a guest? There is a PoC patch on OpenXT > (https://github.com/OpenXT/xenclient-oe/pull/729) but was wondering if > there are any parallel efforts ongoing. I do not follow this issue in detail. However, I suppose that if OVMF supports UEFI secure boot (well, QEMU has to enable SMM support too; I do not know does it work with Xen or not) then guest should work without any issue. Just guessing... Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header
>>> On 04.09.17 at 12:35, wrote: > On 04/09/17 11:15, Jan Beulich wrote: > On 04.09.17 at 10:17, wrote: >>> On 03/09/17 10:38, Nicolas Iooss wrote: Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until shared_info is initialized") moved xen_init_time_ops() from __init to __ref without updating xen-ops.h accordingly. Fix this. Fixes: d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until shared_info is initialized") Signed-off-by: Nicolas Iooss --- arch/x86/xen/xen-ops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index 0d5004477db6..b2a5d48a2c2a 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -69,7 +69,7 @@ void xen_setup_runstate_info(int cpu); void xen_teardown_timer(int cpu); u64 xen_clocksource_read(void); void xen_setup_cpu_clockevents(void); -void __init xen_init_time_ops(void); +void __ref xen_init_time_ops(void); void __init xen_hvm_init_time_ops(void); >>> When correcting this could you please modify the prototypes to comply to >>> the intended form as noted in include/linux/init.h (the __ref or __init >>> annotations should be just before the ending semicolon)? >> Why would these annotations be kept on the declarations anyway? >> Attributes affecting code/data placement generally belong on the >> definitions only. > > Because: > > a) That’s what the coding style says, and > > b) So various static analysis can be done (e.g. sparse) on an individual > translation unit basis. > > > Your objection to having annotations on declarations is why I've never > got around to adding sparse to the hypervisor build. Would you mind educating me what use these annotations can be for static analysis? If they're useful in headers, I would stop objecting to them being added there, but I'd then demand for them to never be present on non-static definitions (unless there are attributes where the compiler requires them to be repeated, but I think all attributes are cumulative). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header
On 04/09/17 13:41, Jan Beulich wrote: On 04.09.17 at 12:35, wrote: >> On 04/09/17 11:15, Jan Beulich wrote: >> On 04.09.17 at 10:17, wrote: On 03/09/17 10:38, Nicolas Iooss wrote: > Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until > shared_info is initialized") moved xen_init_time_ops() from __init to > __ref without updating xen-ops.h accordingly. Fix this. > > Fixes: d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until > shared_info is initialized") > Signed-off-by: Nicolas Iooss > --- > arch/x86/xen/xen-ops.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h > index 0d5004477db6..b2a5d48a2c2a 100644 > --- a/arch/x86/xen/xen-ops.h > +++ b/arch/x86/xen/xen-ops.h > @@ -69,7 +69,7 @@ void xen_setup_runstate_info(int cpu); > void xen_teardown_timer(int cpu); > u64 xen_clocksource_read(void); > void xen_setup_cpu_clockevents(void); > -void __init xen_init_time_ops(void); > +void __ref xen_init_time_ops(void); > void __init xen_hvm_init_time_ops(void); When correcting this could you please modify the prototypes to comply to the intended form as noted in include/linux/init.h (the __ref or __init annotations should be just before the ending semicolon)? >>> Why would these annotations be kept on the declarations anyway? >>> Attributes affecting code/data placement generally belong on the >>> definitions only. >> Because: >> >> a) That’s what the coding style says, and >> >> b) So various static analysis can be done (e.g. sparse) on an individual >> translation unit basis. >> >> >> Your objection to having annotations on declarations is why I've never >> got around to adding sparse to the hypervisor build. > Would you mind educating me what use these annotations can be > for static analysis? If they're useful in headers, I would stop > objecting to them being added there, but I'd then demand for them > to never be present on non-static definitions (unless there are > attributes where the compiler requires them to be repeated, but I > think all attributes are cumulative). For one, finding calls to __init functions from non __init functions. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
>>> On 04.09.17 at 12:42, wrote: > On 04/09/17 11:09, Jan Beulich wrote: > On 01.09.17 at 19:07, wrote: >>> Having all of this logic together makes it easier to follow Xen's virtual >>> setup across the whole system. >>> >>> No practical changes to the resulting L4, although the logic has been >>> rearanged to avoid rewriting some slots. This changes the zap_ro_mpt >>> parameter to simply ro_mpt. Another side effect is that highmem-start= is >>> applied consistently to all L4 tables, not just PV ones. >> Is this side effect really a good idea to have? > > Yes. Otherwise the value of highmem-start= as a debugging mechanism is > rather stunted. Why? When it was introduced it was supposed to allow debugging issues with the partial PV directmap vs the always-full HVM/idle one. >> I.e. are you certain >> HVM-only code (i.e. such known to only ever run in HVM or idle >> vCPU context) is all prepared to not have everything direct- >> mapped, and is using map_domain_page() et al everywhere? > > I'm not aware of any places which would violate this. Then again, as > highmem-start= is too bitrotten to function, I can't test. I'll see to look into what's broken. >>> +void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, >>> + const struct domain *d, mfn_t sl4mfn, bool ro_mpt) >>> +{ >>> +/* Slot 256: RO M2P (if applicable). */ >>> +l4t[l4_table_offset(RO_MPT_VIRT_START)] = >>> +ro_mpt ? idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)] >>> + : l4e_empty(); >> While the patch in general looks correct, I'm also not convinced >> having the slot numbers here as well as doing the operation in an >> open-coded slot-by-slot fashion is a good idea: The comments >> and the intended ordering here can easily go stale with future >> adjustments to the virtual address layout. > > The point of having all of this in one place is that there is only one > place to change if the virtual address layout changes, so the chances of > it getting stale are reduced. > > The slot-by-slot fashion is how the old function was implemented after > optimisation, except this version is shorter because we don't rewrite > several slots. Well, I certainly did assume the compiler would make this slot-by- slot either way, so my concern is solely with how the source is looking. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build
>>> On 04.09.17 at 13:33, wrote: > I have investigated this further and have made the following > discoveries: > > 1. make distinguishes targets purely textually. It will canonicalise a > target name by removing ./ before comparison (so `foo' and `./foo' > are considered the same target) but it won't examine the filesystem > AFAICT. So `foo' and `../../this/subdir/foo' are different targets. > (You seem to have already observed or known this.) > > 2. If you use gcc -MMD to generate a .d file, and say -I. to include > things from the cwd, but invoke gcc to compile a file elsewhere, eg > gcc -MMD -I -o build.o /other/path/build.c > and build.c #includes `foo.h', then the -MMD output mentions > `/absolute/path/to/this/subdir/foo.h', even though it could refer > to `foo.h'. (VPATH and vpath are obvious ways for this to happen.) > This is presumably because gcc has noticed that `.' in this context > must mean relative to the invocation cwd, not relative to build.c. > > 3. If foo.h is autogenerated using some kind of pattern rule, > you end up with two `copies' of the rule, which can run > simultaneously, once for build.c -> build.o and once for normal > files in the same cwd. > > I think (2) is a bug in gcc. But we can't sensibly expect to fix > that. Sadly I think the right fix is to seddery the pointless paths > out of the .d files. > > I don't think going round all our Makefiles adding rules of the form >$(ABS_PATH_TO_HERE)/auto-%-generated.: auto-%-generated.h > is sensible. There are too many and this is too ad-hoc. Well, the absolute paths in there are a problem only when compiling files from a different subdirectory. Is that something that happens in many places? I would agree to the sed approach you suggest if this was a widespread problem, but I don't think it is (and hence I went this other route). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header
>>> On 04.09.17 at 14:43, wrote: > On 04/09/17 13:41, Jan Beulich wrote: > On 04.09.17 at 12:35, wrote: >>> On 04/09/17 11:15, Jan Beulich wrote: >>> On 04.09.17 at 10:17, wrote: > On 03/09/17 10:38, Nicolas Iooss wrote: >> Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until >> shared_info is initialized") moved xen_init_time_ops() from __init to >> __ref without updating xen-ops.h accordingly. Fix this. >> >> Fixes: d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until >> shared_info is initialized") >> Signed-off-by: Nicolas Iooss >> --- >> arch/x86/xen/xen-ops.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h >> index 0d5004477db6..b2a5d48a2c2a 100644 >> --- a/arch/x86/xen/xen-ops.h >> +++ b/arch/x86/xen/xen-ops.h >> @@ -69,7 +69,7 @@ void xen_setup_runstate_info(int cpu); >> void xen_teardown_timer(int cpu); >> u64 xen_clocksource_read(void); >> void xen_setup_cpu_clockevents(void); >> -void __init xen_init_time_ops(void); >> +void __ref xen_init_time_ops(void); >> void __init xen_hvm_init_time_ops(void); > When correcting this could you please modify the prototypes to comply to > the intended form as noted in include/linux/init.h (the __ref or __init > annotations should be just before the ending semicolon)? Why would these annotations be kept on the declarations anyway? Attributes affecting code/data placement generally belong on the definitions only. >>> Because: >>> >>> a) That’s what the coding style says, and >>> >>> b) So various static analysis can be done (e.g. sparse) on an individual >>> translation unit basis. >>> >>> >>> Your objection to having annotations on declarations is why I've never >>> got around to adding sparse to the hypervisor build. >> Would you mind educating me what use these annotations can be >> for static analysis? If they're useful in headers, I would stop >> objecting to them being added there, but I'd then demand for them >> to never be present on non-static definitions (unless there are >> attributes where the compiler requires them to be repeated, but I >> think all attributes are cumulative). > > For one, finding calls to __init functions from non __init functions. Hmm, that's been solved differently on Linux, so I wouldn't have assumed this is something to use sparse for. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] ARM64:Porting xen to new hardware
Hi Bharat On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil wrote: > Hello Oleksandr, > > I have corrected GIC settings but no success.Following line disappear from > log. >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000 > > Is anything else which can I try. > > I don’t know much about xen internal for ARM architecture. As you mentioned, >>>Wrong GIC settings might lead to that IPIs won't work as expected. And >>>boot CPU will get stuck waiting for another CPU. > > Can you explain it with some boot sequence and relation with IPI? Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at smp_call_function (one CPU didn't receive interrupt from another one). Next patch helped us to fix this issue: https://patchwork.kernel.org/patch/9163065/ I assume the SoC you are working with has "arm,gic-400" compatible GIC. Can you take a look at the patch, maybe it is your case too. > > Thanks, > Bharat > > > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko > wrote: >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil wrote: >> > Hello Oleksandr, >> Hi Bharat >> >> > >> > I had removed A72 cluster and tried to boot only two A35 but I got same >> > error. >> > >> > Is anything added or missing in A35 compare to A53? >> Unfortunately, I don't know. >> >> BTW, did you check your GIC settings in the device-tree? >> >> > >> > Regards, >> > Bharat >> > >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil >> > wrote: >> >> >> >> Hello Oleksandr, >> >> Thank you very much for your input. >> >> >> >> Yes. agree. I will check by removing A72 core from DT. >> >> >> >> Thanks, >> >> Bharat >> >> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko >> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> Not sure that I am a competent person, just my assumptions. >> >>> >> >>> CCed ARM guys. >> >>> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil >> >>> wrote: >> >>> > Hello All >> >>> > >> >>> > I am trying to run Xen on new hardware which has two A35 and one A72 >> >>> > core. >> >>> > Xen booted intially but it hangs at >> >>> > smp_call_function(setup_virt_paging_one, >> >>> > (void *)val, 1) function call. >> >>> >> >>> It might be a consequence of that CPU cores are different. And they >> >>> might have different set of features, or even settings. >> >>> And these features/settings the boot CPU has don't compatible with >> >>> other (non-boot) CPUs. >> >>> Can you try not to bringup A72 core (remove it from DT or another >> >>> way), leave only two A35 and see what will happen. >> >>> >> >>> > Find following log of Xen booting,same set of features. >> >>> > >> >>> > - UART enabled - >> >>> > - CPU booting - >> >>> > - Current EL 0008 - >> >>> > - Xen starting at EL2 - >> >>> > - Zero BSS - >> >>> > - Setting up control registers - >> >>> > - Turning on paging - >> >>> > - Ready - >> >>> > (XEN) Checking for initrd in /chosen >> >>> > (XEN) RAM: 4000 - bfff >> >>> > (XEN) >> >>> > (XEN) MODULE[0]: 4400 - 4400fd5a Device Tree >> >>> > (XEN) >> >>> > (XEN) Command line: >> >>> Why? Does your device-tree have bootargs? >> >>> >> >>> > (XEN) Placing Xen at 0xbfe0-0xc000 >> >>> > (XEN) Update BOOTMOD_XEN from 4008-40194e01 => >> >>> > bfe01 >> >>> > (XEN) Domain heap initialised >> >>> > (XEN) Booting using Device Tree >> >>> > (XEN) Platform: Generic System >> >>> > (XEN) Taking dtuart configuration from /chosen/stdout-path >> >>> > (XEN) Looking for dtuart at "serial0", options "" >> >>> > __ ___ __ ___ __ >> >>> > _ >> >>> > \ \/ /___ _ __ | || | / |/ _ \_ _ _ __ ___| |_ __ _| |__ >> >>> > | | >> >>> > ___ >> >>> > \ // _ \ '_ \ | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ >> >>> > \| >> >>> > |/ _ \ >> >>> > / \ __/ | | | |__ _|| | |_| |__| |_| | | | \__ \ || (_| | |_) >> >>> > | | >> >>> > __/ >> >>> > /_/\_\___|_| |_||_|(_)_|\___/\__,_|_| >> >>> > |_|___/\__\__,_|_.__/|_|\___| >> >>> > >> >>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc >> >>> > (Ubuntu/Linaro7 >> >>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100 >> >>> > git:9053a74-dirty >> >>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04, >> >>> > rev >> >>> > 0x1 >> >>> > (XEN) 64-bit Execution: >> >>> > (XEN) Processor Features: >> >>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >> >>> > (XEN) Extensions: FloatingPoint AdvancedSIMD >> >>> > (XEN) Debug Features: 10305106 >> >>> > (XEN) Auxiliary Features: >> >>> > (XEN) Memory Model Features: 00101122 >> >>> > (XEN) ISA Features: 00011120 >> >>> > (XEN) 32-bit Execution: >> >>> > (XEN) Processor Features: 0131:00011011 >> >>> > (XEN) Instruction Se
Re: [Xen-devel] [RFC PATCH V2 3/4] hvmload: Add x2apic entry support in the MADT build
>>> On 04.09.17 at 13:12, wrote: > On Mon, Sep 04, 2017 at 06:59:24PM +0800, Lan Tianyu wrote: >> On 2017年09月01日 17:57, Roger Pau Monné wrote: >> > On Thu, Aug 31, 2017 at 01:01:48AM -0400, Lan Tianyu wrote: >> >> @@ -92,7 +92,12 @@ static struct acpi_20_madt *construct_madt(struct >> >> acpi_ctxt *ctxt, >> >> sz = sizeof(struct acpi_20_madt); >> >> sz += sizeof(struct acpi_20_madt_intsrcovr) * 16; >> >> sz += sizeof(struct acpi_20_madt_ioapic); >> >> -sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus; >> >> + >> >> +if (hvminfo->nr_vcpus < 128) >> > >> > This should be done based on APIC ID. >> >> There will be a problem how to get max apic id. Should we use the max >> vcpu index to get max APIC id? > > IMHO, this should become a loop that iterates over each vCPU getting > it's APIC ID, and add either a lapic or x2apic struct size to sz. Indeed. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: use put_page_type_preemptible in put_page_from_l{3, 4}e
>>> On 04.09.17 at 13:42, wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -1376,7 +1376,7 @@ static int put_page_from_l3e(l3_pgentry_t l3e, unsigned > long pfn, > if ( unlikely(partial > 0) ) > { > ASSERT(!defer); > -return __put_page_type(pg, 1); > +return put_page_type_preemptible(pg); > } > > if ( defer ) > @@ -1399,7 +1399,7 @@ static int put_page_from_l4e(l4_pgentry_t l4e, unsigned > long pfn, > if ( unlikely(partial > 0) ) > { > ASSERT(!defer); > -return __put_page_type(pg, 1); > +return put_page_type_preemptible(pg); > } Is this really a good idea? put_page_type_preemptible() is just a thin wrapper around __put_page_type(), so that the latter can remain private to mm.c. By going through the wrapper you add another branch into a path that I would guess isn't executed frequently enough for its constituents to remain in the uops cache, but possibly frequently enough for the extra branch to matter. Otoh I see we use get_page_type_preemptible() in mm.c too in two places (albeit that one also has an extra ASSERT())... Bottom line - since you've got Andrew's approval, I don't mean to outright object to the change, but I like this extra aspect to be taken into account before deciding whether to really put it in. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: use put_page_type_preemptible in put_page_from_l{3, 4}e
On Mon, Sep 04, 2017 at 07:06:51AM -0600, Jan Beulich wrote: > >>> On 04.09.17 at 13:42, wrote: > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -1376,7 +1376,7 @@ static int put_page_from_l3e(l3_pgentry_t l3e, > > unsigned long pfn, > > if ( unlikely(partial > 0) ) > > { > > ASSERT(!defer); > > -return __put_page_type(pg, 1); > > +return put_page_type_preemptible(pg); > > } > > > > if ( defer ) > > @@ -1399,7 +1399,7 @@ static int put_page_from_l4e(l4_pgentry_t l4e, > > unsigned long pfn, > > if ( unlikely(partial > 0) ) > > { > > ASSERT(!defer); > > -return __put_page_type(pg, 1); > > +return put_page_type_preemptible(pg); > > } > > Is this really a good idea? put_page_type_preemptible() is just > a thin wrapper around __put_page_type(), so that the latter > can remain private to mm.c. By going through the wrapper you > add another branch into a path that I would guess isn't executed > frequently enough for its constituents to remain in the uops > cache, but possibly frequently enough for the extra branch to > matter. Otoh I see we use get_page_type_preemptible() in mm.c > too in two places (albeit that one also has an extra ASSERT())... > This patch is taken from my mm.c refactoring series. Like you said, __put_page_type should remain private to mm.c. By making this change I can move put_page_from_l{2,3,4}e to pv/mm.c and leave __put_page_type in mm.c. Is this a good enough reason for you? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: use put_page_type_preemptible in put_page_from_l{3, 4}e
>>> On 04.09.17 at 15:13, wrote: > On Mon, Sep 04, 2017 at 07:06:51AM -0600, Jan Beulich wrote: >> >>> On 04.09.17 at 13:42, wrote: >> > --- a/xen/arch/x86/mm.c >> > +++ b/xen/arch/x86/mm.c >> > @@ -1376,7 +1376,7 @@ static int put_page_from_l3e(l3_pgentry_t l3e, > unsigned long pfn, >> > if ( unlikely(partial > 0) ) >> > { >> > ASSERT(!defer); >> > -return __put_page_type(pg, 1); >> > +return put_page_type_preemptible(pg); >> > } >> > >> > if ( defer ) >> > @@ -1399,7 +1399,7 @@ static int put_page_from_l4e(l4_pgentry_t l4e, > unsigned long pfn, >> > if ( unlikely(partial > 0) ) >> > { >> > ASSERT(!defer); >> > -return __put_page_type(pg, 1); >> > +return put_page_type_preemptible(pg); >> > } >> >> Is this really a good idea? put_page_type_preemptible() is just >> a thin wrapper around __put_page_type(), so that the latter >> can remain private to mm.c. By going through the wrapper you >> add another branch into a path that I would guess isn't executed >> frequently enough for its constituents to remain in the uops >> cache, but possibly frequently enough for the extra branch to >> matter. Otoh I see we use get_page_type_preemptible() in mm.c >> too in two places (albeit that one also has an extra ASSERT())... >> > > This patch is taken from my mm.c refactoring series. > > Like you said, __put_page_type should remain private to mm.c. By making > this change I can move put_page_from_l{2,3,4}e to pv/mm.c and leave > __put_page_type in mm.c. Is this a good enough reason for you? Ah, I see, that's fine then. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] x86/p2m-pt: simplify p2m_next_level()
On 08/11/2017 02:19 PM, Jan Beulich wrote: > Calculate entry PFN and flags just once. Convert the two successive > main if()-s to and if/else-if chain. Restrict variable scope where > reasonable. Take the opportunity and also make the induction variable > unsigned. > > This at once fixes excessive permissions granted in the 2M PTEs > resulting from splitting a 1G one - original permissions should be > inherited instead. This is not a security issue only because all of > this takes no effect anyway, as iommu_hap_pt_share is always false on > AMD systems for all supported branches. > > Signed-off-by: Jan Beulich Acked-by: George Dunlap Sorry for the delay. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build
Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): > Well, the absolute paths in there are a problem only when compiling > files from a different subdirectory. Is that something that happens > in many places? It seems to be not wholly uncommon in xen.git, primarily because of a desire to build the same code for execution in userland and in the hypervisor (or guest firmware images or similar). So far we have mariner:xen.git> git-grep '^vpath' | wc -l 8 and that clearly leaves some out because it contains none of the hypervisor instances. And my key point is that the need for a workaround is not the fault of the autogenerated .h files. Your proposed workaround needs adjusting every time the set of autogenerated .h files (or the set of Makefiles which make .h files) changes. I would like to make a single change which will always work. After all we have no way to automatically verify that we don't have bugs of this form, and when we do write a bug of this form it's a race bug (and race bugs are horrible to find and debug). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list
On Thu, Aug 31, 2017 at 10:36:01AM +0100, Paul Durrant wrote: > A subsequent patch will remove the current implicit limitation on creation > of ioreq servers which is due to the allocation of gfns for the ioreq > structures and buffered ioreq ring. > > It will therefore be necessary to introduce an explicit limit and, since > this limit should be small, it simplifies the code to maintain an array of > that size rather than using a list. > > Also, by reserving an array slot for the default server and populating > array slots early in create, the need to pass an 'is_default' boolean > to sub-functions can be avoided. > > Signed-off-by: Paul Durrant > --- > Cc: Jan Beulich > Cc: Andrew Cooper > > v3: > - New patch (replacing "move is_default into struct hvm_ioreq_server") in >response to review comments. > --- > xen/arch/x86/hvm/ioreq.c | 507 > +++ > xen/include/asm-x86/hvm/domain.h | 11 +- > 2 files changed, 247 insertions(+), 271 deletions(-) > > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c > index 5e01e1a6d2..0e92763384 100644 > --- a/xen/arch/x86/hvm/ioreq.c > +++ b/xen/arch/x86/hvm/ioreq.c > @@ -46,14 +46,18 @@ static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, > struct vcpu *v) > bool hvm_io_pending(struct vcpu *v) > { > struct domain *d = v->domain; > -struct hvm_ioreq_server *s; > +unsigned int id; > > -list_for_each_entry ( s, > - &d->arch.hvm_domain.ioreq_server.list, > - list_entry ) > +for ( id = 0; id < MAX_NR_IOREQ_SERVERS; id++ ) > { > +struct hvm_ioreq_server *s; > struct hvm_ioreq_vcpu *sv; > > +s = d->arch.hvm_domain.ioreq_server.server[id]; > + No need for the extra newline IMHO (here and below). You could also do the initialization together with the definition, but I guess that's going to exceed the line char limit? Or even you could do something like this AFAICT: for ( id = 0, s = d->arch.hvm_domain.ioreq_server.server[0]; id < MAX_NR_IOREQ_SERVERS; id++, s = d->arch.hvm_domain.ioreq_server.server[id] ) { I would make this a macro (FOREACH_IOREQ_SERVER or similar), since the pattern seems to be repeated in quite a lot of places. > +#define IS_DEFAULT(s) \ > +(s == s->domain->arch.hvm_domain.ioreq_server.server[DEFAULT_IOSERVID]) Parentheses around the instances of s please. > static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s, > -bool is_default) > +ioservid_t id) You could get the id by doing some arithmetic with the array and s, but I don't think that's worth it. > int hvm_create_ioreq_server(struct domain *d, domid_t domid, > @@ -685,52 +667,66 @@ int hvm_create_ioreq_server(struct domain *d, domid_t > domid, > ioservid_t *id) > { > struct hvm_ioreq_server *s; > +unsigned int i; > int rc; > > if ( bufioreq_handling > HVM_IOREQSRV_BUFIOREQ_ATOMIC ) > return -EINVAL; > > -rc = -ENOMEM; > s = xzalloc(struct hvm_ioreq_server); > if ( !s ) > -goto fail1; > +return -ENOMEM; > > domain_pause(d); > spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock); > > -rc = -EEXIST; > -if ( is_default && d->arch.hvm_domain.default_ioreq_server != NULL ) > -goto fail2; > - > -rc = hvm_ioreq_server_init(s, d, domid, is_default, bufioreq_handling, > - next_ioservid(d)); > -if ( rc ) > -goto fail3; > - > -list_add(&s->list_entry, > - &d->arch.hvm_domain.ioreq_server.list); > - > if ( is_default ) > { > -d->arch.hvm_domain.default_ioreq_server = s; > -hvm_ioreq_server_enable(s, true); > +i = DEFAULT_IOSERVID; > + > +rc = -EEXIST; > +if ( d->arch.hvm_domain.ioreq_server.server[i] ) > +goto fail; > +} > +else > +{ > +for ( i = 0; i < MAX_NR_IOREQ_SERVERS; i++ ) > +{ > +if ( i != DEFAULT_IOSERVID && > + !d->arch.hvm_domain.ioreq_server.server[i] ) > +break; > +} > + > +rc = -ENOSPC; > +if ( i >= MAX_NR_IOREQ_SERVERS ) > +goto fail; > } > > +d->arch.hvm_domain.ioreq_server.server[i] = s; > + > +rc = hvm_ioreq_server_init(s, d, domid, bufioreq_handling, i); > +if ( rc ) > +goto fail; > + > +if ( IS_DEFAULT(s) ) > +hvm_ioreq_server_enable(s); > + > if ( id ) > -*id = s->id; > +*id = i; > + > +d->arch.hvm_domain.ioreq_server.count++; > > spin_unlock_recursive(&d->arch.hvm_domain.ioreq_server.lock); > domain_unpause(d); > > return 0; > > - fail3: > - fail2: > + fail: > spin_unlock_recursive(&d->arch.hvm_domain.ioreq_server.lock); > domain_u
[Xen-devel] [PATCH 4/4] tools: eliminate LIBXL_BLKTAP2
Use CONFIG_BLKTAP2 directly. There is no reason why one would want to set LIBXL_BLKTAP2 separately as things stand. Signed-off-by: Wei Liu --- Cc: Ian Jackson --- tools/Rules.mk | 4 +--- tools/libxl/Makefile | 2 +- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/tools/Rules.mk b/tools/Rules.mk index 4592601db1..dbc7635112 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -163,9 +163,7 @@ else CFLAGS += -O2 -fomit-frame-pointer endif -LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2) - -ifeq ($(LIBXL_BLKTAP),y) +ifeq ($(CONFIG_BLKTAP2),y) CFLAGS_libblktapctl = -I$(XEN_BLKTAP2)/control -I$(XEN_BLKTAP2)/include $(CFLAGS_xeninclude) SHDEPS_libblktapctl = LDLIBS_libblktapctl = $(SHDEPS_libblktapctl) $(XEN_BLKTAP2)/control/libblktapctl$(libextension) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 082af8f716..bbfc0c0708 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -46,7 +46,7 @@ LIBXL_LIBS += $(LIBXL_LIBS-y) LIBXLU_LIBS = $(LDLIBS_libxenlight) LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o -ifeq ($(LIBXL_BLKTAP),y) +ifeq ($(CONFIG_BLKTAP2),y) LIBXL_OBJS-y += libxl_blktap2.o else LIBXL_OBJS-y += libxl_noblktap2.o -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/4] Orphan and disable blktap2
Make clear that blktap2 is orphaned to set expectation straight. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Wei Liu (4): MAINTAINERS: orphan blktap2 build: run autogen.sh on Stretch tools: disable blktap2 by default tools: eliminate LIBXL_BLKTAP2 MAINTAINERS | 6 -- configure| 14 +- docs/configure | 14 +- stubdom/configure| 28 +++- tools/Rules.mk | 4 +--- tools/configure | 23 +++ tools/configure.ac | 8 ++-- tools/libxl/Makefile | 2 +- 8 files changed, 76 insertions(+), 23 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] build: run autogen.sh on Stretch
Signed-off-by: Wei Liu --- Cc: Ian Jackson --- configure | 14 +- docs/configure| 14 +- stubdom/configure | 28 +++- tools/configure | 14 +- 4 files changed, 66 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 5b4e828b81..5270388e5c 100755 --- a/configure +++ b/configure @@ -643,6 +643,7 @@ infodir docdir oldincludedir includedir +runstatedir localstatedir sharedstatedir sysconfdir @@ -720,6 +721,7 @@ datadir='${datarootdir}' sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' +runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -972,6 +974,15 @@ do | -silent | --silent | --silen | --sile | --sil) silent=yes ;; + -runstatedir | --runstatedir | --runstatedi | --runstated \ + | --runstate | --runstat | --runsta | --runst | --runs \ + | --run | --ru | --r) +ac_prev=runstatedir ;; + -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ + | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ + | --run=* | --ru=* | --r=*) +runstatedir=$ac_optarg ;; + -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1109,7 +1120,7 @@ fi for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir + libdir localedir mandir runstatedir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1262,6 +1273,7 @@ Fine tuning of the installation directories: --sysconfdir=DIRread-only single-machine data [PREFIX/etc] --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] + --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIRobject code libraries [EPREFIX/lib] --includedir=DIRC header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] diff --git a/docs/configure b/docs/configure index a5780d9942..fb346dd787 100755 --- a/docs/configure +++ b/docs/configure @@ -634,6 +634,7 @@ infodir docdir oldincludedir includedir +runstatedir localstatedir sharedstatedir sysconfdir @@ -710,6 +711,7 @@ datadir='${datarootdir}' sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' +runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -962,6 +964,15 @@ do | -silent | --silent | --silen | --sile | --sil) silent=yes ;; + -runstatedir | --runstatedir | --runstatedi | --runstated \ + | --runstate | --runstat | --runsta | --runst | --runs \ + | --run | --ru | --r) +ac_prev=runstatedir ;; + -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ + | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ + | --run=* | --ru=* | --r=*) +runstatedir=$ac_optarg ;; + -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1099,7 +1110,7 @@ fi for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir + libdir localedir mandir runstatedir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1252,6 +1263,7 @@ Fine tuning of the installation directories: --sysconfdir=DIRread-only single-machine data [PREFIX/etc] --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] + --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIRobject code libraries [EPREFIX/lib] --includedir=DIRC header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] diff --git a/stubdom/configure b/stubdom/configure index 8e6e0542be..c4130dc1fd 100755 --- a/stubdom/configure +++ b/stubdom/configure @@ -587,6 +587,7 @@ PACKAGE_URL='http://www.xen.org/' ac_unique_file="xenstore-minios.cfg" ac_subst_vars='LTLIBOBJS LIBOBJS +STUBDOM_UNINSTALL STUBDOM_INSTALL STUBDOM_BUILD STUBDOM_TARGETS @@ -659,6 +660,7 @@ infodir docdir oldincludedir includedir +runstatedir localstatedir sharedstatedir sysconfdir @@ -748,6 +750,7 @@ datadir='${datarootdir}' sysconfdir='$
[Xen-devel] [PATCH 3/4] tools: disable blktap2 by default
Signed-off-by: Wei Liu --- Cc: Ian Jackson --- tools/configure| 9 ++--- tools/configure.ac | 8 ++-- 2 files changed, 4 insertions(+), 13 deletions(-) diff --git a/tools/configure b/tools/configure index 29393a3ad2..f3bb412f51 100755 --- a/tools/configure +++ b/tools/configure @@ -1490,8 +1490,7 @@ Optional Features: --disable-xsmpolicy Disable XSM policy compilation (default is ENABLED) --enable-ovmf Enable OVMF (default is DISABLED) --disable-seabios Disable SeaBIOS (default is ENABLED) - --enable-blktap2Enable blktap2, (DEFAULT is on for Linux, otherwise - off) + --enable-blktap2Enable blktap2, (DEFAULT is off) --enable-qemu-traditional Enable qemu traditional device model, (DEFAULT is on for Linux or NetBSD x86, otherwise off) @@ -4214,11 +4213,7 @@ if test "${enable_blktap2+set}" = set; then : enableval=$enable_blktap2; else -case "$host_os" in -linux*) - enable_blktap2="yes";; -*) enable_blktap2="no";; -esac +enable_blktap2="no" fi diff --git a/tools/configure.ac b/tools/configure.ac index a47d0fdbe6..d1a3a78d87 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -119,12 +119,8 @@ AC_SUBST(LINUX_BACKEND_MODULES) dnl Enable blktap2 on Linux only. AC_ARG_ENABLE([blktap2], AS_HELP_STRING([--enable-blktap2], - [Enable blktap2, (DEFAULT is on for Linux, otherwise off)]),,[ -case "$host_os" in -linux*) - enable_blktap2="yes";; -*) enable_blktap2="no";; -esac + [Enable blktap2, (DEFAULT is off)]),,[ +enable_blktap2="no" ]) AS_IF([test "x$enable_blktap2" = "xyes"], [ AC_DEFINE([HAVE_BLKTAP2], [1], [Blktap2 enabled]) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/4] MAINTAINERS: orphan blktap2
Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- MAINTAINERS | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5b9e1233a8..ca8cbf276e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -175,6 +175,10 @@ F: xen/drivers/char/pl011.c F: xen/drivers/char/scif-uart.c F: xen/drivers/passthrough/arm/ +BLOCKTAP +S: Orphaned +F: tools/blktap2/ + CPU POOLS M: Juergen Gross M: Dario Faggioli @@ -322,8 +326,6 @@ M: Shriram Rajagopalan M: Yang Hongyang S: Maintained F: docs/README.remus -F: tools/blktap2/drivers/block-remus.c -F: tools/blktap2/drivers/hashtable* F: tools/libxl/libxl_remus_* F: tools/libxl/libxl_netbuffer.c F: tools/libxl/libxl_nonetbuffer.c -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 09/12] x86/hvm/ioreq: simplify code and use consistent naming
On Thu, Aug 31, 2017 at 10:36:02AM +0100, Paul Durrant wrote: > This patch re-works much of the ioreq server initialization and teardown > code: > > - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through > to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called > separately by outer functions. > - Several functions now test the validity of the hvm_ioreq_page gfn value > to determine whether they need to act. This means can be safely called > for the bufioreq page even when it is not used. > - hvm_add/remove_ioreq_gfn() simply return in the case of the default > IOREQ server so callers no longer need to test before calling. > - hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages() > to mirror the existing hvm_ioreq_server_unmap_pages(). > > All of this significantly shortens the code. > > Signed-off-by: Paul Durrant > --- > Cc: Jan Beulich > Cc: Andrew Cooper > > v3: > - Rebased on top of 's->is_default' to 'IS_DEFAULT(s)' changes. > - Minor updates in response to review comments from Roger. > --- > xen/arch/x86/hvm/ioreq.c | 188 > ++- > 1 file changed, 72 insertions(+), 116 deletions(-) > > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c > index 0e92763384..fac82ae934 100644 > --- a/xen/arch/x86/hvm/ioreq.c > +++ b/xen/arch/x86/hvm/ioreq.c > @@ -189,63 +189,78 @@ bool handle_hvm_io_completion(struct vcpu *v) > return true; > } > > -static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn) > +#define IS_DEFAULT(s) \ > +(s == s->domain->arch.hvm_domain.ioreq_server.server[DEFAULT_IOSERVID]) Can't the define be placed here in the previous patch? Or I would rather place it just after the includes at the top of the file. For the rest, LGTM: Reviewed-by: Roger Pau Monné Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH 1/6] example/vhost_xen: remove
On Wed, Aug 30, 2017 at 06:10:29PM +, Jianfeng Tan wrote: > Signed-off-by: Jianfeng Tan Minor nit: checkpatch points out that the prefix should be "examples/..." rather than "example/..." Otherwise: Acked-by: Bruce Richardson ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH 2/6] net/xenvirt: remove
On Wed, Aug 30, 2017 at 06:10:30PM +, Jianfeng Tan wrote: > Signed-off-by: Jianfeng Tan > --- > MAINTAINERS | 2 - > app/test-pmd/Makefile | 4 - > app/test-pmd/testpmd.c | 12 - > config/common_base | 5 - > config/defconfig_arm-armv7a-linuxapp-gcc| 1 - > doc/guides/nics/features/xenvirt.ini| 6 - > drivers/net/Makefile| 2 - > drivers/net/xenvirt/Makefile| 57 -- > drivers/net/xenvirt/rte_eth_xenvirt.c | 766 > > drivers/net/xenvirt/rte_eth_xenvirt.h | 61 -- > drivers/net/xenvirt/rte_eth_xenvirt_version.map | 7 - > drivers/net/xenvirt/rte_mempool_gntalloc.c | 295 - > drivers/net/xenvirt/rte_xen_lib.c | 454 -- > drivers/net/xenvirt/rte_xen_lib.h | 116 > drivers/net/xenvirt/virtio_logs.h | 70 --- > drivers/net/xenvirt/virtqueue.h | 273 - > mk/rte.app.mk | 1 - > pkg/dpdk.spec | 3 - > 18 files changed, 2135 deletions(-) > delete mode 100644 doc/guides/nics/features/xenvirt.ini > delete mode 100644 drivers/net/xenvirt/Makefile > delete mode 100644 drivers/net/xenvirt/rte_eth_xenvirt.c > delete mode 100644 drivers/net/xenvirt/rte_eth_xenvirt.h > delete mode 100644 drivers/net/xenvirt/rte_eth_xenvirt_version.map > delete mode 100644 drivers/net/xenvirt/rte_mempool_gntalloc.c > delete mode 100644 drivers/net/xenvirt/rte_xen_lib.c > delete mode 100644 drivers/net/xenvirt/rte_xen_lib.h > delete mode 100644 drivers/net/xenvirt/virtio_logs.h > delete mode 100644 drivers/net/xenvirt/virtqueue.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index fe6c6db..003e72e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -194,9 +194,7 @@ M: Jianfeng Tan > F: lib/librte_eal/linuxapp/xen_dom0/ > F: lib/librte_eal/linuxapp/eal/*xen* > F: lib/librte_eal/linuxapp/eal/include/exec-env/rte_dom0_common.h > -F: drivers/net/xenvirt/ > F: doc/guides/xen/ > -F: doc/guides/nics/features/xenvirt.ini > > FreeBSD EAL (with overlaps) > M: Bruce Richardson > diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile > index c36be19..b6e80dd 100644 > --- a/app/test-pmd/Makefile > +++ b/app/test-pmd/Makefile > @@ -77,10 +77,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_BNXT_PMD),y) > LDLIBS += -lrte_pmd_bnxt > endif > > -ifeq ($(CONFIG_RTE_LIBRTE_PMD_XENVIRT),y) > -LDLIBS += -lrte_pmd_xenvirt > -endif > - > endif > > CFLAGS_cmdline.o := -D_GNU_SOURCE > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c > index 7d40139..f8d02ae 100644 > --- a/app/test-pmd/testpmd.c > +++ b/app/test-pmd/testpmd.c > @@ -76,9 +76,6 @@ > #ifdef RTE_LIBRTE_IXGBE_PMD > #include > #endif > -#ifdef RTE_LIBRTE_PMD_XENVIRT > -#include > -#endif > #ifdef RTE_LIBRTE_PDUMP > #include > #endif > @@ -497,15 +494,6 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned > nb_mbuf, > "create a new mbuf pool <%s>: n=%u, size=%u, socket=%u\n", > pool_name, nb_mbuf, mbuf_seg_size, socket_id); > > -#ifdef RTE_LIBRTE_PMD_XENVIRT > - rte_mp = rte_mempool_gntalloc_create(pool_name, nb_mbuf, mb_size, > - (unsigned) mb_mempool_cache, > - sizeof(struct rte_pktmbuf_pool_private), > - rte_pktmbuf_pool_init, NULL, > - rte_pktmbuf_init, NULL, > - socket_id, 0); > -#endif > - > /* if the former XEN allocation failed fall back to normal allocation */ > if (rte_mp == NULL) { Remove comment and if condition, as there is no way the the variable can be non-null now. /Bruce ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH 3/6] xen: remove xen dependency in app, examples, test
On Wed, Aug 30, 2017 at 06:10:31PM +, Jianfeng Tan wrote: > Signed-off-by: Jianfeng Tan > --- > app/test-pmd/testpmd.c | 2 +- > examples/ip_pipeline/app.h | 4 -- > examples/ip_pipeline/config_parse.c | 19 - > examples/ip_pipeline/init.c | 5 --- > examples/kni/main.c | 3 -- > test/test/process.h | 10 - > test/test/test.c| 4 -- > test/test/test_eal_flags.c | 81 > - > 8 files changed, 1 insertion(+), 127 deletions(-) > > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c > index f8d02ae..d9c785c 100644 > --- a/app/test-pmd/testpmd.c > +++ b/app/test-pmd/testpmd.c > @@ -494,7 +494,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf, > "create a new mbuf pool <%s>: n=%u, size=%u, socket=%u\n", > pool_name, nb_mbuf, mbuf_seg_size, socket_id); > > - /* if the former XEN allocation failed fall back to normal allocation */ > + /* if the former allocation failed fall back to normal allocation */ > if (rte_mp == NULL) { > if (mp_anon != 0) { > rte_mp = rte_mempool_create_empty(pool_name, nb_mbuf, There is no former allocation here, so I think the previous patch, which removed the #ifdef block should also remove this comment entirely, and the "if (rte_mp == NULL)" too ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted
On Thu, Aug 31, 2017 at 10:36:04AM +0100, Paul Durrant wrote: > A subsequent patch will introduce a new scheme to allow an emulator to > map ioreq server pages directly from Xen rather than the guest P2M. > > This patch lays the groundwork for that change by deferring mapping of > gfns until their values are requested by an emulator. To that end, the > pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed > to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the > behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid > requesting the gfn values. > > Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build
>>> On 04.09.17 at 15:33, wrote: > I would like to make a single change which will always work. After > all we have no way to automatically verify that we don't have bugs of > this form, and when we do write a bug of this form it's a race bug > (and race bugs are horrible to find and debug). Well, okay - I take that you're intending to put together such a change then in the not too distant future. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list
>>> On 04.09.17 at 15:40, wrote: > On Thu, Aug 31, 2017 at 10:36:01AM +0100, Paul Durrant wrote: >> void hvm_destroy_all_ioreq_servers(struct domain *d) >> { >> -struct hvm_ioreq_server *s, *next; >> +unsigned int id; >> >> spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock); >> >> /* No need to domain_pause() as the domain is being torn down */ >> >> -list_for_each_entry_safe ( s, >> - next, >> - &d->arch.hvm_domain.ioreq_server.list, >> - list_entry ) >> +for ( id = 0; id < MAX_NR_IOREQ_SERVERS; id++ ) >> { >> -bool is_default = (s == d->arch.hvm_domain.default_ioreq_server); >> +struct hvm_ioreq_server *s; >> >> -hvm_ioreq_server_disable(s, is_default); >> +s = d->arch.hvm_domain.ioreq_server.server[id]; >> >> -if ( is_default ) >> -d->arch.hvm_domain.default_ioreq_server = NULL; >> +if ( !s ) >> +continue; >> >> -list_del(&s->list_entry); >> +hvm_ioreq_server_disable(s); >> +hvm_ioreq_server_deinit(s); >> >> -hvm_ioreq_server_deinit(s, is_default); >> +ASSERT(d->arch.hvm_domain.ioreq_server.count); >> +--d->arch.hvm_domain.ioreq_server.count; > > It seems more common to use d->arch.hvm_domain.ioreq_server.count--, > unless there' a reason for prefixing the decrement. At least for people also writing C++ code every now and then it is certainly more natural to use the prefixing operator. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build
Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): > On 04.09.17 at 15:33, wrote: > > I would like to make a single change which will always work. After > > all we have no way to automatically verify that we don't have bugs of > > this form, and when we do write a bug of this form it's a race bug > > (and race bugs are horrible to find and debug). > > Well, okay - I take that you're intending to put together such a > change then in the not too distant future. Sure, I was indeed volunteering :-). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH 5/6] eal: remove xen dom0 support
On Wed, Aug 30, 2017 at 06:10:33PM +, Jianfeng Tan wrote: > We remove xen-specific code in EAL, including the option --xen-dom0, > memory initialization code, compiling dependency, etc. > > Besides, related documents are removed or updated. > > Signed-off-by: Jianfeng Tan > --- > MAINTAINERS| 7 - > config/common_base | 5 - > doc/guides/index.rst | 1 - > doc/guides/linux_gsg/build_sample_apps.rst | 5 +- > doc/guides/linux_gsg/sys_reqs.rst | 53 -- > doc/guides/prog_guide/source_org.rst | 1 - > doc/guides/rel_notes/deprecation.rst | 3 - > doc/guides/rel_notes/release_17_11.rst | 12 + > doc/guides/testpmd_app_ug/run_app.rst | 4 - > doc/guides/xen/img/dpdk_xen_pkt_switch.png | Bin 163842 -> 0 bytes > doc/guides/xen/img/grant_refs.png | Bin 6405 -> 0 bytes > doc/guides/xen/img/grant_table.png | Bin 96762 -> 0 bytes > doc/guides/xen/index.rst | 38 - > doc/guides/xen/pkt_switch.rst | 470 - > .../bsdapp/eal/include/exec-env/rte_dom0_common.h | 107 --- > lib/librte_eal/common/eal_common_options.c | 3 - > lib/librte_eal/common/eal_internal_cfg.h | 1 - > lib/librte_eal/common/eal_options.h| 2 - > lib/librte_eal/common/include/rte_memory.h | 66 -- > lib/librte_eal/linuxapp/Makefile | 2 - > lib/librte_eal/linuxapp/eal/Makefile | 5 +- > lib/librte_eal/linuxapp/eal/eal.c | 24 - > lib/librte_eal/linuxapp/eal/eal_memory.c | 56 -- > lib/librte_eal/linuxapp/eal/eal_xen_memory.c | 381 -- > .../eal/include/exec-env/rte_dom0_common.h | 108 --- > lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 54 -- > lib/librte_eal/linuxapp/xen_dom0/Makefile | 53 -- > lib/librte_eal/linuxapp/xen_dom0/compat.h | 15 - > lib/librte_eal/linuxapp/xen_dom0/dom0_mm_dev.h | 107 --- > lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c| 780 > - > pkg/dpdk.spec | 3 - The xen functions that were removed are still listed in the linux/bsd version.map files. Not an ABI versioning expert, but I believe they should be removed as they are no longer present. Also, I spot a reference to xen still in doc/guides/contributing/documentation.rst. /Bruce ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 113030: regressions - trouble: blocked/broken/fail/pass
flight 113030 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113030/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail REGR. vs. 113024 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 113024 pass in 113030 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 113024 pass in 113030 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail pass in 113024 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113024 build-arm64-xsm 2 hosts-allocate broken like 113024 build-arm64-xsm 3 capture-logsbroken like 113024 build-arm64-pvops 3 capture-logsbroken like 113024 build-arm64 2 hosts-allocate broken like 113024 build-arm64 3 capture-logsbroken like 113024 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 113024 like 113016 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 113024 like 113016 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 113024 like 113016 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 113024 like 113016 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 113024 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 113024 never pass test-armhf-armhf-xl 13 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 113024 never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 113024 never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 113024 never pass test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 113024 never pass test-armhf-armhf-libvirt13 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 113024 never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 113024 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 113024 never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 113024 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 113024 never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 113016 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 113016 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113024 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113024 test-amd64-amd64-xl-rtds 10 debian-install fail like 113024 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check
[Xen-devel] [xen-unstable-smoke test] 113038: tolerable trouble: broken/pass - PUSHED
flight 113038 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113038/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113035 build-arm64-pvops 3 capture-logsbroken like 113035 build-arm64 2 hosts-allocate broken like 113035 build-arm64 3 capture-logsbroken like 113035 test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen d4ccdcf64aa0a00dd1f2a710c6f4610b9c59cd60 baseline version: xen fdc6cef85734662e32c91fee2a191d2b26a682f4 Last test of basis 113035 2017-09-04 09:02:44 Z0 days Testing same since 113038 2017-09-04 13:02:21 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs Pushing revision : + branch=xen-unstable-smoke + revision=d4ccdcf64aa0a00dd1f2a710c6f4610b9c59cd60 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke d4ccdcf64aa0a00dd1f2a710c6f4610b9c59cd60 + branch=xen-unstable-smoke + revision=d4ccdcf64aa0a00dd1f2a710c6f4610b9c59cd60 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-4.9-testing + '[' xd4ccdcf64aa0a00dd1f2a710c6f4610b9c59cd60 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/xtf.git ++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git ++ : git://xenbits.xen.org/xtf.git +
Re: [Xen-devel] [dpdk-dev] [PATCH 5/6] eal: remove xen dom0 support
On Mon, Sep 04, 2017 at 03:43:02PM +0100, Bruce Richardson wrote: > On Wed, Aug 30, 2017 at 06:10:33PM +, Jianfeng Tan wrote: > > We remove xen-specific code in EAL, including the option --xen-dom0, > > memory initialization code, compiling dependency, etc. > > > > Besides, related documents are removed or updated. > > > > Signed-off-by: Jianfeng Tan > > --- > > MAINTAINERS| 7 - > > config/common_base | 5 - > > doc/guides/index.rst | 1 - > > doc/guides/linux_gsg/build_sample_apps.rst | 5 +- > > doc/guides/linux_gsg/sys_reqs.rst | 53 -- > > doc/guides/prog_guide/source_org.rst | 1 - > > doc/guides/rel_notes/deprecation.rst | 3 - > > doc/guides/rel_notes/release_17_11.rst | 12 + > > doc/guides/testpmd_app_ug/run_app.rst | 4 - > > doc/guides/xen/img/dpdk_xen_pkt_switch.png | Bin 163842 -> 0 bytes > > doc/guides/xen/img/grant_refs.png | Bin 6405 -> 0 bytes > > doc/guides/xen/img/grant_table.png | Bin 96762 -> 0 bytes > > doc/guides/xen/index.rst | 38 - > > doc/guides/xen/pkt_switch.rst | 470 - > > .../bsdapp/eal/include/exec-env/rte_dom0_common.h | 107 --- > > lib/librte_eal/common/eal_common_options.c | 3 - > > lib/librte_eal/common/eal_internal_cfg.h | 1 - > > lib/librte_eal/common/eal_options.h| 2 - > > lib/librte_eal/common/include/rte_memory.h | 66 -- > > lib/librte_eal/linuxapp/Makefile | 2 - > > lib/librte_eal/linuxapp/eal/Makefile | 5 +- > > lib/librte_eal/linuxapp/eal/eal.c | 24 - > > lib/librte_eal/linuxapp/eal/eal_memory.c | 56 -- > > lib/librte_eal/linuxapp/eal/eal_xen_memory.c | 381 -- > > .../eal/include/exec-env/rte_dom0_common.h | 108 --- > > lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 54 -- > > lib/librte_eal/linuxapp/xen_dom0/Makefile | 53 -- > > lib/librte_eal/linuxapp/xen_dom0/compat.h | 15 - > > lib/librte_eal/linuxapp/xen_dom0/dom0_mm_dev.h | 107 --- > > lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c| 780 > > - > > pkg/dpdk.spec | 3 - > > The xen functions that were removed are still listed in the linux/bsd > version.map files. Not an ABI versioning expert, but I believe they > should be removed as they are no longer present. > Reading the contributors guide section on ABI, specifically http://dpdk.org/doc/guides/contributing/versioning.html#deprecating-an-entire-abi-version it seems like we should collapse down the versions to a single one following the function removal, and also increment the whole library so version. /Bruce ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH 2/6] net/xenvirt: remove
On Mon, Sep 04, 2017 at 03:25:48PM +0100, Bruce Richardson wrote: > On Wed, Aug 30, 2017 at 06:10:30PM +, Jianfeng Tan wrote: > > Signed-off-by: Jianfeng Tan > > --- > > MAINTAINERS | 2 - > > app/test-pmd/Makefile | 4 - > > app/test-pmd/testpmd.c | 12 - > > config/common_base | 5 - > > config/defconfig_arm-armv7a-linuxapp-gcc| 1 - > > doc/guides/nics/features/xenvirt.ini| 6 - > > drivers/net/Makefile| 2 - > > drivers/net/xenvirt/Makefile| 57 -- > > drivers/net/xenvirt/rte_eth_xenvirt.c | 766 > > > > drivers/net/xenvirt/rte_eth_xenvirt.h | 61 -- > > drivers/net/xenvirt/rte_eth_xenvirt_version.map | 7 - > > drivers/net/xenvirt/rte_mempool_gntalloc.c | 295 - > > drivers/net/xenvirt/rte_xen_lib.c | 454 -- > > drivers/net/xenvirt/rte_xen_lib.h | 116 > > drivers/net/xenvirt/virtio_logs.h | 70 --- > > drivers/net/xenvirt/virtqueue.h | 273 - > > mk/rte.app.mk | 1 - > > pkg/dpdk.spec | 3 - > > 18 files changed, 2135 deletions(-) > > delete mode 100644 doc/guides/nics/features/xenvirt.ini > > delete mode 100644 drivers/net/xenvirt/Makefile > > delete mode 100644 drivers/net/xenvirt/rte_eth_xenvirt.c > > delete mode 100644 drivers/net/xenvirt/rte_eth_xenvirt.h > > delete mode 100644 drivers/net/xenvirt/rte_eth_xenvirt_version.map > > delete mode 100644 drivers/net/xenvirt/rte_mempool_gntalloc.c > > delete mode 100644 drivers/net/xenvirt/rte_xen_lib.c > > delete mode 100644 drivers/net/xenvirt/rte_xen_lib.h > > delete mode 100644 drivers/net/xenvirt/virtio_logs.h > > delete mode 100644 drivers/net/xenvirt/virtqueue.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index fe6c6db..003e72e 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -194,9 +194,7 @@ M: Jianfeng Tan > > F: lib/librte_eal/linuxapp/xen_dom0/ > > F: lib/librte_eal/linuxapp/eal/*xen* > > F: lib/librte_eal/linuxapp/eal/include/exec-env/rte_dom0_common.h > > -F: drivers/net/xenvirt/ > > F: doc/guides/xen/ > > -F: doc/guides/nics/features/xenvirt.ini > > > > FreeBSD EAL (with overlaps) > > M: Bruce Richardson > > diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile > > index c36be19..b6e80dd 100644 > > --- a/app/test-pmd/Makefile > > +++ b/app/test-pmd/Makefile > > @@ -77,10 +77,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_BNXT_PMD),y) > > LDLIBS += -lrte_pmd_bnxt > > endif > > > > -ifeq ($(CONFIG_RTE_LIBRTE_PMD_XENVIRT),y) > > -LDLIBS += -lrte_pmd_xenvirt > > -endif > > - > > endif > > > > CFLAGS_cmdline.o := -D_GNU_SOURCE > > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c > > index 7d40139..f8d02ae 100644 > > --- a/app/test-pmd/testpmd.c > > +++ b/app/test-pmd/testpmd.c > > @@ -76,9 +76,6 @@ > > #ifdef RTE_LIBRTE_IXGBE_PMD > > #include > > #endif > > -#ifdef RTE_LIBRTE_PMD_XENVIRT > > -#include > > -#endif > > #ifdef RTE_LIBRTE_PDUMP > > #include > > #endif > > @@ -497,15 +494,6 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned > > nb_mbuf, > > "create a new mbuf pool <%s>: n=%u, size=%u, socket=%u\n", > > pool_name, nb_mbuf, mbuf_seg_size, socket_id); > > > > -#ifdef RTE_LIBRTE_PMD_XENVIRT > > - rte_mp = rte_mempool_gntalloc_create(pool_name, nb_mbuf, mb_size, > > - (unsigned) mb_mempool_cache, > > - sizeof(struct rte_pktmbuf_pool_private), > > - rte_pktmbuf_pool_init, NULL, > > - rte_pktmbuf_init, NULL, > > - socket_id, 0); > > -#endif > > - > > /* if the former XEN allocation failed fall back to normal allocation */ > > if (rte_mp == NULL) { > > Remove comment and if condition, as there is no way the the variable can > be non-null now. > With this change: Acked-by: Bruce Richardson ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH 3/6] xen: remove xen dependency in app, examples, test
On Wed, Aug 30, 2017 at 06:10:31PM +, Jianfeng Tan wrote: > Signed-off-by: Jianfeng Tan > --- Acked-by: Bruce Richardson ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel