Re: [Xen-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

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

[Chao Gao]

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

[Sergey Dyasli]

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

[Sergey Dyasli]

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()

[Sergey Dyasli]

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()

[Sergey Dyasli]

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()

[Sergey Dyasli]

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

[Sergey Dyasli]

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()

[Sergey Dyasli]

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()

[Sergey Dyasli]

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

[Sergey Dyasli]

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

[Sergey Dyasli]

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()

[Sergey Dyasli]

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

[Sergey Dyasli]

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()

[Sergey Dyasli]

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()

[Sergey Dyasli]

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

[Juergen Gross]

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()

[Sergey Dyasli]

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

[Wei Liu]

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

[Platform Team regression test user]

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

[Wei Liu]

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

[Jan Beulich]

>>> 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

[Wei Liu]

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

[George Dunlap]

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

[Jan Beulich]

>>> 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

[Wei Liu]

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

[Roger Pau Monné]

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

[Roger Pau Monné]

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

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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'

[Wei Liu]

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

[Yi Sun]

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

[Wei Liu]

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

[Roger Pau Monné]

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

[Roger Pau Monné]

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()

[Andrew Cooper]

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

[Roger Pau Monné]

(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

[Jan Beulich]

>>> 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

[Chao Gao]

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

[Sergej Proskurin]

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()

[Andrew Cooper]

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()

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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

[osstest service owner]

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

[Jan Beulich]

>>> 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

[Juergen Gross]

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()

[Jan Beulich]

>>> 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

[Andrew Cooper]

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

[osstest service owner]

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()

[Andrew Cooper]

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()

[Wei Liu]

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

[Roger Pau Monné]

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

[Roger Pau Monné]

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

[osstest service owner]

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

[Ian Jackson]

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

[Lan Tianyu]

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

[Roger Pau Monné]

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

[Roger Pau Monné]

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

[Yi Sun]

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

[Lan Tianyu]

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'

[Yi Sun]

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

[Ian Jackson]

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

[Wei Liu]

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

[Wei Liu]

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

[Andrew Cooper]

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()

[Andrew Cooper]

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

[Platform Team regression test user]

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

[Daniel Kiper]

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

[Jan Beulich]

>>> 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

[Andrew Cooper]

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()

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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

[Oleksandr Tyshchenko]

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

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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

[Wei Liu]

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

[Jan Beulich]

>>> 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()

[George Dunlap]

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

[Ian Jackson]

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

[Roger Pau Monné]

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

[Wei Liu]

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

[Wei Liu]

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

[Wei Liu]

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

[Wei Liu]

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

[Wei Liu]

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

[Roger Pau Monné]

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

[Bruce Richardson]

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

[Bruce Richardson]

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

[Bruce Richardson]

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

[Roger Pau Monné]

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

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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

[Ian Jackson]

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

[Bruce Richardson]

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

[osstest service owner]

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

[osstest service owner]

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

[Bruce Richardson]

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

[Bruce Richardson]

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

[Bruce Richardson]

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