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

[osstest service owner]

flight 101017 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101017/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101010
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101010
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101010

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuu3d47a1390bd80b7b974185827a340012d21ad1e3
baseline version:
 qemuu0f2fa73ba0ca19ebdaccf0d1785583d6601411b6

Last test of basis   101010  2016-09-19 11:14:06 Z0 days
Testing same since   101017  2016-09-19 17:22:00 Z0 days1 attempts


People who touched revisions under test:
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  Greg Kurz 
  Peter Maydell 
  Pierre Morel 
  Sascha Silbe 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl 

[Xen-devel] [PATCH V2] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[van . freenix]

From: Peng Fan 

On AArch64 SoCs, some IPs may only have the capability to access
32bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.
So need to allocate memory under 4GB for Dom0.

There is no restriction that how much lowmem needs to be allocated for
Dom0. Dom0 now use 1:1 mapping, but DomU does not use 1:1 mapping,
there is no need to reserve lowmem for DomU, so allocate lowmem as much
as possible for Dom0.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html

V2:
 Remove the bootargs dom0_lowmem introduced in V1.
 Following 
"https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01459.html;
 to allocate as much as possible lowmem.

 Tested results:
 (XEN) Allocating 1:1 mappings totalling 2048MB for dom0:
 (XEN) BANK[0] 0x008800-0x00f800 (1792MB)
 (XEN) BANK[1] 0x09e000-0x09f000 (256MB)
 1792M allocated in 4GB address space.

 xen/arch/arm/domain_build.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..0b9b85c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -240,11 +240,11 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 const unsigned int min_low_order =
 get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
 const unsigned int min_order = get_order_from_bytes(MB(4));
-struct page_info *pg;
+struct page_info *pg = NULL;
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 int i;
 
-bool_t lowmem = is_32bit_domain(d);
+bool_t lowmem = true;
 unsigned int bits;
 
 /*
@@ -265,22 +265,28 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
  */
 while ( order >= min_low_order )
 {
-for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
+for ( bits = order ; bits <= 32 ; bits++ )
 {
 pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
 if ( pg != NULL )
+{
+if ( !insert_11_bank(d, kinfo, pg, order) )
+BUG(); /* Cannot fail for first bank */
+
 goto got_bank0;
+   }
 }
 order--;
 }
 
-panic("Unable to allocate first memory bank");
+if ( pg == NULL )
+{
+printk(XENLOG_INFO "No bank has been allocated below 4GB.\n");
+lowmem = false;
+}
 
  got_bank0:
 
-if ( !insert_11_bank(d, kinfo, pg, order) )
-BUG(); /* Cannot fail for first bank */
-
 /* Now allocate more memory and fill in additional banks */
 
 order = get_11_allocation_size(kinfo->unassigned_mem);
-- 
2.6.6


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

[Wei Yang]

On Tue, Sep 20, 2016 at 01:24:17AM +0200, Dario Faggioli wrote:
>On Sat, 2016-09-17 at 00:31 +, Wei Yang wrote:
>> On Fri, Sep 16, 2016 at 06:07:08PM +0200, Dario Faggioli wrote:
>> > But then again, if the system is not oversubscribed, I'd tend to
>> > think
>> > it to be tolerable, and I'd expect the biggest problem to be the
>> > work-
>> > stealing logic (considering the high number of pcpus), rather than
>> > the
>> > duration of the critical sections within vcpu_wake().
>> > 
>> Yes, we are trying to improve the stealing part too.
>> 
>Great.
>
>> Sounds reasonable, vcpu_wake() is O(1) while "stealing" is O(N) in
>> terms of
>> #PCPUs.
>> 
>Exactly!
>
>> > I also think current upstream is a bit better, especially because
>> > it's
>> > mostly me that made it look the way it does. :-D
>> 
>> Ah, not intended to flattering you.
>> 
>EhEh! Sure, I was joking myself. :-)
>

Ah, really enjoy talking with you :-)
You got some special sense of humor, and I like it~

Have a good day!

>> > 
>> > 
>> > But I was actually describing how 4.1 works. In fact, in 4.1, if
>> > pcpu 6
>> > is idle (se the '//xxx xxx xxx' comments I'm adding to the code
>> > excerpts:
>> > 
>> > if ( new->pri > cur->pri )  //is true, so we put pcpu 6 in mask
>> > {
>> > cpu_set(cpu, mask);
>> > }
>> > if ( cur->pri > CSCHED_PRI_IDLE )  //is false!!
>> > {
>> >    
>> > }
>> > if ( !cpus_empty(mask) ) //the mask contains pcpu 6 only
>> > cpumask_raise_softirq(mask, SCHEDULE_SOFTIRQ);
>> > 
>> 
>> Hmm... don't have the code at hand, while looks you are right. I
>> misunderstood
>> the code.
>
>> So only one idler would be tickled even there would be several idlers
>> in the
>> system. I thought we would tickle several idlers, which may introduce
>> some
>> contention between them.
>> 
>You can ask Xen to tickle more than one idle, by means of that
>parameter. But again, tickling idlers --either one or many-- would only
>happen if there's actual need for it.
>
>> BTW, any idea behind the cycle_cpu()? If this is about the locality,
>> how about
>> cycle within the node? and cycle within the node where v->processor
>> is?
>> 
>Cycle is there as a form of load spreading, i.e., we don't want to risk
>tickling always the same set of pcpus, or always the ones with the
>lower cpu IDs.
>
>You're right that taking locality into account could be a good thing in
>big systems. No, that is not done, not in 4.1 nor in upstream, and it
>may be something actually worth trying (although, again, it's probably
>unrelated to your issue).
>
>> > And again, I'd personally spend some more time --even by
>> > temporarily
>> > and hackishly instrumenting the code-- to understand better where
>> > the
>> > bottleneck is.
>> > 
>> 
>> Hmm... usually we use xentrace and lock profile to identify the
>> bottleneck,
>> other method you would like to suggest? and instrumenting the code
>> means to
>> add some log in code?
>> 
>xentrace and lock profile is all I use too, and there's not much else,
>without touching the code. And in fact, yes, with "instrumenting the
>code" I means temporary changing the code to display the information
>you need.
>
>In this specific case, rather than adding printks here and there
>(which, e.g., is what you usually do for debugging crashes or alike),
>I'd see about modifying a little bit either xentrace or lock profiling
>code (or both!) to make them provide the info you need.
>
>Sorry, but I don't think I can be much more specific without going
>looking at the code and actually trying to do that...
>
>> > E.g., something that has proven effective for others (and for which
>> > I've got an unfinished and never submitted patch to upstream), is
>> > keeping track of what pcpus actually have at least 1 vcpu in their
>> > runqueues (i.e., at least 1 vcpus that is runnable and not running)
>> > and, inside balance_load(), only consider those when looking for
>> > work
>> > to steal.
>> 
>> Looks like we keep a cpumask with those who have 1 more vcpus and
>> during
>> stealing process, just scan those instead of the online cpumask.
>> 
>Yep, that sounds like a plan, and was along the lines of what I was
>doing. If you want to give it a try, patches (for upstream, of course
>:-D) are welcome. :-P
>
>Regards,
>Dario
>-- 
><> (Raistlin Majere)
>-
>Dario Faggioli, Ph.D, http://about.me/dario.faggioli
>Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)


-- 
Richard Yang\nHelp you, Help me

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang]

On 9/9/2016 6:09 PM, Jan Beulich wrote:

On 09.09.16 at 11:56,  wrote:

On 9/9/2016 5:44 PM, Jan Beulich wrote:

On 09.09.16 at 11:24,  wrote:

On 9/9/2016 4:20 PM, Jan Beulich wrote:

On 09.09.16 at 09:24,  wrote:

On 9/9/2016 1:26 PM, Yu Zhang wrote:

On 02.09.16 at 12:47,  wrote:

@@ -965,7 +968,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
if ( is_epte_valid(ept_entry) )
{
if ( (recalc || ept_entry->recalc) &&
- p2m_is_changeable(ept_entry->sa_p2mt) )
+ p2m_is_changeable(ept_entry->sa_p2mt) &&
+ (ept_entry->sa_p2mt != p2m_ioreq_server) )
*t = p2m_is_logdirty_range(p2m, gfn, gfn) ?

p2m_ram_logdirty

  : p2m_ram_rw;
else

Considering this (and at least one more similar adjustment further
down), is it really appropriate to include p2m_ioreq_server in the
set of "changeable" types?

Well, I agree p2m_ioreq_server do have different behaviors than the
p2m_log_dirty, but removing p2m_ioreq_server from changeable type
would need more specific code for the p2m_ioreq_server in routines like
resolve_misconfig(), do_recalc() and p2m_change_entry_type_global() etc.
I've tried this approach and abandoned later. :)

I can see that the other option might require more adjustments, in
which case I guess this variant would be fine if you created another
helper (well named) inline function instead of open coding this in
several places. Of course such dissimilar handling in the various
places p2m_is_changeable() gets used right now will additionally
require good reasoning - after all that predicate exists to express
the similarities between different code paths.

Thanks Jan.
Well, for the logic of p2m type recalculation, similarities between
p2m_ioreq_server
and other changeable types exceeds their differences. As to the special
cases, how
about we use a macro, i.e. p2m_is_ioreq?

That'd be better than the open coded check, but would still result
in (taking the above example)

   p2m_is_changeable(ept_entry->sa_p2mt) &&
   !p2m_is_ioreq(ept_entry->sa_p2mt) )

? What I'd prefer is a predicate that can be applied here on its own,
without involving && or ||.


OK. I can think of 2 scenarios that p2m_ioreq_server needs special handling:

1> In ept_get_entry()/recal_type(), the p2m types are supposed to return
as it is, instead of
changing to p2m_log_dirty. So we can use a macro or a inline function
like p2m_check_changeable(),
which combines the

   p2m_is_changeable(ept_entry->sa_p2mt) &&
   !p2m_is_ioreq(ept_entry->sa_p2mt) )

together.

2> In resolve_misconfig()/do_recalc(), the entry_count gets decremented. We
do not need this new inline function, because they are in a separate
if() statement.

Is this OK? :)

Sounds reasonable. But please give George and others a chance to
voice their opinions before you go that route.

Jan


Hi George,

  Any comments on this series? :)

Yu


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Dongli Zhang]

This patch implemented parts of TODO left in commit id
a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush
filtering in alloc_heap_pages()). It moved TLB-flush filtering out into
populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very slow
to create a guest with memory size of more than 100GB on host with 100+
cpus.

This patch introduced a "MEMF_no_tlbflush" bit to memflags to indicate
whether TLB-flush should be done in alloc_heap_pages or its caller
populate_physmap.  Once this bit is set in memflags, alloc_heap_pages will
ignore TLB-flush. To use this bit after vm is created might lead to
security issue, that is, this would make pages accessible to the guest B,
when guest A may still have a cached mapping to them.

Therefore, this patch also introduced a "creation_finished" field to struct
domain to indicate whether this domain has ever got unpaused by hypervisor.
MEMF_no_tlbflush can be set only during vm creation phase when
creation_finished is still false before this domain gets unpaused for the
first time.

Signed-off-by: Dongli Zhang 
---
Changed since v5:
  * Remove conditional check before "d->creation_finished = true;".
  * Place "bool creation_finished;" next to the other group of booleans.
  * Remove duplicate "only" in comments.

Changed since v4:
  * Rename is_ever_unpaused to creation_finished.
  * Change bool_t to bool.
  * Polish comments.

Changed since v3:
  * Set the flag to true in domain_unpause_by_systemcontroller when
unpausing the guest domain for the first time.
  * Use true/false for all boot_t variables.
  * Add unlikely to optimize "if statement".
  * Correct comment style.

Changed since v2:
  * Limit this optimization to domain creation time.

---
 xen/common/domain.c |  7 +++
 xen/common/memory.c | 22 ++
 xen/common/page_alloc.c |  4 +++-
 xen/include/xen/mm.h|  2 ++
 xen/include/xen/sched.h |  6 ++
 5 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a8804e4..3abaca9 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1004,6 +1004,13 @@ int domain_unpause_by_systemcontroller(struct domain *d)
 {
 int old, new, prev = d->controller_pause_count;
 
+/*
+ * We record this information here for populate_physmap to figure out
+ * that the domain has finished being created. In fact, we're only
+ * allowed to set the MEMF_no_tlbflush flag during VM creation.
+ */
+d->creation_finished = true;
+
 do
 {
 old = prev;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index cc0f69e..21797ca 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -141,6 +141,8 @@ static void populate_physmap(struct memop_args *a)
 unsigned int i, j;
 xen_pfn_t gpfn, mfn;
 struct domain *d = a->domain, *curr_d = current->domain;
+bool need_tlbflush = false;
+uint32_t tlbflush_timestamp = 0;
 
 if ( !guest_handle_subrange_okay(a->extent_list, a->nr_done,
  a->nr_extents-1) )
@@ -150,6 +152,17 @@ static void populate_physmap(struct memop_args *a)
 max_order(curr_d)) )
 return;
 
+/*
+ * With MEMF_no_tlbflush set, alloc_heap_pages() will ignore
+ * TLB-flushes. After VM creation, this is a security issue (it can
+ * make pages accessible to guest B, when guest A may still have a
+ * cached mapping to them). So we do this only during domain creation,
+ * when the domain itself has not yet been unpaused for the first
+ * time.
+ */
+if ( unlikely(!d->creation_finished) )
+a->memflags |= MEMF_no_tlbflush;
+
 for ( i = a->nr_done; i < a->nr_extents; i++ )
 {
 if ( i != a->nr_done && hypercall_preempt_check() )
@@ -214,6 +227,13 @@ static void populate_physmap(struct memop_args *a)
 goto out;
 }
 
+if ( unlikely(a->memflags & MEMF_no_tlbflush) )
+{
+for ( j = 0; j < (1U << a->extent_order); j++ )
+accumulate_tlbflush(_tlbflush, [j],
+_timestamp);
+}
+
 mfn = page_to_mfn(page);
 }
 
@@ -232,6 +252,8 @@ static void populate_physmap(struct memop_args *a)
 }
 
 out:
+if ( need_tlbflush )
+filtered_flush_tlb_mask(tlbflush_timestamp);
 a->nr_done = i;
 }
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index d7ca3a0..ae2476d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -827,7 +827,9 @@ static struct page_info *alloc_heap_pages(
 BUG_ON(pg[i].count_info != PGC_state_free);
 pg[i].count_info = PGC_state_inuse;
 
-accumulate_tlbflush(_tlbflush, [i], _timestamp);
+if ( !(memflags & MEMF_no_tlbflush) )
+accumulate_tlbflush(_tlbflush, [i],
+

[Xen-devel] [PATCH v6 1/2] xen: replace tlbflush check and operation with inline functions

[Dongli Zhang]

This patch cleaned up the code by replacing complicated tlbflush check and
operation with inline functions. We should use those inline functions to
avoid the complicated tlbflush check and tlbflush operations when
implementing TODOs left in commit a902c12ee45fc9389eb8fe54eeddaf267a555c58
(More efficient TLB-flush filtering in alloc_heap_pages()).

"#include " is removed from xen/arch/x86/acpi/suspend.c to
avoid the compiling error after we include "" to
xen/include/xen/mm.h.

Signed-off-by: Dongli Zhang 
---
Changed since v5:
  * Move the if() and its body of tlbflush check into inline function.

Changed since v4:
  * Wrap the filtered tlbflush mask operation as inline function (suggested
by Jan).
  * Remove asm/flushtlb.h from suspend.c to avoid compiling error.

Changed since v3:
  * Wrap the complicated tlbflush condition check as inline function
(suggested by Dario).

---
 xen/arch/x86/acpi/suspend.c |  1 -
 xen/common/page_alloc.c | 19 ++-
 xen/include/xen/mm.h| 29 +
 3 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/acpi/suspend.c b/xen/arch/x86/acpi/suspend.c
index 1d8344c..d5c67ee 100644
--- a/xen/arch/x86/acpi/suspend.c
+++ b/xen/arch/x86/acpi/suspend.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 18ff6cf..d7ca3a0 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -827,14 +827,7 @@ static struct page_info *alloc_heap_pages(
 BUG_ON(pg[i].count_info != PGC_state_free);
 pg[i].count_info = PGC_state_inuse;
 
-if ( pg[i].u.free.need_tlbflush &&
- (pg[i].tlbflush_timestamp <= tlbflush_current_time()) &&
- (!need_tlbflush ||
-  (pg[i].tlbflush_timestamp > tlbflush_timestamp)) )
-{
-need_tlbflush = 1;
-tlbflush_timestamp = pg[i].tlbflush_timestamp;
-}
+accumulate_tlbflush(_tlbflush, [i], _timestamp);
 
 /* Initialise fields which have other uses for free pages. */
 pg[i].u.inuse.type_info = 0;
@@ -849,15 +842,7 @@ static struct page_info *alloc_heap_pages(
 spin_unlock(_lock);
 
 if ( need_tlbflush )
-{
-cpumask_t mask = cpu_online_map;
-tlbflush_filter(mask, tlbflush_timestamp);
-if ( !cpumask_empty() )
-{
-perfc_incr(need_flush_tlb_flush);
-flush_tlb_mask();
-}
-}
+filtered_flush_tlb_mask(tlbflush_timestamp);
 
 return pg;
 }
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index f470e49..50db01d 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 TYPE_SAFE(unsigned long, mfn);
@@ -567,4 +568,32 @@ int prepare_ring_for_helper(struct domain *d, unsigned 
long gmfn,
 struct page_info **_page, void **_va);
 void destroy_ring_for_helper(void **_va, struct page_info *page);
 
+#include 
+
+static inline void accumulate_tlbflush(bool *need_tlbflush,
+   const struct page_info *page,
+   uint32_t *tlbflush_timestamp)
+{
+if ( page->u.free.need_tlbflush &&
+ page->tlbflush_timestamp <= tlbflush_current_time() &&
+ (!*need_tlbflush ||
+  page->tlbflush_timestamp > *tlbflush_timestamp) )
+{
+*need_tlbflush = true;
+*tlbflush_timestamp = page->tlbflush_timestamp;
+}
+}
+
+static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
+{
+cpumask_t mask = cpu_online_map;
+
+tlbflush_filter(mask, tlbflush_timestamp);
+if ( !cpumask_empty() )
+{
+perfc_incr(need_flush_tlb_flush);
+flush_tlb_mask();
+}
+}
+
 #endif /* __XEN_MM_H__ */
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

[He Chen]

Hi Jan,

Sorry for the late response, I saw the this patch was merged but soon
got reverted, and the revert message says this patch is still buggy.

I would be most grateful if you would point out the buggy part of this
patch and the reason why revert it.

Thanks,
-He

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [for-4.8][PATCH v2 18/23] xen/arm: p2m: Re-implement relinquish_p2m_mapping using p2m_{get, set}_entry

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> The function relinquish_p2m_mapping can be re-implemented using
> p2m_{get,set}_entry by iterating over the range mapped and using the
> mapping order given by the callee.
> 
> Given that the preemption was chosen arbitrarily, it is now done on every
> 512 iterations. Meaning that Xen may check more often if the function is
> preempted when there are no mappings.
> 
> Finally drop the operation RELINQUISH in apply_* as nobody is using it
> anymore. Note that the functions could have been dropped in one go at
> the end, however I find easier to drop the operations one by one
> avoiding a big deletion in the patch that remove the last operation.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Erase entry one by one as I have not time so far to check
> whether it is possible to avoid removing entry in the p2m.
> - Use gfn_next_boundary
> ---
>  xen/arch/arm/p2m.c | 77 
> +-
>  1 file changed, 59 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 5f7aef0..ce09c4c 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -754,7 +754,6 @@ static int p2m_mem_access_radix_set(struct p2m_domain 
> *p2m, gfn_t gfn,
>  enum p2m_operation {
>  INSERT,
>  REMOVE,
> -RELINQUISH,
>  MEMACCESS,
>  };
>  
> @@ -1318,7 +1317,6 @@ static int apply_one_level(struct domain *d,
>  
>  break;
>  
> -case RELINQUISH:
>  case REMOVE:
>  if ( !p2m_valid(orig_pte) )
>  {
> @@ -1502,17 +1500,6 @@ static int apply_p2m_changes(struct domain *d,
>  {
>  switch ( op )
>  {
> -case RELINQUISH:
> -/*
> - * Arbitrarily, preempt every 512 operations or 8192 nops.
> - * 512*P2M_ONE_PROGRESS == 8192*P2M_ONE_PROGRESS_NOP == 
> 0x2000
> - * This is set in preempt_count_limit.
> - *
> - */
> -p2m->lowest_mapped_gfn = _gfn(addr >> PAGE_SHIFT);
> -rc = -ERESTART;
> -goto out;
> -
>  case MEMACCESS:
>  {
>  /*
> @@ -1919,16 +1906,70 @@ int p2m_init(struct domain *d)
>  return rc;
>  }
>  
> +/*
> + * The function will go through the p2m and remove page reference when it
> + * is required. The mapping will be removed from the p2m.
> + *
> + * XXX: See whether the mapping can be left intact in the p2m.
> + */
>  int relinquish_p2m_mapping(struct domain *d)
>  {
>  struct p2m_domain *p2m = >arch.p2m;
> -unsigned long nr;
> +unsigned long count = 0;
> +p2m_type_t t;
> +int rc = 0;
> +unsigned int order;
> +
> +/* Convenience alias */
> +gfn_t start = p2m->lowest_mapped_gfn;
> +gfn_t end = p2m->max_mapped_gfn;
> +
> +p2m_write_lock(p2m);
> +
> +for ( ; gfn_x(start) < gfn_x(end);
> +  start = gfn_next_boundary(start, order) )
> +{
> +mfn_t mfn = p2m_get_entry(p2m, start, , NULL, );
> +
> +count++;
> +/*
> + * Arbitrarily preempt every 512 iterations.
> + */
> +if ( !(count % 512) && hypercall_preempt_check() )
> +{
> +rc = -ERESTART;
> +break;
> +}
>  
> -nr = gfn_x(p2m->max_mapped_gfn) - gfn_x(p2m->lowest_mapped_gfn);
> +/*
> + * p2m_set_entry will take care of removing reference on page
> + * when it is necessary and removing the mapping in the p2m.
> + */
> +if ( !mfn_eq(mfn, INVALID_MFN) )
> +{
> +/*
> + * For valid mapping, the start will always be aligned as
> + * entry will be removed whilst relinquishing.
> + */
> +rc = __p2m_set_entry(p2m, start, order, INVALID_MFN,
> + p2m_invalid, p2m_access_rwx);
> +if ( unlikely(rc) )
> +{
> +printk(XENLOG_G_ERR "Unable to remove mapping 
> gfn=%#"PRI_gfn" order=%u from the p2m of domain %d\n", gfn_x(start), order, 
> d->domain_id);
> +break;
> +}
> +}
> +}
>  
> -return apply_p2m_changes(d, RELINQUISH, p2m->lowest_mapped_gfn, nr,
> - INVALID_MFN, 0, p2m_invalid,
> - d->arch.p2m.default_access);
> +/*
> + * Update lowest_mapped_gfn so on the next call we still start where
> + * we stopped.
> + */
> +p2m->lowest_mapped_gfn = start;
> +
> +p2m_write_unlock(p2m);
> +
> +return rc;
>  }
>  
>  int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr)
> -- 
> 1.9.1
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

flight 101016 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101016/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 100957
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 100957

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100957
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100957
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100957
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100957
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass

version targeted for testing:
 xen  57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a
baseline version:
 xen  3cffa34537767dfdb6a0fa02c1a54fdfc7644b6d

Last test of basis   100957  2016-09-14 16:12:51 Z5 days
Testing same since   101016  2016-09-19 16:14:13 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Marek Marczykowski-Górecki 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
> On Tue, 20 Sep 2016, Dario Faggioli wrote:
> > And this would work even if/when there is only one cpupool, or in
> > general for domains that are in a pool that has both big and LITTLE
> > pcpus. Furthermore, big.LITTLE support and cpupools will be
> > orthogonal,
> > just like pinning and cpupools are orthogonal right now. I.e., once
> > we
> > will have what I described above, nothing prevents us from
> > implementing
> > per-vcpu cpupool membership, and either create the two (or more!)
> > big
> > and LITTLE pools, or from mixing things even more, for more complex
> > and
> > specific use cases. :-)
> 
> I think that everybody agrees that this is the best long term
> solution.
> 
Well, no, that wasn't obvious to me. If that's the case, it's already
something! :-)

> > 
> > Actually, with the cpupool solution, if you want a guest (or dom0)
> > to
> > actually have both big and LITTLE vcpus, you necessarily have to
> > implement per-vcpu (rather than per-domain, as it is now) cpupool
> > membership. I said myself it's not impossible, but certainly it's
> > some
> > work... with the scheduler solution you basically get that for
> > free!
> > 
> > So, basically, if we use cpupools for the basics of big.LITTLE
> > support,
> > there's no way out of it (apart from going implementing scheduling
> > support afterwords, but that looks backwards to me, especially when
> > thinking at it with the code in mind).
> 
> The question is: what is the best short-term solution we can ask Peng
> to
> implement that allows Xen to run on big.LITTLE systems today?
> Possibly
> getting us closer to the long term solution, or at least not farther
> from it?
> 
So, I still have to look closely at the patches in these series. But,
with Credit2 in mind, if one:

 - take advantage of the knowledge of what arch a pcpu belongs inside 
   the code that arrange the pcpus in runqueues, which means we'll end 
   up with big runqueues and LITTLE runqueues. I re-wrote that code, I
   can provide pointers and help, if necessary;
 - tweak the one or two instance of for_each_runqueue() [*] that there
   are in the code into a for_each_runqueue_of_same_class(), i.e.:

 if (is_big(this_cpu))
 {
   for_each_big_runqueue()
   {
      ..
   }
 }
 else
 {
   for_each_LITTLE_runqueue()
   {
     ..
   }
 } 

then big.LITTLE support in Credit2 would be done already, and all it
would be left is support for the syntax of new config switches in xl,
and a way of telling, from xl/libxl down to Xen, what arch a vcpu
belongs to, so that it can be associated with one runqueue of the
proper class.

Thinking to Credit1, we need to make sure thet, in load_balance() and
runq_steal(), a LITTLE cpu *only* ever try to steal work from another
LITTLE cpu, and __never__ from a big cpu (and vice versa). And also
that when a vcpu wakes up, and what it has in its v->processor is a
LITTLE pcpu, that only LITTLE processors are considered for being
tickled (I'm less certain of this last part, but it should be more or
less like this).

Then, of course the the same glue and vcpu classification code.

However, in Credit1, it's possible that a trick like that would affect
the accounting and credit algorithm, and hence provide unfair, or in
general, unexpected results. Credit2 should, OTOH, be a lot mere
resilient, wrt that.

> > > The whole process would be more explicit and obvious if we used
> > > cpupools. It would be easier for users to know what it is going
> > > on --
> > > they just need to issue an `xl cpupool-list' command and they
> > > would
> > > see
> > > two clearly named pools (something like big-pool and LITTLE-
> > > pool). 
> > > 
> > Well, I guess that, as part of big.LITTLE support, there will be a
> > way
> > to tell what pcpus are big and which are LITTLE anyway, probably
> > both
> > from `xl info' and from `xl cpupool-list -c' (and most likely in
> > other
> > ways too).
> 
> Sure, but it needs to be very clear. We cannot ask people to spot
> architecture specific flags among the output of `xl info' to be able
> to
> appropriately start a guest. 
>
As mentioned in previous mail, and as drafted when replying to Peng,
the only think that the user should know is how many big and how many
LITTLE vcpus she wants (and, potentially, which one would be each). :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, September 20, 2016 7:12 AM
> To: Wu, Feng ; Jan Beulich 
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> ; xen-devel@lists.xen.org
> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
> PI hooks
> 
> On Sun, 2016-09-18 at 08:37 +, Wu, Feng wrote:
> > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > > So why this is all of the sudden becoming one? Am I completely off
> > > with
> > > my recollection (or in general :-P)? Or what am I missing about the
> > > issue we are trying to address with this new bits of the work?
> >
> > The issue discussed between Jan and me is that now we have four
> > PI hooks: vmx_pi_switch_from, vmx_pi_switch_to, vmx_vcpu_block,
> > and vmx_pi_do_resume. The previous assumption in vmx_vcpu_block()
> > is that when we are running this function, the NDST field should have
> > the same meaning with the current pCPU the vCPU is running on.
> >
> I'm sorry, but I'm still not getting it. Feel free to drop me, if I'm
> doing more harm than good, but really, I can't parse this sentence into
> something that makes me better understand the problem at hand.
> 
> "The previous assumption": "previous" with respect to what?
> 
> "the field should have the same meaning with the current pCPU the vCPU
> is running on", what's this meaning you're mentioning, and how would it
> be the same?

Sorry for my bad description. I mean in the current code there an ASSERT
in vmx_vcpu_block():

ASSERT(pi_desc->ndst ==
(x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK)))

So we assume that the value of NDST field should get from the pCPU the vCPU
is currently running on.

> 
> > However, I found this is not true in some scenarios, such as,
> > vmx_pi_switch_to() hasn't been installed or executed before
> > vmx_vcpu_block() gets called, in which case, we may hit the ASSERT
> > in it. In previous version, I suggested we remove the ASSERT in
> > vmx_vcpu_block() and set NDST explicitly in it. But seems maintainer
> > doesn't like this idea.
> >
> And this is not helping either. An ASSERT() being hit means something
> wrong happened. Whether or not to remove (or change) an ASSERT() is not
> a matter of "like".
> 
> If we hit the ASSERT() but nothing is wrong with the code, then it is
> the ASSERT() itself that is wrong (buggy), and we must remove it, like
> it or not.
> 
> OTOH, if we hit a non buggy ASSERT(), then it means that the ASSERT()
> has done its job in finding something wrong in the code, and we should
> leave it alone and fix the problem.

Yes, this is what we are doing now. We think the ASSERT() should be still
there, and try to fix the issue in the other place to make sure we will not
hit the ASSERT() here.

> 
> How's possible for the solution here to be "either remove the ASSERT()
> _OR_ change the code"? That really makes few sense to me... :-O

As mentioned above, I will remain the ASSERT and fix the issue.
Thanks for the comments!

Thanks,
Feng

> 
> Thanks and Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Tian, Kevin]

> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
> Sent: Tuesday, September 20, 2016 8:25 AM
> 
> On September 19, 2016 5:25 PM, Tian Kevin  wrote:
> >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
> >> Sent: Monday, September 12, 2016 5:08 PM
> >>
> >> On September 12, 2016 3:58 PM, Tian, Kevin  wrote:
> >> >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
> >> >> Sent: Friday, September 09, 2016 11:02 AM
> >> >>
> >> >> On August 30, 2016 1:58 PM, Tian Kevin < kevin.t...@intel.com > wrote:
> >> >> >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
> >> >> >> Sent: Friday, August 19, 2016 8:59 PM
> >> >> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> >> >> index 1d5d287..cc247c3 100644
> >> >> --- a/xen/arch/x86/hvm/vlapic.c
> >> >> +++ b/xen/arch/x86/hvm/vlapic.c
> >> >> @@ -433,6 +433,11 @@ void vlapic_EOI_set(struct vlapic *vlapic)
> >> >> void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)  {
> >> >>  struct domain *d = vlapic_domain(vlapic);
> >> >> +struct hvm_intack pt_intack;
> >> >> +
> >> >> +pt_intack.vector = vector;
> >> >> +pt_intack.source = hvm_intsrc_lapic;
> >> >> +pt_intr_post(vlapic_vcpu(vlapic), pt_intack);
> >> >>
> >> >>  if ( vlapic_test_and_clear_vector(vector,
> >> >>regs->data[APIC_TMR]) )
> >> >>  vioapic_update_EOI(d, vector); diff --git
> >> >> a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c index
> >> >> 8fca08c..29d9bbf 100644
> >> >> --- a/xen/arch/x86/hvm/vmx/intr.c
> >> >> +++ b/xen/arch/x86/hvm/vmx/intr.c
> >> >> @@ -333,8 +333,6 @@ void vmx_intr_assist(void)
> >> >>  clear_bit(i, >arch.hvm_vmx.eoi_exitmap_changed);
> >> >>  __vmwrite(EOI_EXIT_BITMAP(i),
> >> >v->arch.hvm_vmx.eoi_exit_bitmap[i]);
> >> >>  }
> >> >> -
> >> >> -pt_intr_post(v, intack);
> >> >>  }
> >> >>  else
> >> >>  {
> >> >>
> >> >
> >> >Because we update pt irq in every vmentry, there is a chance that
> >> >already-injected instance (before EOI-induced exit happens) will
> >> >incur another pending IRR setting if there is a VM-exit happens
> >> >between HW virtual interrupt injection (vIRR->0, vISR->1) and
> >> >EOI-induced exit (vISR->0), since pt_intr_post hasn't been invoked
> >> >yet. I guess this is the reason why you still see faster wallclock.
> >> >
> >>
> >> Agreed. A good description. My bad description is from another aspect.
> >>
> >> >I think you need mark this pending_intr_post situation explicitly.
> >> >Then pt_update_irq should skip such pt timer when pending_intr_post
> >> >of that timer is true (otherwise the update is meaningless since
> >> >previous one hasn't been posted yet). Then with your change to post
> >> >in EOI-induced exit handler, it should work correctly to meet the
> >> >goal
> >> >- one virtual interrupt delivery for one pending pt intr...
> >> >
> >> I think we are at least on the right track.
> >> But I can't follow ' pending_intr_post ', a new parameter? Thanks.
> >>
> >>
> >
> >yes, a new parameter to record whether a intr_post operation is pending
> 
> 
> The existing parameter ' irq_issued ' looks good. I have tested with below 
> modification last
> night, and it is working.
> If it is okay, I will send out v2..

yes, looks it could serve the purpose. 

> 
> Quan
> 
>  modification =
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 1d5d287..cc247c3 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -433,6 +433,11 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>  void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
>  {
>  struct domain *d = vlapic_domain(vlapic);
> +struct hvm_intack pt_intack;
> +
> +pt_intack.vector = vector;
> +pt_intack.source = hvm_intsrc_lapic;
> +pt_intr_post(vlapic_vcpu(vlapic), pt_intack);
> 
>  if ( vlapic_test_and_clear_vector(vector, >regs->data[APIC_TMR]) 
> )
>  vioapic_update_EOI(d, vector);
> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> index 8fca08c..29d9bbf 100644
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -333,8 +333,6 @@ void vmx_intr_assist(void)
>  clear_bit(i, >arch.hvm_vmx.eoi_exitmap_changed);
>  __vmwrite(EOI_EXIT_BITMAP(i), 
> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>  }
> -
> -pt_intr_post(v, intack);
>  }
>  else
>  {
> diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
> index 5c48fdb..620ca68 100644
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -267,6 +267,11 @@ int pt_update_irq(struct vcpu *v)
>  return -1;
>  }
> 
> +if ( earliest_pt->irq_issued )
> +{
> +spin_unlock(>arch.hvm_vcpu.tm_lock);
> +return -1;
> +}

You need move the check within the loop, so other pt timers are
not blocked in such situation...

Thanks
Kevin

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tian, Kevin]

> From: Tamas K Lengyel
> Sent: Tuesday, September 20, 2016 12:40 AM
> 
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -489,13 +489,16 @@ void hvm_do_resume(struct vcpu *v)
> >>
> >>  if ( v->arch.vm_event->emulate_flags &
> >>   VM_EVENT_FLAG_SET_EMUL_READ_DATA )
> >> -kind = EMUL_KIND_SET_CONTEXT;
> >> +kind = EMUL_KIND_SET_CONTEXT_DATA;
> >>  else if ( v->arch.vm_event->emulate_flags &
> >>VM_EVENT_FLAG_EMULATE_NOWRITE )
> >>  kind = EMUL_KIND_NOWRITE;
> >> +else if ( v->arch.vm_event->emulate_flags &
> >> + VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
> >> +kind = EMUL_KIND_SET_CONTEXT_INSN;
> >
> > The header talking about incompatibilities between these flags -
> > wouldn't it be a good idea to actually -EINVAL such combinations?
> 
> The header just points out that setting all these flags at the same
> time won't have a "combined" effect - evident from the if-else
> treatment above. There is really no point to do an error, the error
> would never reach the user. Setting response flags through vm_event
> doesn't have an error-path back.
> 

Maybe you can have an explicit comment on priority of those flags,
so consistent behavior can be expected moving forward. e.g. above
code implies read_data>nowrite>insn_data. w/o a proper guidance
here, future code changes by others may break that sequence...

Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 07/21] acpi/hvmloader: Build WAET optionally

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 10 +++---
 tools/firmware/hvmloader/acpi/libacpi.h |  1 +
 tools/firmware/hvmloader/util.c |  2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index dc489bb..537933b 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -360,9 +360,13 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* WAET. */
-waet = construct_waet();
-if (!waet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+if ( config->table_flags & ACPI_HAS_WAET )
+{
+waet = construct_waet();
+if ( !waet )
+return -1;
+table_ptrs[nr_tables++] = (unsigned long)waet;
+}
 
 if ( config->table_flags & ACPI_HAS_SSDT_PM )
 {
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index b8f28a3..b411a6e 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -29,6 +29,7 @@
 #define ACPI_HAS_SSDT_S4 (1<<6)
 #define ACPI_HAS_TCPA(1<<7)
 #define ACPI_HAS_IOAPIC  (1<<8)
+#define ACPI_HAS_WAET(1<<9)
 
 struct xen_vmemrange;
 struct acpi_numa {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index aa5fc20..b345576 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,7 +919,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC);
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 06/21] acpi/hvmloader: Make providing IOAPIC in MADT optional

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 70 ++---
 tools/firmware/hvmloader/acpi/libacpi.h |  1 +
 tools/firmware/hvmloader/util.c |  2 +-
 3 files changed, 40 insertions(+), 33 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index c984e5a..dc489bb 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -100,43 +100,49 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 madt->lapic_addr = LAPIC_BASE_ADDRESS;
 madt->flags  = ACPI_PCAT_COMPAT;
 
-intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
-for ( i = 0; i < 16; i++ )
-{
-memset(intsrcovr, 0, sizeof(*intsrcovr));
-intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
-intsrcovr->length = sizeof(*intsrcovr);
-intsrcovr->source = i;
-
-if ( i == 0 )
-{
-/* ISA IRQ0 routed to IOAPIC GSI 2. */
-intsrcovr->gsi= 2;
-intsrcovr->flags  = 0x0;
-}
-else if ( PCI_ISA_IRQ_MASK & (1U << i) )
-{
-/* PCI: active-low level-triggered. */
-intsrcovr->gsi= i;
-intsrcovr->flags  = 0xf;
-}
-else
+if ( config->table_flags & ACPI_HAS_IOAPIC )
+{ 
+intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
+for ( i = 0; i < 16; i++ )
 {
-/* No need for a INT source override structure. */
-continue;
+memset(intsrcovr, 0, sizeof(*intsrcovr));
+intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
+intsrcovr->length = sizeof(*intsrcovr);
+intsrcovr->source = i;
+
+if ( i == 0 )
+{
+/* ISA IRQ0 routed to IOAPIC GSI 2. */
+intsrcovr->gsi= 2;
+intsrcovr->flags  = 0x0;
+}
+else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+{
+/* PCI: active-low level-triggered. */
+intsrcovr->gsi= i;
+intsrcovr->flags  = 0xf;
+}
+else
+{
+/* No need for a INT source override structure. */
+continue;
+}
+
+intsrcovr++;
 }
 
-intsrcovr++;
-}
+io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
+memset(io_apic, 0, sizeof(*io_apic));
+io_apic->type= ACPI_IO_APIC;
+io_apic->length  = sizeof(*io_apic);
+io_apic->ioapic_id   = IOAPIC_ID;
+io_apic->ioapic_addr = ioapic_base_address;
 
-io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
-memset(io_apic, 0, sizeof(*io_apic));
-io_apic->type= ACPI_IO_APIC;
-io_apic->length  = sizeof(*io_apic);
-io_apic->ioapic_id   = IOAPIC_ID;
-io_apic->ioapic_addr = ioapic_base_address;
+lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
+}
+else
+lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
-lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
 info->nr_cpus = hvminfo->nr_vcpus;
 info->madt_lapic0_addr = (uint32_t)lapic;
 for ( i = 0; i < hvminfo->nr_vcpus; i++ )
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 70cf26b..b8f28a3 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -28,6 +28,7 @@
 #define ACPI_HAS_SSDT_S3 (1<<5)
 #define ACPI_HAS_SSDT_S4 (1<<6)
 #define ACPI_HAS_TCPA(1<<7)
+#define ACPI_HAS_IOAPIC  (1<<8)
 
 struct xen_vmemrange;
 struct acpi_numa {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 8875675..aa5fc20 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,7 +919,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= ACPI_HAS_TCPA;
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 21/21] libxc/xc_dom_core: Copy ACPI tables to guest space

[Boris Ostrovsky]

Load ACPI modules into guest space

Signed-off-by: Boris Ostrovsky 
---
Changes in v4:
* Style updates

 tools/libxc/xc_dom_core.c | 95 +++
 1 file changed, 95 insertions(+)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index ebada89..be3ccd7 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1040,6 +1040,97 @@ static int xc_dom_build_ramdisk(struct xc_dom_image *dom)
 return -1;
 }
 
+static int populate_acpi_pages(struct xc_dom_image *dom,
+   xen_pfn_t *extents,
+   unsigned int num_pages)
+{
+int rc;
+xc_interface *xch = dom->xch;
+uint32_t domid = dom->guest_domid;
+unsigned long idx;
+unsigned int first_high_idx = (4 << 30) >> PAGE_SHIFT; /* 4GB */
+
+for ( ; num_pages; num_pages--, extents++ )
+{
+
+if ( xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents) == 1 )
+continue;
+
+if (dom->highmem_end)
+{
+idx = --dom->highmem_end;
+if ( idx == first_high_idx )
+dom->highmem_end = 0;
+}
+else
+{
+idx = --dom->lowmem_end;
+}
+
+rc = xc_domain_add_to_physmap(xch, domid,
+  XENMAPSPACE_gmfn,
+  idx, *extents);
+if (rc)
+return rc;
+}
+
+return 0;
+}
+
+static int xc_dom_load_acpi(struct xc_dom_image *dom)
+{
+int j, i = 0;
+unsigned num_pages;
+xen_pfn_t *extents, base;
+void *ptr;
+
+while ( (i < MAX_ACPI_MODULES) && dom->acpi_modules[i].length )
+{
+DOMPRINTF("%s: %d bytes at address %" PRIx64 "\n", __FUNCTION__,
+  dom->acpi_modules[i].length,
+  dom->acpi_modules[i].guest_addr_out);
+
+num_pages = (dom->acpi_modules[i].length + (XC_PAGE_SIZE - 1)) >>
+   XC_PAGE_SHIFT;
+extents = malloc(num_pages * sizeof(*extents));
+if ( !extents )
+{
+DOMPRINTF("%s: Out of memory", __FUNCTION__);
+goto err;
+}
+
+base = dom->acpi_modules[i].guest_addr_out >> XC_PAGE_SHIFT;
+for (j = 0; j < num_pages; j++)
+extents[j] = base + j;
+if ( populate_acpi_pages(dom, extents, num_pages) )
+{
+DOMPRINTF("%s: Can populate ACPI pages", __FUNCTION__);
+goto err;
+}
+
+ptr = xc_map_foreign_range(dom->xch, dom->guest_domid,
+   XC_PAGE_SIZE * num_pages,
+   PROT_READ | PROT_WRITE, base);
+if ( !ptr )
+{
+DOMPRINTF("%s: Can't map %d pages at 0x%lx",
+  __FUNCTION__, num_pages, base);
+goto err;
+}
+
+memcpy(ptr, dom->acpi_modules[i].data, dom->acpi_modules[i].length);
+
+free(extents);
+i++;
+}
+
+return 0;
+
+err:
+free(extents);
+return -1;
+}
+
 int xc_dom_build_image(struct xc_dom_image *dom)
 {
 unsigned int page_size;
@@ -1097,6 +1188,10 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 memcpy(devicetreemap, dom->devicetree_blob, dom->devicetree_size);
 }
 
+/* load ACPI tables */
+if ( xc_dom_load_acpi(dom) != 0 )
+goto err;
+
 /* allocate other pages */
 if ( !dom->arch_hooks->p2m_base_supported ||
  dom->parms.p2m_base >= dom->parms.virt_base ||
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

[Boris Ostrovsky]

ACPI sources will be available to various component which will build
them according to their own rules. ACPI's Makefile will only generate
necessary source files.

Signed-off-by: Boris Ostrovsky 
---
Changes in v4:
* Added a suffix to iasl's -p option to work around a bug in older
  iasl versions where it drops everything after rightmost '.'.

 .gitignore |  8 +++---
 tools/firmware/hvmloader/Makefile  | 11 +++-
 tools/firmware/hvmloader/acpi/Makefile | 48 --
 3 files changed, 37 insertions(+), 30 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6dee857..5720e0f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -127,13 +127,13 @@ tools/firmware/*bios/*bios*.txt
 tools/firmware/etherboot/gpxe/*
 tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
-tools/firmware/hvmloader/acpi/mk_dsdt
-tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt_*cpu*.asl
-tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/dsdt*.c
+tools/firmware/hvmloader/dsdt_*.asl
 tools/firmware/hvmloader/hvmloader
+tools/firmware/hvmloader/mk_dsdt
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
+tools/firmware/hvmloader/ssdt_*.h
 tools/firmware/rombios/BIOS-bochs-[^/]*
 tools/firmware/rombios/_rombios[^/]*_.c
 tools/firmware/rombios/rombios[^/]*.s
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 23b0a58..2565832 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,6 +20,7 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
+export ACPI_BUILD_DIR=$(CURDIR)
 SUBDIRS := acpi
 
 # The HVM loader is started in 32-bit mode at the address below:
@@ -76,7 +77,15 @@ all: subdirs-all
 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-hvmloader: $(OBJS) acpi/acpi.a
+ACPI_PATH = acpi
+ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
+$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+vpath build.c $(ACPI_PATH)
+vpath static_tables.c $(ACPI_PATH)
+OBJS += $(ACPI_OBJS)
+
+hvmloader: $(OBJS)
$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(LOADADDR) -o hvmloader.tmp $^
$(OBJCOPY) hvmloader.tmp hvmloader
rm -f hvmloader.tmp
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index c6382bd..4045ea7 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -15,41 +15,45 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC-$(GPL)   = build.c dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
-C_SRC  = build.c static_tables.c $(C_SRC-y)
-OBJS  = $(patsubst %.c,%.o,$(C_SRC))
+# Used as a workaround for a bug in some older iasl versions where
+# the tool will ignore everything after last '.' in the path ('-p' argument)
+TMP_SUFFIX = tmp__
 
-CFLAGS += $(CFLAGS_xeninclude)
+MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
+
+C_SRC-$(GPL)   = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+C_SRC  = $(addprefix $(ACPI_BUILD_DIR)/, $(C_SRC-y))
+H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 vpath iasl $(PATH)
-all: acpi.a
+all: $(C_SRC) $(H_SRC)
 
-ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
-   iasl -vs -p $* -tc $<
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
-   rm -f $*.hex $*.aml
+$(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
+   iasl -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
+   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
+   rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
 
-mk_dsdt: mk_dsdt.c
+$(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
 ifeq ($(GPL),y)
-dsdt_anycpu_qemu_xen.asl: gpl/dsdt.asl dsdt_acpi_info.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: gpl/dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
cat dsdt_acpi_info.asl >> $@
-   ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: gpl/dsdt.asl dsdt_acpi_info.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: gpl/dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
cat dsdt_acpi_info.asl >> $@
-   ./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
 endif
 
-$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
-   iasl -vs -p $* -tc $*.asl
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
+$(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
+   iasl -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc 
$(ACPI_BUILD_DIR)/$*.asl
+   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
 

[Xen-devel] [PATCH v4 01/21] acpi: Extract acpi info description into a separate ASL file

[Boris Ostrovsky]

This code will be needed by PVH guests who don't want to use full DSDT.

Signed-off-by: Boris Ostrovsky 
---
Changes in v4:
* New patch. This used to be done in a later patch but because we now
  are trying to keep dsdt.asl GPL-only (in the next patch) it's better
  to do this here and not touch dsdt.asl later.

 .gitignore   |  2 +-
 tools/firmware/hvmloader/acpi/Makefile   |  8 +---
 tools/firmware/hvmloader/acpi/dsdt.asl   | 19 -
 tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl | 26 
 4 files changed, 32 insertions(+), 23 deletions(-)
 create mode 100644 tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl

diff --git a/.gitignore b/.gitignore
index cc64fc9..6dee857 100644
--- a/.gitignore
+++ b/.gitignore
@@ -129,7 +129,7 @@ tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
 tools/firmware/hvmloader/acpi/mk_dsdt
 tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt_*.asl
+tools/firmware/hvmloader/acpi/dsdt_*cpu*.asl
 tools/firmware/hvmloader/acpi/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index d3e882a..76da073 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -33,13 +33,15 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 mk_dsdt: mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
+dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   cat dsdt_acpi_info.asl >> $@
./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl mk_dsdt
+dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   cat dsdt_acpi_info.asl >> $@
./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@
 
 $(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
@@ -63,7 +65,7 @@ acpi.a: $(OBJS)
 
 clean:
rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
-   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
+   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*cpu*.asl
 
 distclean: clean
 
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl 
b/tools/firmware/hvmloader/acpi/dsdt.asl
index bd65823..4f6db79 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -43,25 +43,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
 
 Scope (\_SB)
 {
-   /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC00 */
-   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
-   Field(BIOS, ByteAcc, NoLock, Preserve) {
-   UAR1, 1,
-   UAR2, 1,
-   LTP1, 1,
-   HPET, 1,
-   Offset(2),
-   NCPU, 16,
-   PMIN, 32,
-   PLEN, 32,
-   MSUA, 32, /* MADT checksum address */
-   MAPA, 32, /* MADT LAPIC0 address */
-   VGIA, 32, /* VM generation id address */
-   LMIN, 32,
-   HMIN, 32,
-   LLEN, 32,
-   HLEN, 32
-   }
 
 /* Fix HCT test for 0x400 pci memory:
  * - need to report low 640 MB mem as motherboard resource
diff --git a/tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl 
b/tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl
new file mode 100644
index 000..29e962a
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl
@@ -0,0 +1,26 @@
+
+Scope (\_SB)
+{
+   /*
+* BIOS region must match struct acpi_info in build.c and
+   * be located at ACPI_INFO_PHYSICAL_ADDRESS = 0xFC00
+   */
+   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
+   Field(BIOS, ByteAcc, NoLock, Preserve) {
+   UAR1, 1,
+   UAR2, 1,
+   LTP1, 1,
+   HPET, 1,
+   Offset(2),
+   NCPU, 16,
+   PMIN, 32,
+   PLEN, 32,
+   MSUA, 32, /* MADT checksum address */
+   MAPA, 32, /* MADT LAPIC0 address */
+   VGIA, 32, /* VM generation id address */
+   LMIN, 32,
+   HMIN, 32,
+   LLEN, 32,
+   HLEN, 32
+   }
+}
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 09/21] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables

[Boris Ostrovsky]

Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c | 47 ++-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 1dd9987..b295ef0 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -145,7 +145,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
 info->nr_cpus = hvminfo->nr_vcpus;
-info->madt_lapic0_addr = (uint32_t)lapic;
+info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
 for ( i = 0; i < hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
@@ -162,7 +162,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
 set_checksum(madt, offsetof(struct acpi_header, checksum),
  madt->header.length);
-info->madt_csum_addr = (uint32_t)>header.checksum;
+info->madt_csum_addr =
+ctxt->mem_ops.v2p(ctxt, >header.checksum);
 
 return madt;
 }
@@ -328,7 +329,7 @@ static int construct_passthrough_tables(struct acpi_ctxt 
*ctxt,
 break;
 memcpy(buffer, header, header->length);
 
-table_ptrs[nr_tables++] = (unsigned long)buffer;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, buffer);
 total += header->length;
 pt_addr += header->length;
 }
@@ -355,7 +356,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 madt = construct_madt(ctxt, config, info);
 if (!madt) return -1;
-table_ptrs[nr_tables++] = (unsigned long)madt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, madt);
 }
 
 /* HPET. */
@@ -363,7 +364,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 hpet = construct_hpet(ctxt, config);
 if (!hpet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)hpet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, hpet);
 }
 
 /* WAET. */
@@ -372,7 +373,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 waet = construct_waet(ctxt, config);
 if ( !waet )
 return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, waet);
 }
 
 if ( config->table_flags & ACPI_HAS_SSDT_PM )
@@ -380,7 +381,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_pm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_pm, sizeof(ssdt_pm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 }
 
 if ( config->table_flags & ACPI_HAS_SSDT_S3 )
@@ -388,7 +389,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s3), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S3 disabled\n");
 }
@@ -398,7 +399,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s4), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S4 disabled\n");
 }
@@ -412,12 +413,12 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_tpm, sizeof(ssdt_tpm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 
 tcpa = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_tcpa), 16);
 if (!tcpa) return -1;
 memset(tcpa, 0, sizeof(*tcpa));
-table_ptrs[nr_tables++] = (unsigned long)tcpa;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, tcpa);
 
 tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
 tcpa->header.length= sizeof(*tcpa);
@@ -445,11 +446,11 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 struct acpi_20_slit *slit = construct_slit(ctxt, config);
 
 if ( srat )
-table_ptrs[nr_tables++] = (unsigned long)srat;
+

[Xen-devel] [PATCH v4 11/21] acpi/hvmloader: Include file/paths adjustments

[Boris Ostrovsky]

In prepearation to moving acpi sources into generally available
libacpi:

1. Pass IOAPIC/LAPIC/PCI mask values via struct acpi_config
2. Modify include files search paths to point to acpi directory
3. Macro-ise include file for build.c that defines various
   utilities used by that file. Users of libacpi will be expected
   to define this macro when compiling build.c

Signed-off-by: Boris Ostrovsky 
---
Changes in v4:
* Include xen/memory.h in build.c
* lapic_id() returns uint8_t


 tools/firmware/hvmloader/Makefile |  3 ++-
 tools/firmware/hvmloader/acpi/README  | 16 
 tools/firmware/hvmloader/acpi/build.c | 19 ++-
 tools/firmware/hvmloader/acpi/libacpi.h   |  7 +++
 tools/firmware/hvmloader/hvmloader.c  |  2 +-
 tools/firmware/hvmloader/rombios.c|  2 +-
 tools/firmware/hvmloader/seabios.c|  5 +++--
 tools/firmware/hvmloader/util.c   | 15 +--
 tools/firmware/rombios/32bit/Makefile |  2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile |  2 +-
 tools/firmware/rombios/32bit/util.h   |  2 +-
 11 files changed, 52 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 2565832..7b3641c 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -80,7 +80,8 @@ smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 ACPI_PATH = acpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
-$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"../util.h\"
+CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)
 vpath static_tables.c $(ACPI_PATH)
 OBJS += $(ACPI_OBJS)
diff --git a/tools/firmware/hvmloader/acpi/README 
b/tools/firmware/hvmloader/acpi/README
index 210d5ba..2b9d6e1 100644
--- a/tools/firmware/hvmloader/acpi/README
+++ b/tools/firmware/hvmloader/acpi/README
@@ -1,11 +1,19 @@
-ACPI Table for domain firmware
+ACPI builder for domain firmware
 
 
-INSTALL
+BUILDING ACPI
 -
-Simply make is OK.
-# make 
+Users of ACPI builder are expected to provide an include file that makes 
available
+the following:
+* strncpy
+* printf
+* NULL
+* test_bit
+* offsetof
 
+When compiling build.c, the name of this include file should be given to
+compiler as -DLIBACPI_STDUTILS=\"\". See 
tools/firmware/hvmloader/Makefile
+for an example.
 
 Note on DSDT Table
 --
diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index b295ef0..00fb67e 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -13,15 +13,13 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include LIBACPI_STDUTILS
 #include "acpi2_0.h"
 #include "libacpi.h"
 #include "ssdt_s3.h"
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
-#include "../config.h"
-#include "../util.h"
-#include "../vnuma.h"
 #include 
 #include 
 #include 
@@ -82,6 +80,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 const struct hvm_info_table   *hvminfo = config->hvminfo;
 int i, sz;
 
+if ( config->lapic_id == NULL )
+return NULL;
+
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
@@ -98,7 +99,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->header.oem_revision = ACPI_OEM_REVISION;
 madt->header.creator_id   = ACPI_CREATOR_ID;
 madt->header.creator_revision = ACPI_CREATOR_REVISION;
-madt->lapic_addr = LAPIC_BASE_ADDRESS;
+madt->lapic_addr = config->lapic_base_address;
 madt->flags  = ACPI_PCAT_COMPAT;
 
 if ( config->table_flags & ACPI_HAS_IOAPIC )
@@ -117,7 +118,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 intsrcovr->gsi= 2;
 intsrcovr->flags  = 0x0;
 }
-else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+else if ( config->pci_isa_irq_mask & (1U << i) )
 {
 /* PCI: active-low level-triggered. */
 intsrcovr->gsi= i;
@@ -136,8 +137,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 memset(io_apic, 0, sizeof(*io_apic));
 io_apic->type= ACPI_IO_APIC;
 io_apic->length  = sizeof(*io_apic);
-io_apic->ioapic_id   = IOAPIC_ID;
-io_apic->ioapic_addr = ioapic_base_address;
+io_apic->ioapic_id   = config->ioapic_id;
+io_apic->ioapic_addr = config->ioapic_base_address;
 
 lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
 }
@@ -153,7 +154,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 

[Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
Changes in v4:
* Remove allocation-specific fields from struct acpi_ctxt and use
  an enclosing struct libxl_acpi_ctxt.
* Use private struct hvminfo (to deal with constified struct
  acpi_config->hvminfo)

 .gitignore   |  12 ++-
 tools/libacpi/build.c|   7 +-
 tools/libacpi/libacpi.h  |   6 +-
 tools/libxl/Makefile |  18 +++-
 tools/libxl/libxl_arch.h |   3 +
 tools/libxl/libxl_x86.c  |  30 --
 tools/libxl/libxl_x86_acpi.c | 243 +++
 tools/libxl/libxl_x86_acpi.h |  35 +++
 8 files changed, 334 insertions(+), 20 deletions(-)
 create mode 100644 tools/libxl/libxl_x86_acpi.c
 create mode 100644 tools/libxl/libxl_x86_acpi.h

diff --git a/.gitignore b/.gitignore
index 5720e0f..9b6f58e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -173,15 +173,19 @@ tools/include/xen/*
 tools/include/xen-xsm/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-tools/libxl/libxlu_cfg_y.output
+tools/libxl/_libxl.api-for-check
+tools/libxl/*.api-ok
 tools/libxl/*.pc
 tools/libxl/*.pc.in
-tools/libxl/xl
+tools/libxl/dsdt*.c
+tools/libxl/dsdt_*.asl
+tools/libxl/libxlu_cfg_y.output
+tools/libxl/mk_dsdt
+tools/libxl/ssdt_*.h
 tools/libxl/testenum
 tools/libxl/testenum.c
 tools/libxl/tmp.*
-tools/libxl/_libxl.api-for-check
-tools/libxl/*.api-ok
+tools/libxl/xl
 tools/misc/cpuperf/cpuperf-perfcntr
 tools/misc/cpuperf/cpuperf-xen
 tools/misc/xc_shadow
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 00fb67e..47dae01 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -20,6 +20,7 @@
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
+#include 
 #include 
 #include 
 #include 
@@ -496,7 +497,7 @@ static int new_vm_gid(struct acpi_ctxt *ctxt,
 return 1;
 }
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
 {
 struct acpi_info *acpi_info;
 struct acpi_20_rsdp *rsdp;
@@ -631,11 +632,11 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 if ( !new_vm_gid(ctxt, config, acpi_info) )
 goto oom;
 
-return;
+return 0;
 
 oom:
 printf("unable to build ACPI tables: out of memory\n");
-
+return -1;
 }
 
 /*
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index e386362..1d388f9 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -78,10 +78,10 @@ struct acpi_config {
  * This must match the OperationRegion(BIOS, SystemMemory, )
  * definition in the DSDT
  */
-unsigned int infop;
+unsigned long infop;
 
 /* RSDP address */
-unsigned int rsdp;
+unsigned long rsdp;
 
 /* x86-specific parameters */
 uint8_t (*lapic_id)(unsigned cpu);
@@ -91,7 +91,7 @@ struct acpi_config {
 uint8_t ioapic_id;
 };
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
 
 #endif /* __LIBACPI_H__ */
 
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 90427ff..336358c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -75,7 +75,21 @@ else
 LIBXL_OBJS-y += libxl_no_colo.o
 endif
 
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
+ACPI_PATH  = $(XEN_ROOT)/tools/libacpi
+ACPI_FILES = dsdt_pvh.c
+ACPI_OBJS  = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
+$(ACPI_FILES): acpi
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"$(CURDIR)/libxl_x86_acpi.h\"
+vpath build.c $(ACPI_PATH)/
+vpath static_tables.c $(ACPI_PATH)/
+LIBXL_OBJS-$(CONFIG_X86) += $(ACPI_OBJS)
+
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
+-include acpi
+
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
 
 ifeq ($(CONFIG_NetBSD),y)
@@ -167,6 +181,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
 libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+libxl_x86_acpi.o: CFLAGS += -I$(XEN_ROOT)/tools
 
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
@@ -309,6 +324,7 @@ clean:
$(RM) -f testidl.c.new testidl.c *.api-ok
$(RM) -f xenlight.pc
$(RM) -f xlutil.pc
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) clean
 
 distclean: clean
$(RM) -f xenlight.pc.in xlutil.pc.in
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 253a037..7a70b01 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -66,6 +66,9 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 
 #define LAPIC_BASE_ADDRESS  

[Xen-devel] [PATCH v4 14/21] libacpi: Build DSDT for PVH guests

[Boris Ostrovsky]

PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
that it can be included in ASLs for both HVM and PVH2.

Signed-off-by: Boris Ostrovsky 
---
 tools/libacpi/Makefile  | 7 ++-
 tools/libacpi/mk_dsdt.c | 8 
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index fdb08e6..83d6a8f 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -22,7 +22,7 @@ TMP_SUFFIX= tmp__
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
 C_SRC-$(GPL)   = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
-C_SRC  = $(addprefix $(ACPI_BUILD_DIR)/, $(C_SRC-y))
+C_SRC  = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_pvh.c $(C_SRC-y))
 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 vpath iasl $(PATH)
@@ -49,6 +49,11 @@ $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: gpl/dsdt.asl $(MK_DSDT)
$(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
 endif
 
+$(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
0)\n{" > $@
+   cat dsdt_acpi_info.asl >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> $@
+
 $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
iasl -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc 
$(ACPI_BUILD_DIR)/$*.asl
sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index e750820..8130cbd 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -23,6 +23,7 @@ static unsigned int indent_level;
 static bool debug = false;
 
 typedef enum dm_version {
+QEMU_NONE,
 QEMU_XEN_TRADITIONAL,
 QEMU_XEN,
 } dm_version;
@@ -135,6 +136,8 @@ int main(int argc, char **argv)
 dm_version = QEMU_XEN;
 } else if (strcmp(optarg, "qemu-xen-traditional") == 0) {
 dm_version = QEMU_XEN_TRADITIONAL;
+} else if (strcmp(optarg, "none") == 0) {
+dm_version = QEMU_NONE;
 } else {
 fprintf(stderr, "Unknown device model version `%s'.\n", 
optarg);
 return -1;
@@ -252,6 +255,11 @@ int main(int argc, char **argv)
 
 pop_block();
 
+if (dm_version == QEMU_NONE) {
+pop_block();
+return 0;
+}
+
 /* Define GPE control method. */
 push_block("Scope", "\\_GPE");
 push_block("Method",
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 05/21] acpi/hvmloader: Set TIS header address in hvmloader

[Boris Ostrovsky]

Users other than hvmloader may provide TIS address as virtual.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 9 -
 tools/firmware/hvmloader/acpi/libacpi.h | 3 +++
 tools/firmware/hvmloader/config.h   | 2 ++
 tools/firmware/hvmloader/util.c | 4 
 4 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 68eb7c4..c984e5a 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -335,7 +335,6 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 struct acpi_20_tcpa *tcpa;
 unsigned char *ssdt;
 static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
-uint16_t *tis_hdr;
 void *lasa;
 
 /* MADT. */
@@ -388,10 +387,10 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* TPM TCPA and SSDT. */
-tis_hdr = (uint16_t *)0xFED40F00;
-if ( (tis_hdr[0] == tis_signature[0]) &&
- (tis_hdr[1] == tis_signature[1]) &&
- (tis_hdr[2] == tis_signature[2]) )
+if ( (config->table_flags & ACPI_HAS_TCPA) &&
+ (config->tis_hdr[0] == tis_signature[0]) &&
+ (config->tis_hdr[1] == tis_signature[1]) &&
+ (config->tis_hdr[2] == tis_signature[2]) )
 {
 ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index d1e7042..70cf26b 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -27,6 +27,7 @@
 #define ACPI_HAS_SSDT_PM (1<<4)
 #define ACPI_HAS_SSDT_S3 (1<<5)
 #define ACPI_HAS_SSDT_S4 (1<<6)
+#define ACPI_HAS_TCPA(1<<7)
 
 struct xen_vmemrange;
 struct acpi_numa {
@@ -60,6 +61,8 @@ struct acpi_config {
 struct acpi_numa numa;
 const struct hvm_info_table *hvminfo;
 
+const uint16_t *tis_hdr;
+
 /*
  * Address where acpi_info should be placed.
  * This must match the OperationRegion(BIOS, SystemMemory, )
diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index a4429f4..6e00413 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -56,6 +56,8 @@ extern uint8_t ioapic_version;
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_END 0xfc00
 
+#define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
+
 extern unsigned long pci_mem_start, pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index f37b16e..8875675 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,6 +919,10 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
+config->table_flags |= ACPI_HAS_TCPA;
+
+config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
+
 config->numa.nr_vmemranges = nr_vmemranges;
 config->numa.nr_vnodes = nr_vnodes;
 config->numa.vcpu_to_vnode = vcpu_to_vnode;
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 00/21] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing 
existing
hvmloader's ACPI builder code. The builder is provided as a library in 
tools/libacpi.

This is verion 4 of the series, see individual patches for changes. It can
be fetched from git://oss.oracle.com/git/bostrovs/xen.git:acpi_v4

The most "interesting" part here (besides addressing v3 comments) is working 
around
licensing issues. This is mostly patch 2.

Boris Ostrovsky (21):
  acpi: Extract acpi info description into a separate ASL file
  acpi: Prevent GPL-only code from seeping into non-GPL binaries
  acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
  acpi/hvmloader: Collect processor and NUMA info in hvmloader
  acpi/hvmloader: Set TIS header address in hvmloader
  acpi/hvmloader: Make providing IOAPIC in MADT optional
  acpi/hvmloader: Build WAET optionally
  acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
  acpi/hvmloader: Translate all addresses when assigning addresses in
ACPI tables
  acpi/hvmloader: Link ACPI object files directly
  acpi/hvmloader: Include file/paths adjustments
  acpi: Move ACPI code to tools/libacpi
  x86: Allow LAPIC-only emulation_flags for HVM guests
  libacpi: Build DSDT for PVH guests
  acpi: Makefile should better tolerate interrupts
  libxc/libxl: Allow multiple ACPI modules
  libxl/acpi: Add ACPI e820 entry
  libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
  ilibxl: Initialize domain build info before calling libxl__domain_make
  libxl/acpi: Build ACPI tables for HVMlite guests
  libxc/xc_dom_core: Copy ACPI tables to guest space

 .gitignore |  20 +-
 MAINTAINERS|   1 +
 tools/firmware/hvmloader/Makefile  |  24 +-
 tools/firmware/hvmloader/acpi/Makefile |  72 --
 tools/firmware/hvmloader/acpi/dsdt.asl | 480 
 tools/firmware/hvmloader/acpi/ssdt_tpm.asl |  30 -
 tools/firmware/hvmloader/config.h  |   2 +
 tools/firmware/hvmloader/hvmloader.c   |   2 +-
 tools/firmware/hvmloader/ovmf.c|   2 +-
 tools/firmware/hvmloader/rombios.c |   2 +-
 tools/firmware/hvmloader/seabios.c |   5 +-
 tools/firmware/hvmloader/util.c|  52 +-
 tools/firmware/hvmloader/util.h|   2 +-
 tools/firmware/rombios/32bit/Makefile  |   2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile  |   2 +-
 tools/firmware/rombios/32bit/util.h|   2 +-
 tools/libacpi/Makefile |  84 ++
 tools/{firmware/hvmloader/acpi => libacpi}/README  |  16 +-
 .../{firmware/hvmloader/acpi => libacpi}/acpi2_0.h |  19 +-
 tools/{firmware/hvmloader/acpi => libacpi}/build.c | 303 
 tools/libacpi/dsdt_acpi_info.asl   |  26 +
 tools/libacpi/gpl/COPYING  |   5 +
 tools/libacpi/gpl/dsdt.asl | 846 +
 .../{firmware/hvmloader/acpi => libacpi}/libacpi.h |  37 +-
 .../{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c |  88 +--
 .../hvmloader/acpi => libacpi}/ssdt_pm.asl |  11 +-
 .../hvmloader/acpi => libacpi}/ssdt_s3.asl |  11 +-
 .../hvmloader/acpi => libacpi}/ssdt_s4.asl |  11 +-
 tools/libacpi/ssdt_tpm.asl |  28 +
 .../hvmloader/acpi => libacpi}/static_tables.c |  18 +-
 tools/libxc/include/xc_dom.h   |   5 +-
 tools/libxc/xc_dom_core.c  |  95 +++
 tools/libxc/xc_dom_hvmloader.c |   3 +-
 tools/libxl/Makefile   |  20 +-
 tools/libxl/libxl_arch.h   |   9 +
 tools/libxl/libxl_create.c |  22 +-
 tools/libxl/libxl_dom.c|  53 +-
 tools/libxl/libxl_x86.c|  45 +-
 tools/libxl/libxl_x86_acpi.c   | 243 ++
 tools/libxl/libxl_x86_acpi.h   |  35 +
 xen/arch/x86/domain.c  |  26 +-
 41 files changed, 1847 insertions(+), 912 deletions(-)
 delete mode 100644 tools/firmware/hvmloader/acpi/Makefile
 delete mode 100644 tools/firmware/hvmloader/acpi/dsdt.asl
 delete mode 100644 tools/firmware/hvmloader/acpi/ssdt_tpm.asl
 create mode 100644 tools/libacpi/Makefile
 rename tools/{firmware/hvmloader/acpi => libacpi}/README (60%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (95%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (63%)
 create mode 100644 tools/libacpi/dsdt_acpi_info.asl
 create mode 100644 tools/libacpi/gpl/COPYING
 create mode 100644 tools/libacpi/gpl/dsdt.asl
 rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (64%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (82%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl (97%)
 rename 

[Xen-devel] [PATCH v4 19/21] ilibxl: Initialize domain build info before calling libxl__domain_make

[Boris Ostrovsky]

libxl__domain_make() may want to use b_info so we should set defaults
a little earlier.

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_create.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 04f8ae9..07b2b4b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -899,17 +899,6 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
-ret = libxl__domain_make(gc, d_config, , >config);
-if (ret) {
-LOG(ERROR, "cannot make domain: %d", ret);
-dcs->guest_domid = domid;
-ret = ERROR_FAIL;
-goto error_out;
-}
-
-dcs->guest_domid = domid;
-dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
-
 ret = libxl__domain_build_info_setdefault(gc, _config->b_info);
 if (ret) {
 LOG(ERROR, "Unable to set domain build info defaults");
@@ -923,6 +912,17 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+ret = libxl__domain_make(gc, d_config, , >config);
+if (ret) {
+LOG(ERROR, "cannot make domain: %d", ret);
+dcs->guest_domid = domid;
+ret = ERROR_FAIL;
+goto error_out;
+}
+
+dcs->guest_domid = domid;
+dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
+
 /*
  * Set the dm version quite early so that libxl doesn't have to pass the
  * build info around just to know if the domain has a device model or not.
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
GPLv2. We want to prevent this code from showing up in non-GPL
binaries which might become possible after we make ACPI builder code
available to users other than hvmloader.

There are two pieces that we need to be careful about:
(1) A small piece of code in dsdt.asl that implements _PIC method
(2) A fragment of ASL generator in mk_dsdt.c that describes PCI
interrupt routing.

The cleanest way to deal with this seems to be taking generatedi ASL
chunk from (2), adding it to dsdt.asl and keeping dsdt.asl GPL-only.

Signed-off-by: Boris Ostrovsky 
---
CC: Lars Kurth 
---

Changes in v4:
* New in v4
  Added code in new dsdt.asl is
  +Scope ( \_SB.PCI0 )
  +{
  +Name ( BUFA, ResourceTemplate() { IRQ(Level, ActiveLow, Shared) { 5, 
10, 11 } } )
   ...
  +})
  +}

 tools/firmware/hvmloader/Makefile  |   4 +
 tools/firmware/hvmloader/acpi/Makefile |   9 +-
 tools/firmware/hvmloader/acpi/dsdt.asl | 461 
 tools/firmware/hvmloader/acpi/gpl/COPYING  |   5 +
 tools/firmware/hvmloader/acpi/gpl/dsdt.asl | 846 +
 tools/firmware/hvmloader/acpi/mk_dsdt.c|  68 +--
 6 files changed, 862 insertions(+), 531 deletions(-)
 delete mode 100644 tools/firmware/hvmloader/acpi/dsdt.asl
 create mode 100644 tools/firmware/hvmloader/acpi/gpl/COPYING
 create mode 100644 tools/firmware/hvmloader/acpi/gpl/dsdt.asl

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 9f7357f..23b0a58 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -65,6 +65,10 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 endif
 
+# Certain parts of ACPI builder are GPL-only
+GPL = y
+export GPL
+
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index 76da073..32d8c22 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -17,7 +17,8 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
dsdt_anycpu_qemu_xen.c
+C_SRC-$(GPL)   = build.c dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+C_SRC  = build.c static_tables.c $(C_SRC-y)
 OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 
 CFLAGS += $(CFLAGS_xeninclude)
@@ -33,16 +34,18 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 mk_dsdt: mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
+ifeq ($(GPL),y)
+dsdt_anycpu_qemu_xen.asl: gpl/dsdt.asl dsdt_acpi_info.asl mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@
cat dsdt_acpi_info.asl >> $@
./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
+dsdt_%cpu.asl: gpl/dsdt.asl dsdt_acpi_info.asl mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@
cat dsdt_acpi_info.asl >> $@
./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@
+endif
 
 $(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
iasl -vs -p $* -tc $*.asl
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl 
b/tools/firmware/hvmloader/acpi/dsdt.asl
deleted file mode 100644
index 4f6db79..000
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ /dev/null
@@ -1,461 +0,0 @@
-/**
- * DSDT for Xen with Qemu device model
- *
- * Copyright (c) 2004, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; If not, see .
- */
-
-DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
-{
-Name (\PMBS, 0x0C00)
-Name (\PMLN, 0x08)
-Name (\IOB1, 0x00)
-Name (\IOL1, 0x00)
-Name (\APCB, 0xFEC0)
-Name (\APCL, 0x0001)
-Name (\PUID, 0x00)
-
-/* _S3 and _S4 are in separate SSDTs */
-Name (\_S5, Package (0x04)
-{
-0x00,  /* PM1a_CNT.SLP_TYP */
-0x00,  /* PM1b_CNT.SLP_TYP */
-0x00,  /* reserved */
-0x00   /* reserved */
-  

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On September 19, 2016 5:25 PM, Tian Kevin  wrote:
>> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
>> Sent: Monday, September 12, 2016 5:08 PM
>>
>> On September 12, 2016 3:58 PM, Tian, Kevin  wrote:
>> >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
>> >> Sent: Friday, September 09, 2016 11:02 AM
>> >>
>> >> On August 30, 2016 1:58 PM, Tian Kevin < kevin.t...@intel.com > wrote:
>> >> >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
>> >> >> Sent: Friday, August 19, 2016 8:59 PM
>> >> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
>> >> index 1d5d287..cc247c3 100644
>> >> --- a/xen/arch/x86/hvm/vlapic.c
>> >> +++ b/xen/arch/x86/hvm/vlapic.c
>> >> @@ -433,6 +433,11 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>> >> void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)  {
>> >>  struct domain *d = vlapic_domain(vlapic);
>> >> +struct hvm_intack pt_intack;
>> >> +
>> >> +pt_intack.vector = vector;
>> >> +pt_intack.source = hvm_intsrc_lapic;
>> >> +pt_intr_post(vlapic_vcpu(vlapic), pt_intack);
>> >>
>> >>  if ( vlapic_test_and_clear_vector(vector,
>> >>regs->data[APIC_TMR]) )
>> >>  vioapic_update_EOI(d, vector); diff --git
>> >> a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c index
>> >> 8fca08c..29d9bbf 100644
>> >> --- a/xen/arch/x86/hvm/vmx/intr.c
>> >> +++ b/xen/arch/x86/hvm/vmx/intr.c
>> >> @@ -333,8 +333,6 @@ void vmx_intr_assist(void)
>> >>  clear_bit(i, >arch.hvm_vmx.eoi_exitmap_changed);
>> >>  __vmwrite(EOI_EXIT_BITMAP(i),
>> >v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>> >>  }
>> >> -
>> >> -pt_intr_post(v, intack);
>> >>  }
>> >>  else
>> >>  {
>> >>
>> >
>> >Because we update pt irq in every vmentry, there is a chance that
>> >already-injected instance (before EOI-induced exit happens) will
>> >incur another pending IRR setting if there is a VM-exit happens
>> >between HW virtual interrupt injection (vIRR->0, vISR->1) and
>> >EOI-induced exit (vISR->0), since pt_intr_post hasn't been invoked
>> >yet. I guess this is the reason why you still see faster wallclock.
>> >
>>
>> Agreed. A good description. My bad description is from another aspect.
>>
>> >I think you need mark this pending_intr_post situation explicitly.
>> >Then pt_update_irq should skip such pt timer when pending_intr_post
>> >of that timer is true (otherwise the update is meaningless since
>> >previous one hasn't been posted yet). Then with your change to post
>> >in EOI-induced exit handler, it should work correctly to meet the
>> >goal
>> >- one virtual interrupt delivery for one pending pt intr...
>> >
>> I think we are at least on the right track.
>> But I can't follow ' pending_intr_post ', a new parameter? Thanks.
>>
>>
>
>yes, a new parameter to record whether a intr_post operation is pending


The existing parameter ' irq_issued ' looks good. I have tested with below 
modification last night, and it is working. 
If it is okay, I will send out v2..

Quan

 modification =
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 1d5d287..cc247c3 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -433,6 +433,11 @@ void vlapic_EOI_set(struct vlapic *vlapic)
 void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
 {
 struct domain *d = vlapic_domain(vlapic);
+struct hvm_intack pt_intack;
+
+pt_intack.vector = vector;
+pt_intack.source = hvm_intsrc_lapic;
+pt_intr_post(vlapic_vcpu(vlapic), pt_intack);

 if ( vlapic_test_and_clear_vector(vector, >regs->data[APIC_TMR]) )
 vioapic_update_EOI(d, vector);
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 8fca08c..29d9bbf 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -333,8 +333,6 @@ void vmx_intr_assist(void)
 clear_bit(i, >arch.hvm_vmx.eoi_exitmap_changed);
 __vmwrite(EOI_EXIT_BITMAP(i), v->arch.hvm_vmx.eoi_exit_bitmap[i]);
 }
-
-pt_intr_post(v, intack);
 }
 else
 {
diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
index 5c48fdb..620ca68 100644
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -267,6 +267,11 @@ int pt_update_irq(struct vcpu *v)
 return -1;
 }

+if ( earliest_pt->irq_issued )
+{
+spin_unlock(>arch.hvm_vcpu.tm_lock);
+return -1;
+}
 earliest_pt->irq_issued = 1;
 irq = earliest_pt->irq;
 is_lapic = (earliest_pt->source == PTSRC_lapic);


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 13/21] x86: Allow LAPIC-only emulation_flags for HVM guests

[Boris Ostrovsky]

PVHv2 guests may request LAPIC emulation (and nothing else)

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/domain.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3c4b094..1bd5eb6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 }
 else
 {
-if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
+uint32_t emflags;
+
+if ( is_hardware_domain(d) )
+config->emulation_flags |= XEN_X86_EMU_PIT;
+
+emflags = config->emulation_flags;
+if ( emflags & ~XEN_X86_EMU_ALL )
 {
 printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
-   d->domain_id, config->emulation_flags);
+   d->domain_id, emflags);
 return -EINVAL;
 }
-if ( is_hardware_domain(d) )
-config->emulation_flags |= XEN_X86_EMU_PIT;
-if ( config->emulation_flags != 0 &&
- (config->emulation_flags !=
-  (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
+
+/* PVHv2 guests can request emulated APIC. */
+if ( emflags &&
+(is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
+ (emflags != XEN_X86_EMU_LAPIC)) :
+(emflags != XEN_X86_EMU_PIT)) )
 {
 printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
-   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV",
-   config->emulation_flags);
+   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
 return -EOPNOTSUPP;
 }
-d->arch.emulation_flags = config->emulation_flags;
+d->arch.emulation_flags = emflags;
 }
 
 if ( has_hvm_container_domain(d) )
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 12/21] acpi: Move ACPI code to tools/libacpi

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 MAINTAINERS|  1 +
 tools/firmware/hvmloader/Makefile  | 14 --
 tools/firmware/hvmloader/ovmf.c|  2 +-
 tools/firmware/rombios/32bit/Makefile  |  2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile  |  2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/Makefile|  2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/README  |  0
 tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/build.c |  0
 .../hvmloader/acpi => libacpi}/dsdt_acpi_info.asl  |  0
 tools/{firmware/hvmloader/acpi => libacpi}/gpl/COPYING |  0
 tools/{firmware/hvmloader/acpi => libacpi}/gpl/dsdt.asl|  0
 tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl|  0
 tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c |  0
 19 files changed, 13 insertions(+), 10 deletions(-)
 rename tools/{firmware/hvmloader/acpi => libacpi}/Makefile (98%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/README (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt_acpi_info.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/gpl/COPYING (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/gpl/dsdt.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 97720a8..07545f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,7 @@ S:  Supported
 F: xen/arch/x86/acpi/
 F: xen/drivers/acpi/
 F: xen/include/acpi/
+F: tools/libacpi/
 
 AMD IOMMU
 M: Suravee Suthikulpanit 
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 7b3641c..c19986a 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,10 +20,7 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-export ACPI_BUILD_DIR=$(CURDIR)
-SUBDIRS := acpi
 
-# The HVM loader is started in 32-bit mode at the address below:
 LOADADDR = 0x10
 
 # SMBIOS spec requires format mm/dd/
@@ -71,16 +68,20 @@ GPL = y
 export GPL
 
 .PHONY: all
-all: subdirs-all
+all: acpi subdirs-all
$(MAKE) hvmloader
 
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR)
+
 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-ACPI_PATH = acpi
+ACPI_PATH = ../../libacpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
-$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"../util.h\"
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"$(CURDIR)/util.h\"
 CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)
 vpath static_tables.c $(ACPI_PATH)
@@ -122,6 +123,7 @@ endif
 clean: subdirs-clean
rm -f roms.inc roms.inc.new acpi.h
rm -f hvmloader hvmloader.tmp *.o $(DEPS)
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR) clean
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 0ac3416..4ff7f1d 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -23,7 +23,7 @@
 
 #include "config.h"
 #include "smbios_types.h"
-#include "acpi/libacpi.h"
+#include "libacpi.h"
 #include "apic_regs.h"
 #include "../rombios/config.h"
 #include "util.h"
diff --git a/tools/firmware/rombios/32bit/Makefile 
b/tools/firmware/rombios/32bit/Makefile
index 71399d2..b0583c9 100644
--- a/tools/firmware/rombios/32bit/Makefile
+++ b/tools/firmware/rombios/32bit/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 TARGET = 32bitbios_flat.h
 
-CFLAGS += $(CFLAGS_xeninclude) -I.. -I../../hvmloader/acpi
+CFLAGS += $(CFLAGS_xeninclude) -I.. -I../../../libacpi
 
 SUBDIRS = tcgbios
 
diff --git 

[Xen-devel] [PATCH v4 03/21] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

[Boris Ostrovsky]

ACPI builder is currently distributed under GPLv2 license.

We plan to make the builder available to components other
than the hvmloader (which is also GPLv2). Some of these
components (such as libxl) may be distributed under LGPL-2.1
so that they can be used by non-GPLv2 callers.  But this
will not be possible if we incorporate the ACPI builder in
those other components.

To avoid this problem we are relicensing sources in ACPI
bulder directory to the Lesser GNU Public License (LGPL)
version 2.1

(dsdt.asl remains GPLv2 as we might need permission from Lenovo
due to commit 801d469ad ("[HVM] ACPI support patch 3 of 4: ACPI
_PRT table."))

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel Kiper 
Acked-by: Stefan Berger 
Acked-by: Kouya Shimura 
Acked-by: Jan Beulich 
Acked-by: Kevin Tian 
Acked-by: Keir Fraser 
Acked-by: Simon Horman 
Acked-by: Lars Kurth 
Acked-by: Konrad Rzeszutek Wilk  [for Oracle, 
VirtualIron and Sun contributions]
---
CC: Daniel Kiper 
CC: Stefan Berger 
CC: Kouya Shimura 
CC: Jan Beulich 
CC: Kevin Tian 
CC: Keir Fraser 
CC: Simon Horman 
CC: Lars Kurth 
CC: Konrad Rzeszutek Wilk 
CC: k...@lenovo.com
---

Changes in v4:
* Dropped dsdt.asl until Lenovo ACK is received (note that mk_dsdt.c *is* made 
LGPL)

 tools/firmware/hvmloader/acpi/Makefile| 18 --
 tools/firmware/hvmloader/acpi/acpi2_0.h   | 19 ---
 tools/firmware/hvmloader/acpi/build.c | 18 --
 tools/firmware/hvmloader/acpi/mk_dsdt.c   | 12 
 tools/firmware/hvmloader/acpi/ssdt_pm.asl | 11 ---
 tools/firmware/hvmloader/acpi/ssdt_s3.asl | 11 ---
 tools/firmware/hvmloader/acpi/ssdt_s4.asl | 11 ---
 tools/firmware/hvmloader/acpi/ssdt_tpm.asl| 18 --
 tools/firmware/hvmloader/acpi/static_tables.c | 18 --
 9 files changed, 64 insertions(+), 72 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index 32d8c22..c6382bd 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -1,17 +1,15 @@
 #
 # Copyright (c) 2004, Intel Corporation.
 #
-# This program is free software; you can redistribute it and/or modify it
-# under the terms and conditions of the GNU General Public License,
-# version 2, as published by the Free Software Foundation.
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License as published
+# by the Free Software Foundation; version 2.1 only. with the special
+# exception on linking described in file LICENSE.
 #
-# This program is distributed in the hope it will be useful, but WITHOUT
-# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-# more details.
-#
-# You should have received a copy of the GNU General Public License along with
-# this program; If not, see .
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# NU Lesser General Public License for more details.
 #
 
 XEN_ROOT = $(CURDIR)/../../../..
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h 
b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 87a558a..775eb7a 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -1,18 +1,15 @@
 /*
  * Copyright (c) 2004, Intel Corporation.
  *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; If not, see .
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
  *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT 

[Xen-devel] [PATCH v4 16/21] libxc/libxl: Allow multiple ACPI modules

[Boris Ostrovsky]

Provide ability to load multiple ACPI modules. Thie feature is needed
by PVHv2 guests and will be used in subsequent patches.

We assume that PVHv2 guests do not load their ACPI modules specified
in the configuration file. We can extend support for that in the future
if desired.

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
 tools/libxc/include/xc_dom.h   |  5 +++--
 tools/libxc/xc_dom_hvmloader.c |  3 ++-
 tools/libxl/libxl_dom.c| 26 ++
 3 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index de7dca9..608cbc2 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -212,8 +212,9 @@ struct xc_dom_image {
 /* BIOS/Firmware passed to HVMLOADER */
 struct xc_hvm_firmware_module system_firmware_module;
 
-/* Extra ACPI tables passed to HVMLOADER */
-struct xc_hvm_firmware_module acpi_module;
+/* Extra ACPI tables */
+#define MAX_ACPI_MODULES4
+struct xc_hvm_firmware_module acpi_modules[MAX_ACPI_MODULES];
 
 /* Extra SMBIOS structures passed to HVMLOADER */
 struct xc_hvm_firmware_module smbios_module;
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 6eb8516..59f94e5 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -172,7 +172,8 @@ static int modules_init(struct xc_dom_image *dom)
 rc = module_init_one(dom, >system_firmware_module,
  "System Firmware module");
 if ( rc ) goto err;
-rc = module_init_one(dom, >acpi_module, "ACPI module");
+/* Only one module can be added */
+rc = module_init_one(dom, >acpi_modules[0], "ACPI module");
 if ( rc ) goto err;
 rc = module_init_one(dom, >smbios_module, "SMBIOS module");
 if ( rc ) goto err;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c895649..c4be916 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -818,7 +818,8 @@ static int hvm_build_set_params(xc_interface *handle, 
uint32_t domid,
 
 static int hvm_build_set_xs_values(libxl__gc *gc,
uint32_t domid,
-   struct xc_dom_image *dom)
+   struct xc_dom_image *dom,
+   const libxl_domain_build_info *info)
 {
 char *path = NULL;
 int ret = 0;
@@ -839,18 +840,20 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
 goto err;
 }
 
-if (dom->acpi_module.guest_addr_out) {
+/* Only one module can be passed. PVHv2 guests do not support this. */
+if (dom->acpi_modules[0].guest_addr_out && 
+info->device_model_version !=LIBXL_DEVICE_MODEL_VERSION_NONE) {
 path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS, domid);
 
 ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%"PRIx64,
-   dom->acpi_module.guest_addr_out);
+   dom->acpi_modules[0].guest_addr_out);
 if (ret)
 goto err;
 
 path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH, domid);
 
 ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%x",
-   dom->acpi_module.length);
+   dom->acpi_modules[0].length);
 if (ret)
 goto err;
 }
@@ -994,6 +997,13 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 
 if (info->u.hvm.acpi_firmware) {
+
+if (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE) {
+LOGE(ERROR, "PVH guests do not allow loading ACPI modules");
+rc = ERROR_FAIL;
+goto out;
+}
+
 data = NULL;
 e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
  , );
@@ -1005,9 +1015,9 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 libxl__ptr_add(gc, data);
 if (datalen) {
-/* Only accept non-empty files */
-dom->acpi_module.data = data;
-dom->acpi_module.length = (uint32_t)datalen;
+/* Only accept a non-empty file */
+dom->acpi_modules[0].data = data;
+dom->acpi_modules[0].length = (uint32_t)datalen;
 }
 }
 
@@ -1143,7 +1153,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 goto out;
 }
 
-rc = hvm_build_set_xs_values(gc, domid, dom);
+rc = hvm_build_set_xs_values(gc, domid, dom, info);
 if (rc != 0) {
 LOG(ERROR, "hvm build set xenstore values failed");
 goto out;
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 08/21] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

[Boris Ostrovsky]

Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
Changes in v4:
* Added comment to acpi_mem_free()

 tools/firmware/hvmloader/acpi/build.c   | 95 ++---
 tools/firmware/hvmloader/acpi/libacpi.h | 10 +++-
 tools/firmware/hvmloader/util.c | 24 -
 3 files changed, 84 insertions(+), 45 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 537933b..1dd9987 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -71,7 +71,8 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(const struct acpi_config *config,
+static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config,
struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
@@ -86,7 +87,7 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 sz += sizeof(struct acpi_20_madt_ioapic);
 sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
 
-madt = mem_alloc(sz, 16);
+madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
 if (!madt) return NULL;
 
 memset(madt, 0, sizeof(*madt));
@@ -166,11 +167,12 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 return madt;
 }
 
-static struct acpi_20_hpet *construct_hpet(void)
+static struct acpi_20_hpet *construct_hpet(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_hpet *hpet;
 
-hpet = mem_alloc(sizeof(*hpet), 16);
+hpet = ctxt->mem_ops.alloc(ctxt, sizeof(*hpet), 16);
 if (!hpet) return NULL;
 
 memset(hpet, 0, sizeof(*hpet));
@@ -189,11 +191,12 @@ static struct acpi_20_hpet *construct_hpet(void)
 return hpet;
 }
 
-static struct acpi_20_waet *construct_waet(void)
+static struct acpi_20_waet *construct_waet(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_waet *waet;
 
-waet = mem_alloc(sizeof(*waet), 16);
+waet = ctxt->mem_ops.alloc(ctxt, sizeof(*waet), 16);
 if (!waet) return NULL;
 
 memcpy(waet, , sizeof(*waet));
@@ -204,7 +207,8 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(const struct acpi_config *config)
+static struct acpi_20_srat *construct_srat(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -216,7 +220,7 @@ static struct acpi_20_srat *construct_srat(const struct 
acpi_config *config)
 size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
sizeof(*memory) * config->numa.nr_vmemranges;
 
-p = mem_alloc(size, 16);
+p = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !p )
 return NULL;
 
@@ -262,7 +266,8 @@ static struct acpi_20_srat *construct_srat(const struct 
acpi_config *config)
 return srat;
 }
 
-static struct acpi_20_slit *construct_slit(const struct acpi_config *config)
+static struct acpi_20_slit *construct_slit(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_slit *slit;
 unsigned int i, num, size;
@@ -270,7 +275,7 @@ static struct acpi_20_slit *construct_slit(const struct 
acpi_config *config)
 num = config->numa.nr_vnodes * config->numa.nr_vnodes;
 size = sizeof(*slit) + num * sizeof(uint8_t);
 
-slit = mem_alloc(size, 16);
+slit = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !slit )
 return NULL;
 
@@ -294,7 +299,8 @@ static struct acpi_20_slit *construct_slit(const struct 
acpi_config *config)
 return slit;
 }
 
-static int construct_passthrough_tables(unsigned long *table_ptrs,
+static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
+unsigned long *table_ptrs,
 int nr_tables,
 struct acpi_config *config)
 {
@@ -317,7 +323,7 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 
 header = (struct acpi_header*)pt_addr;
 
-buffer = mem_alloc(header->length, 16);
+buffer = ctxt->mem_ops.alloc(ctxt, header->length, 16);
 if ( buffer == NULL )
 break;
 memcpy(buffer, header, header->length);
@@ -330,7 +336,8 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 return nr_added;
 }
 

[Xen-devel] [PATCH v4 18/21] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
 tools/libxl/Makefile |  2 ++
 tools/libxl/libxl_arch.h |  6 ++
 tools/libxl/libxl_dom.c  | 19 +++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a3c0af8..90427ff 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -166,6 +166,8 @@ $(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
+libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
 
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 34a853c..253a037 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -62,4 +62,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 uint32_t domid,
 struct xc_dom_image *dom);
 
+#if defined(__i386__) || defined(__x86_64__)
+
+#define LAPIC_BASE_ADDRESS  0xfee0
+
+#endif
+
 #endif
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7974302..2924629 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1077,10 +1077,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->target_pages = mem_size >> XC_PAGE_SHIFT;
 if (dom->mmio_size == 0 && device_model)
 dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
-else if (dom->mmio_size == 0 && !device_model)
-dom->mmio_size = GB(4) -
-((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
-<< XC_PAGE_SHIFT);
+else if (dom->mmio_size == 0 && !device_model) {
+#if defined(__i386__) || defined(__x86_64__)
+if (libxl_defbool_val(info->u.hvm.apic)) {
+/* Make sure LAPIC_BASE_ADDRESS is below special pages */
+assert(X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+  << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= 
XC_PAGE_SIZE);
+dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
+} else
+dom->mmio_size = GB(4) -
+((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+ << XC_PAGE_SHIFT);
+#else
+assert(1);
+#endif
+}
 lowmem_end = mem_size;
 highmem_end = 0;
 mmio_start = (1ull << 32) - dom->mmio_size;
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 15/21] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

Intermediate stages of building a target should be made with
temporary files that are copied to final target in the end.

Signed-off-by: Boris Ostrovsky 
---
Changes in v4:
* Instead of storing those intermediate files in /tmp keep then locally
  by adding TMP_SUFFIX to target.

 tools/libacpi/Makefile | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 83d6a8f..68351c7 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -15,7 +15,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-# Used as a workaround for a bug in some older iasl versions where
+# Suffix for temporary files.
+# Also used as a workaround for a bug in some older iasl versions where
 # the tool will ignore everything after last '.' in the path ('-p' argument)
 TMP_SUFFIX = tmp__
 
@@ -38,26 +39,30 @@ $(MK_DSDT): mk_dsdt.c
 
 ifeq ($(GPL),y)
 $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: gpl/dsdt.asl $(MK_DSDT)
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   cat dsdt_acpi_info.asl >> $@
-   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
+   mv -f $@.$(TMP_SUFFIX) $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
 $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: gpl/dsdt.asl $(MK_DSDT)
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   cat dsdt_acpi_info.asl >> $@
-   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
+   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
+   mv -f $@.$(TMP_SUFFIX) $@
 endif
 
 $(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
-   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
0)\n{" > $@
-   cat dsdt_acpi_info.asl >> $@
-   $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> $@
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
0)\n{" > $@.$(TMP_SUFFIX)
+   cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
+   $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> 
$@.$(TMP_SUFFIX)
+   mv -f $@.$(TMP_SUFFIX) $@
 
 $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
iasl -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc 
$(ACPI_BUILD_DIR)/$*.asl
-   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
-   echo "int $*_len=sizeof($*);" >>$@
+   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@.$(TMP_SUFFIX)
+   echo "int $*_len=sizeof($*);" >>$@.$(TMP_SUFFIX)
+   mv -f $@.$(TMP_SUFFIX) $@
rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
 
 iasl:
@@ -70,6 +75,7 @@ iasl:
 
 clean:
rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
+   rm -f $(C_SRC:=.$(TMP_SUFFIX)) $(patsubst %.c,%.hex,$(C_SRC)) 
$(patsubst %.c,%.aml,$(C_SRC))
 
 distclean: clean
 
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 17/21] libxl/acpi: Add ACPI e820 entry

[Boris Ostrovsky]

Add entry for ACPI tables created for PVHv2 guests to e820 map.

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_dom.c |  8 
 tools/libxl/libxl_x86.c | 15 +++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c4be916..7974302 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1134,16 +1134,16 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
 }
 
+rc = libxl__build_dom(gc, domid, info, state, dom);
+if (rc != 0)
+goto out;
+
 rc = libxl__arch_domain_construct_memmap(gc, d_config, domid, dom);
 if (rc != 0) {
 LOG(ERROR, "setting domain memory map failed");
 goto out;
 }
 
-rc = libxl__build_dom(gc, domid, info, state, dom);
-if (rc != 0)
-goto out;
-
 rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
>store_mfn, state->console_port,
>console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..2b221aa 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -492,6 +492,7 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 uint64_t highmem_size =
 dom->highmem_end ? dom->highmem_end - (1ull << 32) : 0;
 uint32_t lowmem_start = dom->device_model ? GUEST_LOW_MEM_START_DEFAULT : 
0;
+unsigned page_size = XC_DOM_PAGE_SIZE(dom);
 
 /* Add all rdm entries. */
 for (i = 0; i < d_config->num_rdms; i++)
@@ -503,6 +504,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 if (highmem_size)
 e820_entries++;
 
+for (i = 0; i < MAX_ACPI_MODULES; i++)
+if (dom->acpi_modules[i].length)
+e820_entries++;
+
 if (e820_entries >= E820MAX) {
 LOG(ERROR, "Ooops! Too many entries in the memory map!");
 rc = ERROR_INVAL;
@@ -528,6 +533,16 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 nr++;
 }
 
+for (i = 0; i < MAX_ACPI_MODULES; i++) {
+if (dom->acpi_modules[i].length) {
+e820[nr].addr = dom->acpi_modules[i].guest_addr_out & ~(page_size 
- 1);
+e820[nr].size = dom->acpi_modules[i].length +
+(dom->acpi_modules[i].guest_addr_out & (page_size - 1));
+e820[nr].type = E820_ACPI;
+nr++;
+}
+}
+
 /* High memory */
 if (highmem_size) {
 e820[nr].addr = ((uint64_t)1 << 32);
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 04/21] acpi/hvmloader: Collect processor and NUMA info in hvmloader

[Boris Ostrovsky]

No need for ACPI code to rely on hvm_info variable.

Signed-off-by: Boris Ostrovsky 
---
Changes in v4:
* Constified mode things (struct acpi_config's hvminfo, test_bit's argument)
* Removed xen/memory.h from libacpi.h


 tools/firmware/hvmloader/acpi/build.c   | 52 ++---
 tools/firmware/hvmloader/acpi/libacpi.h | 11 +++
 tools/firmware/hvmloader/util.c |  9 ++
 tools/firmware/hvmloader/util.h |  2 +-
 4 files changed, 49 insertions(+), 25 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index de56f1f..68eb7c4 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -24,6 +24,7 @@
 #include "../vnuma.h"
 #include 
 #include 
+#include 
 
 #define ACPI_MAX_SECONDARY_TABLES 16
 
@@ -70,18 +71,20 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(struct acpi_info *info)
+static struct acpi_20_madt *construct_madt(const struct acpi_config *config,
+   struct acpi_info *info)
 {
 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;
 
 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) * hvm_info->nr_vcpus;
+sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
 
 madt = mem_alloc(sz, 16);
 if (!madt) return NULL;
@@ -134,9 +137,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 io_apic->ioapic_addr = ioapic_base_address;
 
 lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
-info->nr_cpus = hvm_info->nr_vcpus;
+info->nr_cpus = hvminfo->nr_vcpus;
 info->madt_lapic0_addr = (uint32_t)lapic;
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
 lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
@@ -144,7 +147,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 /* Processor ID must match processor-object IDs in the DSDT. */
 lapic->acpi_processor_id = i;
 lapic->apic_id = LAPIC_ID(i);
-lapic->flags = (test_bit(i, hvm_info->vcpu_online)
+lapic->flags = (test_bit(i, hvminfo->vcpu_online)
 ? ACPI_LOCAL_APIC_ENABLED : 0);
 lapic++;
 }
@@ -195,7 +198,7 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(void)
+static struct acpi_20_srat *construct_srat(const struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -204,8 +207,8 @@ static struct acpi_20_srat *construct_srat(void)
 void *p;
 unsigned int i;
 
-size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
-   sizeof(*memory) * nr_vmemranges;
+size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
+   sizeof(*memory) * config->numa.nr_vmemranges;
 
 p = mem_alloc(size, 16);
 if ( !p )
@@ -222,25 +225,26 @@ static struct acpi_20_srat *construct_srat(void)
 srat->table_revision  = ACPI_SRAT_TABLE_REVISION;
 
 processor = (struct acpi_20_srat_processor *)(srat + 1);
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 processor->type = ACPI_PROCESSOR_AFFINITY;
 processor->length   = sizeof(*processor);
-processor->domain   = vcpu_to_vnode[i];
+processor->domain   = config->numa.vcpu_to_vnode[i];
 processor->apic_id  = LAPIC_ID(i);
 processor->flags= ACPI_LOCAL_APIC_AFFIN_ENABLED;
 processor++;
 }
 
 memory = (struct acpi_20_srat_memory *)processor;
-for ( i = 0; i < nr_vmemranges; i++ )
+for ( i = 0; i < config->numa.nr_vmemranges; i++ )
 {
 memory->type  = ACPI_MEMORY_AFFINITY;
 memory->length= sizeof(*memory);
-memory->domain= vmemrange[i].nid;
+memory->domain= config->numa.vmemrange[i].nid;
 memory->flags = ACPI_MEM_AFFIN_ENABLED;
-memory->base_address  = vmemrange[i].start;
-memory->mem_length= vmemrange[i].end - vmemrange[i].start;
+memory->base_address  = config->numa.vmemrange[i].start;
+memory->mem_length= config->numa.vmemrange[i].end -
+config->numa.vmemrange[i].start;
 memory++;
 }
 
@@ -252,12 +256,12 @@ static struct acpi_20_srat *construct_srat(void)
 return srat;
 }
 
-static struct acpi_20_slit 

[Xen-devel] [xen-4.5-testing test] 101015: regressions - FAIL

[osstest service owner]

flight 101015 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101015/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-buildfail REGR. vs. 100909
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 100909
 build-i3865 xen-buildfail REGR. vs. 100909

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 100909

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu 12 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Mon, 2016-09-19 at 21:33 +0800, Peng Fan wrote:
> On Mon, Sep 19, 2016 at 11:33:58AM +0100, George Dunlap wrote:
> > 
> > No, I think it would be a lot simpler to just teach the scheduler
> > about
> > different classes of cpus.  credit1 would probably need to be
> > modified
> > so that its credit algorithm would be per-class rather than pool-
> > wide;
> > but credit2 shouldn't need much modification at all, other than to
> > make
> > sure that a given runqueue doesn't include more than one class; and
> > to
> > do load-balancing only with runqueues of the same class.
> 
> I try to follow.
>  - scheduler needs to be aware of different classes of cpus. ARM
> big.Little cpus.
>
Yes, I think this is essential.

>  - scheduler schedules vcpus on different physical cpus in one
> cpupool.
>
Yep, that's what the scheduler does. And personally, I'd start
implementing big.LITTLE support for a situation where both big and
LITTLE cpus coexists in the same pool.

>  - different cpu classes needs to be in different runqueue.
> 
Yes. So, basically, imagine to use vcpu pinning to support big.LITTLE.
I've spoken briefly about this in my reply to Juergen. You probably can
even get something like this up-&-running by writing very few or zero
code (you'll need --for now-- max_dom0_vcpus, dom0_vcpus_pin, and then,
in domain config files, "cpus='...'").

Then, the real goal, would be to achieve the same behavior
automatically, by acting on runqueues' arrangement and load balancing
logic in the scheduler(s).

Anyway, sorry for my ignorance on big.LITTLE, but there's something I'm
missing: _when_ is it that it is (or needs to be) decided whether a
vcpu will run on a big or LITTLE core?

Thinking to a bare metal system, I think that cpu X is, for instance, big, and 
will always be like that; similarly, cpu Y is LITTLE.

This makes me think that, for a virtual machine, it is ok to choose/specify at 
_domain_creation_ time, which vcpus are big and which vcpus are LITTLE, is this 
correct?
If yes, this also means that --whatever way we find to make this happen, 
cpupools, scheduler, etc-- the vcpus that we decided they are big, must only be 
scheduled on actual big pcpus, and pcpus that we decided they are LITTLE, must 
only be scheduled on actual LITTLE pcpus, correct again?

> Then for implementation.
>  - When create a guest, specific physical cpus that the guest will be
> run on.
>
I'd actually do that the other way round. I'd ask the user to specify
how many --and, if that's important-- vcpus are big and how many/which
are LITTLE.

Knowing that, we also know whether the domain is a big only, LITTLE
only or big.LITTLE one. And we also know on which set of pcpus each set
of vcpus should be restrict to.

So, basically (but it's just an example) something like this, in the xl
config file of a guest:

1) big.LITTLE guest, with 2 big and 2 LITTLE pcpus. User doesn't care  
   which is which, so a default could be 0,1 big and 2,3 LITTLE:

 vcpus = 4
 vcpus.big = 2

2) big.LITTLE guest, with 8 vcpus, of which 0,2,4 and 6 are big:

vcpus = 8
vcpus.big = [0, 2, 4, 6]

Which would be the same as

vcpus = 8
vcpus.little = [1, 3, 5, 7]

3) guest with 4 vcpus, all big:

vcpus = 4
vcpus.big = "all"

Which would be the same as:

vcpus = 4
vcpus.little = "none"

And also the same as just:

vcpus = 4


Or something like this

>  - If the physical cpus are different cpus, indicate the guest would
> like to be a big.little guest.
>    And have big vcpus and little vcpus.
>
Not liking this as _the_ way of specifying the guest topology, wrt
big.LITTLE-ness (see alternative proposal right above. :-))

However, right now we support pinning/affinity already. We certainly
need to decide what to do if, e.g., no vcpus.big or vcpus.little are
present, but the vcpus have hard or soft affinity to some specific
pcpus.

So, right now, this, in the xl config file:

cpus = [2, 8, 12, 13, 15, 17]

means that we want to ping 1-to-1 vcpu 0 to pcpu 2, vcpu 1 to pcpu 8,
vcpu 2 to pcpu 12, vcpu 3 to pcpu 13, vcpu 4 to pcpu 15 and vcpu 5 to
pcpu 17. Now, if cores 2, 8 and 12 are big, and no vcpus.big or
vcpu.little is specified, I'd put forward the assumption that the user
wants vcpus 0, 1 and 2 to be big, and vcpus 3, 4, and 5 to be LITTLE.

If, instead, there are vcpus.big or vcpus.little specified, and there's
disagreement, I'd either error out or decide which overrun the other
(and print a WARNING about that happening).

Still right now, this:

cpus = "2-12"

means that all the vcpus of the domain have hard affinity (i.e., are
pinned) to pcpus 2-12. And in this case I'd conclude that the user
wants for all the vcpus to be big.

I'm less sure what to do if _only_ soft-affinity is specified (via
"cpus_soft="), or if hard-affinity contains both big and LITTLE pcpus,
like, e.g.:

cpus = "2-15"

>  - If no physical cpus specificed, then the guest may runs on big
> cpus or on little cpus. But not both.
>
Yes. if nothing (or something contradictory) is specified, we 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Tue, 20 Sep 2016, Dario Faggioli wrote:
> On Mon, 2016-09-19 at 14:03 -0700, Stefano Stabellini wrote:
> > On Mon, 19 Sep 2016, Dario Faggioli wrote:
> > > Setting thing up like this, even automatically, either in
> > hypervisor or
> > > toolstack, is basically already possible (with all the good and bad
> > > aspects of pinning, of course).
> > > 
> > > Then, sure (as I said when replying to George), we may want things
> > to
> > > be more flexible, and we also probably want to be on the safe side
> > --if 
> > > ever some components manages to undo our automatic pinning-- wrt
> > the
> > > scheduler not picking up work for the wrong architecture... But
> > still
> > > I'm a bit surprised this did not came up... Julien, Peng, is that
> > > because you think this is not doable for any reason I'm missing?
> > 
> > Let's suppose that Xen detects big.LITTLE and pins dom0 vcpus to big
> > automatically. How can the user know that she really needs to be
> > careful
> > in the way she pins the vcpus of new VMs? Xen would also need to pin
> > automatically vcpus of new VMs to either big or LITTLE cores, or xl
> > would have to do it.
> > 
> Actually doing things with what we currently have for pinning is only
> something I've brought up as an example, and (potentially) useful for
> proof-of-concept, or very early stage level support.
> 
> In the long run, when thinking to the scheduler based solution, I see
> things happening the other way round: you specify in xl config file
> (and with boot parameters, for dom0) how many big and how many LITTLE
> vcpus you want, and the scheduler will know that it can only schedule
> the big ones on big physical cores, and the LITTLE ones on LITTLE
> physical cores.
> 
> Note that we're saying 'pinning' (yeah, I know, I did it myself in the
> first place :-/), but that would not be an actual 1-to-1 pinning. For
> instance, if domain X has 4 big pcpus, say 0,1,2,3,4, and the host has
> 8 big pcpus, say 8-15, then dXv1, dXv2, dXv3 and dXv4 will only be run
> by the scheduler on pcpus 8-15. Any of them, and with migration and
> load balancing within the set possible. This is what I'm talking about.
> 
> And this would work even if/when there is only one cpupool, or in
> general for domains that are in a pool that has both big and LITTLE
> pcpus. Furthermore, big.LITTLE support and cpupools will be orthogonal,
> just like pinning and cpupools are orthogonal right now. I.e., once we
> will have what I described above, nothing prevents us from implementing
> per-vcpu cpupool membership, and either create the two (or more!) big
> and LITTLE pools, or from mixing things even more, for more complex and
> specific use cases. :-)

I think that everybody agrees that this is the best long term solution.


> Actually, with the cpupool solution, if you want a guest (or dom0) to
> actually have both big and LITTLE vcpus, you necessarily have to
> implement per-vcpu (rather than per-domain, as it is now) cpupool
> membership. I said myself it's not impossible, but certainly it's some
> work... with the scheduler solution you basically get that for free!
> 
> So, basically, if we use cpupools for the basics of big.LITTLE support,
> there's no way out of it (apart from going implementing scheduling
> support afterwords, but that looks backwards to me, especially when
> thinking at it with the code in mind).

The question is: what is the best short-term solution we can ask Peng to
implement that allows Xen to run on big.LITTLE systems today? Possibly
getting us closer to the long term solution, or at least not farther
from it?


> > The whole process would be more explicit and obvious if we used
> > cpupools. It would be easier for users to know what it is going on --
> > they just need to issue an `xl cpupool-list' command and they would
> > see
> > two clearly named pools (something like big-pool and LITTLE-pool). 
> >
> Well, I guess that, as part of big.LITTLE support, there will be a way
> to tell what pcpus are big and which are LITTLE anyway, probably both
> from `xl info' and from `xl cpupool-list -c' (and most likely in other
> ways too).

Sure, but it needs to be very clear. We cannot ask people to spot
architecture specific flags among the output of `xl info' to be able to
appropriately start a guest. Even what I suggested isn't great as `xl
cpupool-list' isn't a common command to run.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

flight 101013 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101013/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 100905

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100905
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100905
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100905
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100905

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 xen  317eb71bc3b0830338601fb14d1f49546a1c1e35
baseline version:
 xen  038aadd63752baf18b7cc9c7fbec0e5f3aa7c46a

Last test of basis   100905  2016-09-12 23:40:57 Z6 days
Testing same since   101013  2016-09-19 15:45:51 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 
  Marek Marczykowski-Górecki 
  Stefan Bader 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt  

Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

[Dario Faggioli]

On Sat, 2016-09-17 at 00:31 +, Wei Yang wrote:
> On Fri, Sep 16, 2016 at 06:07:08PM +0200, Dario Faggioli wrote:
> > But then again, if the system is not oversubscribed, I'd tend to
> > think
> > it to be tolerable, and I'd expect the biggest problem to be the
> > work-
> > stealing logic (considering the high number of pcpus), rather than
> > the
> > duration of the critical sections within vcpu_wake().
> > 
> Yes, we are trying to improve the stealing part too.
> 
Great.

> Sounds reasonable, vcpu_wake() is O(1) while "stealing" is O(N) in
> terms of
> #PCPUs.
> 
Exactly!

> > I also think current upstream is a bit better, especially because
> > it's
> > mostly me that made it look the way it does. :-D
> 
> Ah, not intended to flattering you.
> 
EhEh! Sure, I was joking myself. :-)

> > 
> > 
> > But I was actually describing how 4.1 works. In fact, in 4.1, if
> > pcpu 6
> > is idle (se the '//xxx xxx xxx' comments I'm adding to the code
> > excerpts:
> > 
> > if ( new->pri > cur->pri )  //is true, so we put pcpu 6 in mask
> > {
> > cpu_set(cpu, mask);
> > }
> > if ( cur->pri > CSCHED_PRI_IDLE )  //is false!!
> > {
> >    
> > }
> > if ( !cpus_empty(mask) ) //the mask contains pcpu 6 only
> > cpumask_raise_softirq(mask, SCHEDULE_SOFTIRQ);
> > 
> 
> Hmm... don't have the code at hand, while looks you are right. I
> misunderstood
> the code.

> So only one idler would be tickled even there would be several idlers
> in the
> system. I thought we would tickle several idlers, which may introduce
> some
> contention between them.
> 
You can ask Xen to tickle more than one idle, by means of that
parameter. But again, tickling idlers --either one or many-- would only
happen if there's actual need for it.

> BTW, any idea behind the cycle_cpu()? If this is about the locality,
> how about
> cycle within the node? and cycle within the node where v->processor
> is?
> 
Cycle is there as a form of load spreading, i.e., we don't want to risk
tickling always the same set of pcpus, or always the ones with the
lower cpu IDs.

You're right that taking locality into account could be a good thing in
big systems. No, that is not done, not in 4.1 nor in upstream, and it
may be something actually worth trying (although, again, it's probably
unrelated to your issue).

> > And again, I'd personally spend some more time --even by
> > temporarily
> > and hackishly instrumenting the code-- to understand better where
> > the
> > bottleneck is.
> > 
> 
> Hmm... usually we use xentrace and lock profile to identify the
> bottleneck,
> other method you would like to suggest? and instrumenting the code
> means to
> add some log in code?
> 
xentrace and lock profile is all I use too, and there's not much else,
without touching the code. And in fact, yes, with "instrumenting the
code" I means temporary changing the code to display the information
you need.

In this specific case, rather than adding printks here and there
(which, e.g., is what you usually do for debugging crashes or alike),
I'd see about modifying a little bit either xentrace or lock profiling
code (or both!) to make them provide the info you need.

Sorry, but I don't think I can be much more specific without going
looking at the code and actually trying to do that...

> > E.g., something that has proven effective for others (and for which
> > I've got an unfinished and never submitted patch to upstream), is
> > keeping track of what pcpus actually have at least 1 vcpu in their
> > runqueues (i.e., at least 1 vcpus that is runnable and not running)
> > and, inside balance_load(), only consider those when looking for
> > work
> > to steal.
> 
> Looks like we keep a cpumask with those who have 1 more vcpus and
> during
> stealing process, just scan those instead of the online cpumask.
> 
Yep, that sounds like a plan, and was along the lines of what I was
doing. If you want to give it a try, patches (for upstream, of course
:-D) are welcome. :-P

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen Code Review Dashboard

[Jesus M. Gonzalez-Barahona]

Ooops. Sorry for the delay in answering. Yes, this is going to be
offered in the context of Outreachy once again. If you are still
interested, we can schedule an IRC meeting to start guiding you to your
first contribution.

Saludos,

Jesus.

On Tue, 2016-09-06 at 20:57 +0530, Anubha Aggarwal wrote:
> Yes in the context of outreachy.
> On 6 Sep 2016 20:43, "Jesus M. Gonzalez-Barahona" 
> wrote:
> > Hi, Anubha,
> > 
> > Are you commenting about this in the context of Outreacy or
> > anything
> > else?
> > 
> >         Jesus.
> > 
> > On Tue, 2016-09-06 at 19:11 +0530, Anubha Aggarwal wrote:
> > > Hello i am Anubha . I am interested to do work in this project .
> > I am
> > > good at Java, Xml and Sql.
> > > So can you guide me how i can make my first contribution to it.
> > > Tnks
> > >
> > >
> > --
> > Bitergia: http://bitergia.com
> > /me at Twitter: https://twitter.com/jgbarah
> > 
> > 
-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Dario Faggioli]

On Sun, 2016-09-18 at 08:37 +, Wu, Feng wrote:
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > So why this is all of the sudden becoming one? Am I completely off
> > with
> > my recollection (or in general :-P)? Or what am I missing about the
> > issue we are trying to address with this new bits of the work?
> 
> The issue discussed between Jan and me is that now we have four
> PI hooks: vmx_pi_switch_from, vmx_pi_switch_to, vmx_vcpu_block,
> and vmx_pi_do_resume. The previous assumption in vmx_vcpu_block()
> is that when we are running this function, the NDST field should have
> the same meaning with the current pCPU the vCPU is running on.
>
I'm sorry, but I'm still not getting it. Feel free to drop me, if I'm
doing more harm than good, but really, I can't parse this sentence into
something that makes me better understand the problem at hand.

"The previous assumption": "previous" with respect to what?

"the field should have the same meaning with the current pCPU the vCPU
is running on", what's this meaning you're mentioning, and how would it
be the same?

> However, I found this is not true in some scenarios, such as,
> vmx_pi_switch_to() hasn't been installed or executed before
> vmx_vcpu_block() gets called, in which case, we may hit the ASSERT
> in it. In previous version, I suggested we remove the ASSERT in
> vmx_vcpu_block() and set NDST explicitly in it. But seems maintainer
> doesn't like this idea. 
>
And this is not helping either. An ASSERT() being hit means something
wrong happened. Whether or not to remove (or change) an ASSERT() is not
a matter of "like".

If we hit the ASSERT() but nothing is wrong with the code, then it is
the ASSERT() itself that is wrong (buggy), and we must remove it, like
it or not.

OTOH, if we hit a non buggy ASSERT(), then it means that the ASSERT()
has done its job in finding something wrong in the code, and we should
leave it alone and fix the problem.

How's possible for the solution here to be "either remove the ASSERT()
_OR_ change the code"? That really makes few sense to me... :-O

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Mon, 2016-09-19 at 14:03 -0700, Stefano Stabellini wrote:
> On Mon, 19 Sep 2016, Dario Faggioli wrote:
> > Setting thing up like this, even automatically, either in
> hypervisor or
> > toolstack, is basically already possible (with all the good and bad
> > aspects of pinning, of course).
> > 
> > Then, sure (as I said when replying to George), we may want things
> to
> > be more flexible, and we also probably want to be on the safe side
> --if 
> > ever some components manages to undo our automatic pinning-- wrt
> the
> > scheduler not picking up work for the wrong architecture... But
> still
> > I'm a bit surprised this did not came up... Julien, Peng, is that
> > because you think this is not doable for any reason I'm missing?
> 
> Let's suppose that Xen detects big.LITTLE and pins dom0 vcpus to big
> automatically. How can the user know that she really needs to be
> careful
> in the way she pins the vcpus of new VMs? Xen would also need to pin
> automatically vcpus of new VMs to either big or LITTLE cores, or xl
> would have to do it.
> 
Actually doing things with what we currently have for pinning is only
something I've brought up as an example, and (potentially) useful for
proof-of-concept, or very early stage level support.

In the long run, when thinking to the scheduler based solution, I see
things happening the other way round: you specify in xl config file
(and with boot parameters, for dom0) how many big and how many LITTLE
vcpus you want, and the scheduler will know that it can only schedule
the big ones on big physical cores, and the LITTLE ones on LITTLE
physical cores.

Note that we're saying 'pinning' (yeah, I know, I did it myself in the
first place :-/), but that would not be an actual 1-to-1 pinning. For
instance, if domain X has 4 big pcpus, say 0,1,2,3,4, and the host has
8 big pcpus, say 8-15, then dXv1, dXv2, dXv3 and dXv4 will only be run
by the scheduler on pcpus 8-15. Any of them, and with migration and
load balancing within the set possible. This is what I'm talking about.

And this would work even if/when there is only one cpupool, or in
general for domains that are in a pool that has both big and LITTLE
pcpus. Furthermore, big.LITTLE support and cpupools will be orthogonal,
just like pinning and cpupools are orthogonal right now. I.e., once we
will have what I described above, nothing prevents us from implementing
per-vcpu cpupool membership, and either create the two (or more!) big
and LITTLE pools, or from mixing things even more, for more complex and
specific use cases. :-)

Actually, with the cpupool solution, if you want a guest (or dom0) to
actually have both big and LITTLE vcpus, you necessarily have to
implement per-vcpu (rather than per-domain, as it is now) cpupool
membership. I said myself it's not impossible, but certainly it's some
work... with the scheduler solution you basically get that for free!

So, basically, if we use cpupools for the basics of big.LITTLE support,
there's no way out of it (apart from going implementing scheduling
support afterwords, but that looks backwards to me, especially when
thinking at it with the code in mind).

> The whole process would be more explicit and obvious if we used
> cpupools. It would be easier for users to know what it is going on --
> they just need to issue an `xl cpupool-list' command and they would
> see
> two clearly named pools (something like big-pool and LITTLE-pool). 
>
Well, I guess that, as part of big.LITTLE support, there will be a way
to tell what pcpus are big and which are LITTLE anyway, probably both
from `xl info' and from `xl cpupool-list -c' (and most likely in other
ways too).

> We
> wouldn't have to pin vcpus to cpus automatically in Xen or xl, which
> doesn't sound like fun.
>
As tried to say above, it will _look_ like some kind of automatic
pinning, but that does not mean it has to be implemented by means of
it, or dealt with by the user in the same way.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline baseline-only test] 67730: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67730 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67730/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   3 host-install(3) broken REGR. vs. 67725
 build-amd64-xsm   3 host-install(3) broken REGR. vs. 67725
 build-amd64   3 host-install(3) broken REGR. vs. 67725
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 67725
 build-i3863 host-install(3) broken REGR. vs. 67725
 build-i386-pvops  3 host-install(3) broken REGR. vs. 67725
 build-i386-xsm3 host-install(3) broken REGR. vs. 67725
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 67725
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 67725

Tests which did not succeed, but are not blocking:
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Mon, 19 Sep 2016, Dario Faggioli wrote:
> On Mon, 2016-09-19 at 12:23 +0200, Juergen Gross wrote:
> > On 19/09/16 12:06, Julien Grall wrote:
> > > On 19/09/2016 11:45, George Dunlap wrote:
> > > > But expanding the schedulers to know about different classes of
> > > > cpus,
> > > > and having vcpus specified as running only on specific types of
> > > > pcpus,
> > > > seems like a more flexible approach.
> > > 
> > > So, if I understand correctly, you would not recommend to extend
> > > the
> > > number of CPU pool per domain, correct?
> > 
> > Before deciding in which direction to go (multiple cpupools, sub-
> > pools,
> > kind of implicit cpu pinning) 
> >
> You mention "implicit pinning" here, and I'd like to stress this,
> because basically no one (else) in the conversation seem to have
> considered it. In fact, it may not necessarily be the best long term
> solution, but doing something based on pinning is, IMO, a very
> convenient first step (and may well become one of the 'modes' available
> to the user for taking advantage of big.LITTLE.
> 
> So, if cpus 0-3 are big and cpus 4,5 are LITTLE, we can:
>  - for domain X, which wants to run only on big cores, pin all it's
>    vcpus to pcpus 0-3
>  - for domain Y, which wants to run only on LITTLE cores, pin all it's
>    vcpus to pcpus 4,5
>  - for domain Z, which wants its vcpus 0,1 to run on big cores, and
>    it's vcpus 2,3 to run on LITTLE cores, pin vcpus 0,1 to pcpus 0-3, 
>    and pin vcpus 2,3 to pcpus 4,5
> 
> Setting thing up like this, even automatically, either in hypervisor or
> toolstack, is basically already possible (with all the good and bad
> aspects of pinning, of course).
> 
> Then, sure (as I said when replying to George), we may want things to
> be more flexible, and we also probably want to be on the safe side --if 
> ever some components manages to undo our automatic pinning-- wrt the
> scheduler not picking up work for the wrong architecture... But still
> I'm a bit surprised this did not came up... Julien, Peng, is that
> because you think this is not doable for any reason I'm missing?

Let's suppose that Xen detects big.LITTLE and pins dom0 vcpus to big
automatically. How can the user know that she really needs to be careful
in the way she pins the vcpus of new VMs? Xen would also need to pin
automatically vcpus of new VMs to either big or LITTLE cores, or xl
would have to do it.

The whole process would be more explicit and obvious if we used
cpupools. It would be easier for users to know what it is going on --
they just need to issue an `xl cpupool-list' command and they would see
two clearly named pools (something like big-pool and LITTLE-pool). We
wouldn't have to pin vcpus to cpus automatically in Xen or xl, which
doesn't sound like fun.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Mon, 19 Sep 2016, Peng Fan wrote:
> On Mon, Sep 19, 2016 at 11:59:05AM +0200, Julien Grall wrote:
> >
> >
> >On 19/09/2016 11:38, Peng Fan wrote:
> >>On Mon, Sep 19, 2016 at 10:53:56AM +0200, Julien Grall wrote:
> >>>Hello,
> >>>
> >>>On 19/09/2016 10:36, Peng Fan wrote:
> On Mon, Sep 19, 2016 at 10:09:06AM +0200, Julien Grall wrote:
> >Hello Peng,
> >
> >On 19/09/2016 04:08, van.free...@gmail.com wrote:
> >>From: Peng Fan 
> >>
> >>This patchset is to support XEN run on big.little SoC.
> >>The idea of the patch is from
> >>"https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00465.html;
> >>
> >>There are some changes to cpupool and add x86 stub functions to avoid 
> >>build
> >>break. Sending The RFC patchset out is to request for comments to see 
> >>whether
> >>this implementation is acceptable or not. Patchset have been tested 
> >>based on
> >>xen-4.8 unstable on NXP i.MX8.
> >>
> >>I use Big/Little CPU and cpupool to explain the idea.
> >>A pool contains Big CPUs is called Big Pool.
> >>A pool contains Little CPUs is called Little Pool.
> >>If a pool does not contains any physical cpus, Little CPUs or Big CPUs
> >>can be added to the cpupool. But the cpupool can not contain both Little
> >>and Big CPUs. The CPUs in a cpupool must have the same cpu type(midr 
> >>value for ARM).
> >>CPUs can not be added to the cpupool which contains cpus that have 
> >>different cpu type.
> >>Little CPUs can not be moved to Big Pool if there are Big CPUs in Big 
> >>Pool,
> >>and versa. Domain in Big Pool can not be migrated to Little Pool, and 
> >>versa.
> >>When XEN tries to bringup all the CPUs, only add CPUs with the same cpu 
> >>type(same midr value)
> >>into cpupool0.
> >
> >As mentioned in the mail you pointed above, this series is not enough to 
> >make
> >big.LITTLE working on then. Xen is always using the boot CPU to detect 
> >the
> >list of features. With big.LITTLE features may not be the same.
> >
> >And I would prefer to see Xen supporting big.LITTLE correctly before
> >beginning to think to expose big.LITTLE to the userspace (via cpupool)
> >automatically.
> 
> Do you mean vcpus be scheduled between big and little cpus freely?
> >>>
> >>>By supporting big.LITTLE correctly I meant Xen thinks that all the cores 
> >>>has
> >>>the same set of features. So the feature detection is only done the boot 
> >>>CPU.
> >>>See processor_setup for instance...
> >>>
> >>>Moving vCPUs between big and little cores would be a hard task (cache line
> >>>issue, and possibly feature) and I don't expect to ever cross this in Xen.
> >>>However, I am expecting to see big.LITTLE exposed to the guest (i.e having
> >>>big and little vCPUs).
> >>
> >>big vCPUs scheduled on big Physical CPUs and little vCPUs scheduled on 
> >>little
> >>physical cpus, right?
> >>If it is, is there is a need to let Xen think all the cores has the same set
> >>of features?
> >
> >I think you missed my point. The feature registers on big and little cores
> >may be different. Currently, Xen is reading the feature registers of the CPU
> >boot and wrongly assumes that those features will exists on all CPUs. This is
> >not the case and should be fixed before we are getting in trouble.
> >
> >>
> >>Developing big.little guest support, I am not sure how much efforts needed.
> >>Is this really needed?
> >
> >This is not necessary at the moment, although I have seen some interest about
> >it. Running a guest only on a little core is a nice beginning, but a guest
> >may want to take advantage of big.LITTLE (running hungry app on big one and
> >little on small one).
> >
> >>
> >>>
> 
> This patchset is to use cpupool to block the vcpu be scheduled between 
> big and
> little cpus.
> 
> >
> >See for instance v->arch.actlr = READ_SYSREG32(ACTLR_EL1).
> 
> Thanks for this. I only expose cpuid to guest, missed actlr. I'll check
> the A53 and A72 TRM about AArch64 implementationd defined registers.
> This actlr can be added to the cpupool_arch_info as midr.
> 
> Reading "vcpu_initialise", seems only MIDR and ACTLR needs to be handled.
> Please advise if I missed anything else.
> >>>
> >>>Have you check the register emulation?
> >>
> >>Checked midr. Have not checked others.
> >>I think I missed some registers in ctxt_switch_to.
> >>
> >>>
> 
> >
> >>
> >>Thinking an SoC with 4 A53(cpu[0-3]) + 2 A72(cpu[4-5]), cpu0 is the 
> >>first one
> >>that boots up. When XEN tries to bringup secondary CPUs, add cpu[0-3] to
> >>cpupool0 and leave cpu[4-5] not in any cpupool. Then when Dom0 boots up,
> >>`xl cpupool-list -c` will show cpu[0-3] in Pool-0.
> >>
> >>Then use the following script to create a new cpupool and add cpu[4-5] 
> >>to
> >>the cpupool.
> 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Mon, 19 Sep 2016, Juergen Gross wrote:
> On 19/09/16 12:06, Julien Grall wrote:
> > Hi George,
> > 
> > On 19/09/2016 11:45, George Dunlap wrote:
> >> On Mon, Sep 19, 2016 at 9:53 AM, Julien Grall 
> >> wrote:
> > As mentioned in the mail you pointed above, this series is not
> > enough to
> > make
> > big.LITTLE working on then. Xen is always using the boot CPU to detect
> > the
> > list of features. With big.LITTLE features may not be the same.
> >
> > And I would prefer to see Xen supporting big.LITTLE correctly before
> > beginning to think to expose big.LITTLE to the userspace (via cpupool)
> > automatically.
> 
> 
>  Do you mean vcpus be scheduled between big and little cpus freely?
> >>>
> >>>
> >>> By supporting big.LITTLE correctly I meant Xen thinks that all the
> >>> cores has
> >>> the same set of features. So the feature detection is only done the boot
> >>> CPU. See processor_setup for instance...
> >>>
> >>> Moving vCPUs between big and little cores would be a hard task (cache
> >>> line
> >>> issue, and possibly feature) and I don't expect to ever cross this in
> >>> Xen.
> >>> However, I am expecting to see big.LITTLE exposed to the guest (i.e
> >>> having
> >>> big and little vCPUs).
> >>
> >> So it sounds like the big and LITTLE cores are architecturally
> >> different enough that software must be aware of which one it's running
> >> on?
> > 
> > That's correct. Each big and LITTLE cores may have different errata,
> > different features...
> > 
> > It has also the advantage to let the guest dealing itself with its own
> > power efficiency without introducing a specific Xen interface.
> > 
> >>
> >> Exposing varying numbers of big and LITTLE vcpus to guests seems like
> >> a sensible approach.  But at the moment cpupools only allow a domain
> >> to be in exactly one pool -- meaning if we use cpupools to control the
> >> big.LITTLE placement, you won't be *able* to have guests with both big
> >> and LITTLE vcpus.
> >>
>  If need to create all the pools, need to decided how many pools need
>  to be
>  created.
>  I thought about this, but I do not come out a good idea.
> 
>  The cpupool0 is defined in xen/common/cpupool.c, if need to create many
>  pools,
>  need to alloc cpupools dynamically when booting. I would not like to
>  change a
>  lot to common code.
> >>>
> >>>
> >>> Why? We should avoid to choose a specific design just because the common
> >>> code does not allow you to do it without heavy change.
> >>>
> >>> We never came across the big.LITTLE problem on x86, so it is normal to
> >>> modify the code.
> >>
> >> Julien is correct; there's no reason we couldn't have a default
> >> multiple pools on boot.
> >>
>  The implementation in this patchset I think is an easy way to let
>  Big and
>  Little
>  CPUs all run.
> >>>
> >>>
> >>> I care about having a design allowing an easy use of big.LITTLE on
> >>> Xen. Your
> >>> solution requires the administrator to know the underlying platform and
> >>> create the pool.
> >>>
> >>> In the solution I suggested, the pools would be created by Xen (and
> >>> the info
> >>> exposed to the userspace for the admin).
> >>
> >> FWIW another approach could be the one taken by "xl
> >> cpupool-numa-split": you could have "xl cpupool-bigLITTLE-split" or
> >> something that would automatically set up the pools.
> >>
> >> But expanding the schedulers to know about different classes of cpus,
> >> and having vcpus specified as running only on specific types of pcpus,
> >> seems like a more flexible approach.
> > 
> > So, if I understand correctly, you would not recommend to extend the
> > number of CPU pool per domain, correct?
> 
> Before deciding in which direction to go (multiple cpupools, sub-pools,
> kind of implicit cpu pinning) I think we should think about the
> implications regarding today's interfaces:
> 
> - Do we want to be able to use different schedulers for big/little
>   (this would mean some cpupool related solution)? I'd prefer to
>   have only one scheduler type for each domain. :-)
> 
> - What about scheduling parameters like weight and cap? How would
>   those apply (answer probably influencing pinning solution).
>   Remember that especially the downsides of pinning led to the
>   introduction of cpupools.

It isn't easy to answer these questions, but there might be a reason to
have different schedulers because they are supposed to run different
classes of workloads. big cores are of cpu intensive tasks (think of V8,
the Javascript engine), while LITTLE cores are for low key background
applications (think of the whatsapp daemon that runs in the background
on your phone).


> - Is big.LITTLE to be expected to be combined with NUMA?

NUMA is not a popular way to design hardware in the ARM ecosystem today.
If it did become more widespread, I would expect it to happen on server
hardware, where big.LITTLE 

Re: [Xen-devel] [PATCH v6 3/6] livepatch: NOP if func->new_addr is zero.

[Konrad Rzeszutek Wilk]

> > > Ooh, good idea. But I think it maybe better as a seperate patch (as it
> > > also touches the ARM code).
> > 
> > That's in the other series, isn't it?
> 
> It expands the existing ones. Right now in 'staging' branch we have an
> arch/arm/livepatch.c which has these functions in it.
> 
> Granted nothing compiles them, so I could break it in this patch.
> 
> But I already cobbled up the patch so may as well use it?
> 

Tested version:

From 0b0ee8f270219f5c9092960ed8560d8e039332a9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 19 Sep 2016 12:20:27 -0400
Subject: [PATCH] livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp

With "livepatch: NOP if func->new_addr is zero." that name
makes no more sense.

Suggested-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
---
v7: New submission
---
 xen/arch/arm/livepatch.c| 4 ++--
 xen/arch/x86/livepatch.c| 4 ++--
 xen/common/livepatch.c  | 4 ++--
 xen/include/xen/livepatch.h | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 755f596..7f067a0 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -21,11 +21,11 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return -ENOSYS;
 }
 
-void arch_livepatch_apply_jmp(struct livepatch_func *func)
+void arch_livepatch_apply(struct livepatch_func *func)
 {
 }
 
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+void arch_livepatch_revert(const struct livepatch_func *func)
 {
 }
 
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 118770e..36bbc5f 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -47,7 +47,7 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return 0;
 }
 
-void arch_livepatch_apply_jmp(struct livepatch_func *func)
+void arch_livepatch_apply(struct livepatch_func *func)
 {
 uint8_t *old_ptr;
 uint8_t insn[sizeof(func->opaque)];
@@ -76,7 +76,7 @@ void arch_livepatch_apply_jmp(struct livepatch_func *func)
 memcpy(old_ptr, insn, len);
 }
 
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+void arch_livepatch_revert(const struct livepatch_func *func)
 {
 memcpy(func->old_addr, func->opaque, livepatch_insn_len(func));
 }
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index ed41f39..9d2e86d 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1033,7 +1033,7 @@ static int apply_payload(struct payload *data)
 }
 
 for ( i = 0; i < data->nfuncs; i++ )
-arch_livepatch_apply_jmp(>funcs[i]);
+arch_livepatch_apply(>funcs[i]);
 
 arch_livepatch_revive();
 
@@ -1062,7 +1062,7 @@ static int revert_payload(struct payload *data)
 }
 
 for ( i = 0; i < data->nfuncs; i++ )
-arch_livepatch_revert_jmp(>funcs[i]);
+arch_livepatch_revert(>funcs[i]);
 
 arch_livepatch_revive();
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 174af06..b7f66d4 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -86,8 +86,8 @@ unsigned int livepatch_insn_len(const struct livepatch_func 
*func)
 int arch_livepatch_quiesce(void);
 void arch_livepatch_revive(void);
 
-void arch_livepatch_apply_jmp(struct livepatch_func *func);
-void arch_livepatch_revert_jmp(const struct livepatch_func *func);
+void arch_livepatch_apply(struct livepatch_func *func);
+void arch_livepatch_revert(const struct livepatch_func *func);
 void arch_livepatch_post_action(void);
 
 void arch_livepatch_mask(void);
-- 
2.4.11


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 12/16] bug/x86/arm: Align bug_frames sections.

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 04:19:55PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > Signed-off-by: Konrad Rzeszutek Wilk 
> > 
> > I forgot to mention that with those NITs fixed:
> > 
> > Reviewed-by: Julien Grall 
> 
> Thanks.
> 
> However I noticed (and I recall having it replaced in earlier
> versions so I must have in a hurry missed it), but this:
> 
> > > > --- a/xen/include/asm-arm/bug.h
> > > > +++ b/xen/include/asm-arm/bug.h
> > > > @@ -52,6 +52,7 @@ struct bug_frame {
> > > > 
> > > > ".popsection\n"\
> > > >   ".pushsection .bug_frames." __stringify(type) ", \"a\",
> > > > %progbits\n"\
> > > > 
> > > > "4:\n" \
> > > > + ".align 4\n"  
> > > >  \
> 
> [fixed up, your mailer mangled it]
> This should have been:
> 
> diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
> index 773d63e..affe64f 100644
> --- a/xen/include/asm-arm/bug.h
> +++ b/xen/include/asm-arm/bug.h
> @@ -52,7 +52,7 @@ struct bug_frame {
>   ".popsection\n"\
>   ".pushsection .bug_frames." __stringify(type) ", \"a\", 
> %progbits\n"\
>   "4:\n" \
> - ".align 4\n"   \
> + ".p2align 4\n" \

Argh. '.p2align 2' !

For reference, here is the full patch:

From ecf25f594118042364367d0bfacb3ee25046 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Wed, 7 Sep 2016 11:57:05 -0400
Subject: [PATCH] bug/x86/arm: Align bug_frames sections.

Most of the WARN_ON or BUG_ON sections are properly aligned on
x86. However on ARM and on x86 assembler the macros don't include
any alignment information - hence they end up being the default
byte granularity.

On ARM32 it is paramount that the alignment is word-size (4)
otherwise if one tries to use (uint32_t*) access (such
as livepatch ELF relocations) we get a Data Abort.

Enforcing bug_frames to have the proper alignment across all
architectures and in both C and x86 makes them all the same.

Furthermore on x86 the bloat-o-meter detects that with this
change:

add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
function old new   delta

On ARM32:
add/remove: 1/0 grow/shrink: 0/1 up/down: 384/-288 (96)
function old new   delta
gnttab_unpopulate_status_frames- 384+384
do_grant_table_op  10808   10520-288

And ARM64:
add/remove: 1/2 grow/shrink: 0/1 up/down: 4164/-4236 (-72)
function old new   delta
gnttab_map_grant_ref   -4164   +4164
do_grant_table_op   98929836 -56
grant_map_exists 300   --300
__gnttab_map_grant_ref  3880   -   -3880

Reviewed-by: Julien Grall 
Acked-by: Jan Beulich  [x86 parts]
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: First submission. Replaces the "livepatch/elf: Adjust section aligment to 
word"
patch.
v4: Remove the .ALIGN(4) in xen.lds.S for x86 (the only place needing
that change).
Update the commit description with correct x86 results
Remove the . = ALIGN(4); in linker filer on x86 [the only file needing the 
change]
v5: Add Jan's Ack on x86 parts.
v6: Added Julien's Reviewed-by
s/aligment/alignment/
s/align 4/p2align 2/ as the align semnatics varies by platforms, while
p2align is the same across all of them.
---
 xen/arch/x86/xen.lds.S| 1 -
 xen/include/asm-arm/bug.h | 1 +
 xen/include/asm-x86/bug.h | 1 +
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d903c31..7676de9 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -79,7 +79,6 @@ SECTIONS
   .rodata : {
_srodata = .;
/* Bug frames table */
-   . = ALIGN(4);
__start_bug_frames = .;
*(.bug_frames.0)
__stop_bug_frames_0 = .;
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
index 68353e1..4704e2d 100644
--- a/xen/include/asm-arm/bug.h
+++ b/xen/include/asm-arm/bug.h
@@ -52,6 +52,7 @@ struct bug_frame {
  ".popsection\n"\
  ".pushsection .bug_frames." __stringify(type) ", \"a\", %progbits\n"\
  "4:\n"  

Re: [Xen-devel] [PATCH v4 12/16] bug/x86/arm: Align bug_frames sections.

[Konrad Rzeszutek Wilk]

> > > Signed-off-by: Konrad Rzeszutek Wilk 
> 
> I forgot to mention that with those NITs fixed:
> 
> Reviewed-by: Julien Grall 

Thanks.

However I noticed (and I recall having it replaced in earlier
versions so I must have in a hurry missed it), but this:

> > > --- a/xen/include/asm-arm/bug.h
> > > +++ b/xen/include/asm-arm/bug.h
> > > @@ -52,6 +52,7 @@ struct bug_frame {
> > > 
> > > ".popsection\n"\
> > >   ".pushsection .bug_frames." __stringify(type) ", \"a\",
> > > %progbits\n"\
> > > 
> > > "4:\n" \
> > > + ".align 4\n"
> > >\

[fixed up, your mailer mangled it]
This should have been:

diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
index 773d63e..affe64f 100644
--- a/xen/include/asm-arm/bug.h
+++ b/xen/include/asm-arm/bug.h
@@ -52,7 +52,7 @@ struct bug_frame {
  ".popsection\n"\
  ".pushsection .bug_frames." __stringify(type) ", \"a\", %progbits\n"\
  "4:\n" \
- ".align 4\n"   \
+ ".p2align 4\n" \
  ".long (1b - 4b)\n"\
  ".long (2b - 4b)\n"\
  ".long (3b - 4b)\n"\


So that it would be in sync with x86 version.

The end result is exactly the same - it is just that p2align is
preferred because it has the same semantics across platforms while
.align differs.

I made the change (along with your recommendations) and put your
Reviewed-by. I hope that is OK.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 101012: regressions - FAIL

[osstest service owner]

flight 101012 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101012/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 101008

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100998
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101008
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101008
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101008
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101008
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101008

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  6bd621d7010bb8561196aedf5198d5fe7c146822
baseline version:
 xen  6559a686ae77bca2539d826120c9f3bd0d75cdf8

Last test of basis   101008  2016-09-19 01:58:31 Z0 days
Testing same since   101012  2016-09-19 12:15:44 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Kevin Tian 
  Razvan Cojocaru 
  Tamas K Lengyel 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  

Re: [Xen-devel] stack size limit issues with xen + qemu + rbd

[Konrad Rzeszutek Wilk]

On Fri, Sep 16, 2016 at 04:55:17PM -0400, Chris Patterson wrote:
> I have spent some time investigating a case where qemu is failing to
> register xenstore watches for a PV guest once I enable vfb (and
> thereby triggering the creation of a qemu instance).
> 
> The qemu logs show something along the lines of:
> xen be core: xen be core: xen be: watching backend path
> (backend/console/3) failed
> xen be: watching backend path (backend/console/3) failed
> xen be core: xen be core: xen be: watching backend path (backend/vkbd/3) 
> failed
> xen be: watching backend path (backend/vkbd/3) failed
> xen be core: xen be core: xen be: watching backend path (backend/qdisk/3) 
> failed
> xen be: watching backend path (backend/qdisk/3) failed
> xen be core: xen be core: xen be: watching backend path (backend/qusb/3) 
> failed
> xen be: watching backend path (backend/qusb/3) failed
> xen be core: xen be core: xen be: watching backend path (backend/vfb/3) failed
> xen be: watching backend path (backend/vfb/3) failed
> xen be core: xen be core: xen be: watching backend path (backend/qnic/3) 
> failed
> xen be: watching backend path (backend/qnic/3) failed
> 
> I have tested qemu master, qemu-xen in the master xen tree, as well as
> a few tags all with the same issue.
> 
> I came across a similar issue reported by Juergen Gross:
> https://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg03341.html
> 
> Sure enough, the thread stack size was the culprit.  I had been
> testing with qemu with the associated fix "vnc-tight: fix regression
> with libxenstore" as it is in master, so that wasn't it...
> 
> I did some basic analysis of the qemu binary and the libraries it is pulling 
> in:
> 
> for lib in $(ldd /usr/local/bin/qemu-system-i386 | grep -o '/.* '); do
> echo "lib=$lib"; readelf -S "$lib" | grep -e tbss -e tdata -A1 ; done
> 
> The largest consumers were:
> lib=/usr/lib/x86_64-linux-gnu/librbd.so.1
>   [17] .tbss NOBITS   0088fed0  0068fed0
>1820   WAT   0 0 8
> lib=/usr/lib/x86_64-linux-gnu/librados.so.2
>   [17] .tbss NOBITS   00718600  00518600
>0aa0   WAT   0 0 8
> 
> IIUC, librbd & librados are using nearly 9k of the 16k alone (I am
> assuming this thread-local storage must be consumed as part of the
> thread's stack)?
> 
> I narrowed that down to Ceph's usage of __thread in stringify() in
> src/include/stringify.h.
> 
> To make things functional, the options were either to:
> (a) disable rbd at configure time for qemu
> (b) reduce the level of thread-local storage in dependencies
> (particularly ceph's stringify)
> (c) increase the stack size specified in xenstore's xs.c


I would say c) for now and focus on b) long-term until c) can be
reverted?

> 
> Is there is any precedent/policy with regards to expected TLS and/or
> stack usage for dependencies?  Is the best course of action (b)? Or

No precendent/policy that I know of..

> perhaps reconsider the default size for (c)?
> 
> Thoughts? :)
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

flight 101018 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101018/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f1446de4ba5218a58fa2486ebe090495e0fb05c4
baseline version:
 xen  b09499d3b98b317192465820668429301f6a3741

Last test of basis   101014  2016-09-19 16:01:22 Z0 days
Testing same since   101018  2016-09-19 18:02:42 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Paulina Szubarczyk 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=f1446de4ba5218a58fa2486ebe090495e0fb05c4
+ . ./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 
f1446de4ba5218a58fa2486ebe090495e0fb05c4
+ branch=xen-unstable-smoke
+ revision=f1446de4ba5218a58fa2486ebe090495e0fb05c4
+ . ./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.7-testing
+ '[' xf1446de4ba5218a58fa2486ebe090495e0fb05c4 = 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
++ : 

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
 On 15.09.16 at 18:51,  wrote:
>> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
>> *hvmemul_ctxt,
>>  pfec |= PFEC_user_mode;
>>
>>  hvmemul_ctxt->insn_buf_eip = regs->eip;
>> -if ( !vio->mmio_insn_bytes )
>> +
>> +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>> +{
>> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
>> + sizeof(curr->arch.vm_event->emul.insn));
>
> This should quite clearly be !=, and I think it builds only because you
> use the wrong operand in the first sizeof().
>
>> +hvmemul_ctxt->insn_buf_bytes = 
>> sizeof(curr->arch.vm_event->emul.insn);
>> +memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul.insn,
>> +   hvmemul_ctxt->insn_buf_bytes);
>
> This memcpy()s between dissimilar types. Please omit the & and
> properly add .data on the second argument (and this .data
> addition should then also be mirrored in the BUILD_BUG_ON()).
>
>> +}
>> +else if ( !vio->mmio_insn_bytes )
>
> And then - I'm sorry for not having thought of this before - I think
> this would better not live here, or have an effect more explicitly
> only when coming here through hvm_emulate_one_vm_event().
> Since the former seems impractical, I think giving _hvm_emulate_one()
> one or two extra parameters would be the most straightforward
> approach.

So this is the spot where the mmio insn buffer is getting copied as
well instead of fetching the instructions from the guest memory. So
having the vm_event buffer getting copied here too makes the most
sense. Having the vm_event insn buffer getting copied in somewhere
else, while the mmio insn buffer getting copied here, IMHO just
fragments the flow even more making it harder to see what is actually
happening. How about adjusting the if-else here to be:

if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn  )
...
else if ( vio->mmio_insn_bytes )
...
else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )

?

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] Fix issues introduced in 3a7f872a

[Wei Liu]

3a7f872a ("tools: lift BUILD_BUG_ON to a tools header file") was taken
out from an rather old half finished branch by dropping unrelated
changes.  Unfortunately two issues sneaked in.

1. Hvmloader should be standalone. Revert the changes to hvmloader.
2. The define guard in libs.h was erroneously deleted. Add that back.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/firmware/hvmloader/rombios.c | 1 -
 tools/firmware/hvmloader/smbios.c  | 1 -
 tools/firmware/hvmloader/util.h| 1 +
 tools/include/xen-tools/libs.h | 1 +
 4 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/rombios.c 
b/tools/firmware/hvmloader/rombios.c
index 1e853ec..9acf03f 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -31,7 +31,6 @@
 #include "option_rom.h"
 
 #include 
-#include 
 
 #define ROM_INCLUDE_ROMBIOS
 #define ROM_INCLUDE_VGABIOS
diff --git a/tools/firmware/hvmloader/smbios.c 
b/tools/firmware/hvmloader/smbios.c
index 0e61bd1..210c7b0 100644
--- a/tools/firmware/hvmloader/smbios.c
+++ b/tools/firmware/hvmloader/smbios.c
@@ -26,7 +26,6 @@
 #include "util.h"
 #include "hypercall.h"
 #include 
-#include 
 
 /* SBMIOS handle base values */
 #define SMBIOS_HANDLE_TYPE0   0x
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 94292d6..0fb266e 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -41,6 +41,7 @@ void __assert_failed(char *assertion, char *file, int line)
 void __bug(char *file, int line) __attribute__((noreturn));
 #define BUG() __bug(__FILE__, __LINE__)
 #define BUG_ON(p) do { if (p) BUG(); } while (0)
+#define BUILD_BUG_ON(p) ((void)sizeof(char[1 - 2 * !!(p)]))
 
 #define min_t(type,x,y) \
 ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
diff --git a/tools/include/xen-tools/libs.h b/tools/include/xen-tools/libs.h
index 9d8b4ab..e874fb8 100644
--- a/tools/include/xen-tools/libs.h
+++ b/tools/include/xen-tools/libs.h
@@ -1,4 +1,5 @@
 #ifndef __XEN_TOOLS_LIBS__
+#define __XEN_TOOLS_LIBS__
 
 #ifndef BUILD_BUG_ON
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

flight 101014 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101014/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  b09499d3b98b317192465820668429301f6a3741
baseline version:
 xen  de4e4fd12bdca17cb3511e9bfc8f2c1e94c09a7d

Last test of basis   101011  2016-09-19 12:00:53 Z0 days
Testing same since   101014  2016-09-19 16:01:22 Z0 days1 attempts


People who touched revisions under test:
  Daniel Kiper 
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=b09499d3b98b317192465820668429301f6a3741
+ . ./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 
b09499d3b98b317192465820668429301f6a3741
+ branch=xen-unstable-smoke
+ revision=b09499d3b98b317192465820668429301f6a3741
+ . ./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.7-testing
+ '[' xb09499d3b98b317192465820668429301f6a3741 = 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

Re: [Xen-devel] [PATCH v4 2/5] x86/time: implement tsc as clocksource

[Joao Martins]

On 09/19/2016 05:25 PM, Jan Beulich wrote:
 On 19.09.16 at 18:11,  wrote:
>> On 09/19/2016 11:13 AM, Jan Beulich wrote:
>> On 14.09.16 at 19:37,  wrote:
 Since b64438c7c ("x86/time: use correct (local) time stamp in
 constant-TSC calibration fast path") updates to cpu time use local
 stamps, which means platform timer is only used to seed the initial
 cpu time.  With clocksource=tsc there is no need to be in sync with
 another clocksource, so we reseed the local/master stamps to be values
 of TSC and update the platform time stamps accordingly. Time
 calibration is set to 1sec after we switch to TSC, thus these stamps
 are reseeded to also ensure monotonic returning values right after the
 point we switch to TSC. This is also to avoid the possibility of
 having inconsistent readings in this short period (i.e. until
 calibration fires).
>>>
>>> And within this one second, which may cover some of Dom0's
>>> booting up, it is okay to have inconsistencies?
>> It's not okay which is why I am removing this possibility when switching to 
>> TSC.
>> The inconsistencies in those readings (if I wasn't adjusting) would be 
>> because
>> we would be using (in that 1-sec) those cpu time tuples calculated by the
>> previous calibration or platform time initialization (while still was HPET,
>> ACPI, etc as clocksource). Would you prefer me removing the "avoid" and 
>> instead
>> change it to "remove the possibility" in this last sentence?
> 
> Let's not do the 2nd step before the 1st, which is the question of
> what happens prior to and what actually changes at this first
> calibration (after 1 sec).
The first calibration won't change much - this 1-sec was meant when having
nop_rendezvous which is the first time platform timer would be used to set local
cpu_time (will adjust the mention above as it's misleading for the reader as it
doesn't refer to this patch). Though reseeding the cpu times to boot_tsc_stamp
prior to calibration (*without* the time latch values from previous platform
timer) we can ensure NOW/get_s_time or calls to update_vcpu_system_time() will
see monotonically increasing values. Otherwise keeping the previous ones,
calibration would just add up local TSC delta and any existing divergence
wouldn't be solved. On a later patch when we set the stable bit (with nop
rendezvous), if these cpu times weren't adjusted guests/xen would still see
small divergence between CPUs until the first calibration was fired (after we
switched to TSC). And then the values wouldn't be consistent with the guarantees
expected from this bit. But even not considering this bit (which is not the
subject of this patch), same guarantee is expected from get_s_time() calls
within Xen.


 @@ -1480,6 +1570,25 @@ static int __init verify_tsc_reliability(void)
  printk("TSC warp detected, disabling TSC_RELIABLE\n");
  setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);
  }
 +else if ( !strcmp(opt_clocksource, "tsc") &&
 +  (try_platform_timer(_tsc) > 0) )
 +{
 +/*
 + * Platform timer has changed and CPU time will only be 
 updated
 + * after we set again the calibration timer, which means we 
 need to
 + * seed again each local CPU time. At this stage TSC is known 
 to be
 + * reliable i.e. monotonically increasing across all CPUs so 
 this
 + * lets us remove the skew between platform timer and TSC, 
 since
 + * these are now effectively the same.
 + */
 +on_selected_cpus(_online_map, reset_percpu_time, NULL, 1);
 +
 +/* Finish platform timer switch. */
 +try_platform_timer_tail();
 +
 +printk(XENLOG_INFO "Switched to Platform timer %s TSC\n",
 +   freq_string(plt_src.frequency));
>>>
>>> This message should have the same log level as the one at the end
>>> of init_platform_timer().
>> Agreed, but at the end of init_platform_timer there is a plain printk with an
>> omitted log level. Or do you mean to remove XENLOG_INFO from this printk 
>> above
>> or, instead add XENLOG_INFO to one printk at the end of 
>> init_platform_timer() ?
> 
> Well, info would again be too low a level for my taste. Hence either
> remove the level here (slightly preferred from my pov), or make both
> warning.
As your preference goes towards without the log level, I will re-introduce back
without it. Although I would find clearer to use printk with a log level as it
was advised in earlier reviews.

NB: My suggestion of info as level is because my usual line of thought is to see
warning as something potentially erroneous that user should be warned about, and
error as being an actual error.

Joao

Re: [Xen-devel] [PATCH v4 07/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 08:48:10AM -0600, Jan Beulich wrote:
> >>> On 19.09.16 at 16:13,  wrote:
> 
> > 
> > On 19/09/2016 16:11, Jan Beulich wrote:
> > On 19.09.16 at 15:33,  wrote:
> >>> On 19/09/2016 11:27, Jan Beulich wrote:
> >>> On 16.09.16 at 18:38,  wrote:
> > --- a/xen/arch/arm/livepatch.c
> > +++ b/xen/arch/arm/livepatch.c
> > @@ -117,6 +117,20 @@ bool arch_livepatch_symbol_ok(const struct 
> > livepatch_elf
> >>> *elf,
> >  return true;
> >  }
> >
> > +bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
> > +const struct livepatch_elf_sym *sym)
> > +{
> > +#ifdef CONFIG_ARM_32
> > +/*
> > + * Xen does not use Thumb instructions - and we should not see any 
> > of
> > + * them. If we do, abort.
> > + */
> > +if ( sym->name && *sym->name == '$' && sym->name[1] == 't' )
> >>>
> >>> Please use sym->name[0] for readability. Also, you may want to check the
> >>> length of the symbol before checking the second character.
> >>
> >> Why would the length check be needed? If the first character is $,
> >> then looking at the second one is always valid (and it being nul will
> >> be properly dealt with by the expression above).
> > 
> > Because you may have a payload which is not valid? Or maybe you consider 
> > that all the payload are trusted.
> 
> If all symbols' names are inside their string tables and the string
> tables are both contained inside the image and have a zero byte
> at their end (all of which gets verified afair), nothing bad can
> happen I think.

Exactly. All of those checks are done so we are sure that the
sym->name[0] points to something.


Julien, I can use strlen if you prefer, so it would be like so:
   
bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
const struct livepatch_elf_sym *sym)
{
#ifdef CONFIG_ARM_32
/*
 * Xen does not use Thumb instructions - and we should not see any of
 * them. If we do, abort.
 */
if ( sym-name && sym->name[0] == '$' && sym->name[1] == 't' )
{
size_t len = strlen(sym->name);

if ( (len >= 3 && (sym->name[2] == '.')) || len == 2 )
return true;
}
#endif
return false;
}

Or this way:

bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
const struct livepatch_elf_sym *sym)
{   
#ifdef CONFIG_ARM_32
/*  
 * Xen does not use Thumb instructions - and we should not see any
 * of  
 * them. If we do, abort.   
 */ 
if ( sym->name && sym->name[0] == '$' && sym->name[1] == 't' )  
 
{   
if ( sym->name[2] && sym->name[2] != '.' )  
return false;   

return true;
}   
#endif  
return false;   
}   


Both add exactly the same amount of lines of code :-)

> 
> Jan
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Mon, 2016-09-19 at 12:23 +0200, Juergen Gross wrote:
> On 19/09/16 12:06, Julien Grall wrote:
> > On 19/09/2016 11:45, George Dunlap wrote:
> > > But expanding the schedulers to know about different classes of
> > > cpus,
> > > and having vcpus specified as running only on specific types of
> > > pcpus,
> > > seems like a more flexible approach.
> > 
> > So, if I understand correctly, you would not recommend to extend
> > the
> > number of CPU pool per domain, correct?
> 
> Before deciding in which direction to go (multiple cpupools, sub-
> pools,
> kind of implicit cpu pinning) 
>
You mention "implicit pinning" here, and I'd like to stress this,
because basically no one (else) in the conversation seem to have
considered it. In fact, it may not necessarily be the best long term
solution, but doing something based on pinning is, IMO, a very
convenient first step (and may well become one of the 'modes' available
to the user for taking advantage of big.LITTLE.

So, if cpus 0-3 are big and cpus 4,5 are LITTLE, we can:
 - for domain X, which wants to run only on big cores, pin all it's
   vcpus to pcpus 0-3
 - for domain Y, which wants to run only on LITTLE cores, pin all it's
   vcpus to pcpus 4,5
 - for domain Z, which wants its vcpus 0,1 to run on big cores, and
   it's vcpus 2,3 to run on LITTLE cores, pin vcpus 0,1 to pcpus 0-3, 
   and pin vcpus 2,3 to pcpus 4,5

Setting thing up like this, even automatically, either in hypervisor or
toolstack, is basically already possible (with all the good and bad
aspects of pinning, of course).

Then, sure (as I said when replying to George), we may want things to
be more flexible, and we also probably want to be on the safe side --if 
ever some components manages to undo our automatic pinning-- wrt the
scheduler not picking up work for the wrong architecture... But still
I'm a bit surprised this did not came up... Julien, Peng, is that
because you think this is not doable for any reason I'm missing?

> I think we should think about the
> implications regarding today's interfaces:
> 
I totally agree. (At least) These three things should be very clear,
before starting to implement anything:
 - what is the behavior that we want to achieve, from the point of 
   view of both the hypervisor and the guests
 - what will be the interface
 - how this new interface will map and will interact with existing 
   interfaces

> - Do we want to be able to use different schedulers for big/little
>   (this would mean some cpupool related solution)? I'd prefer to
>   have only one scheduler type for each domain. :-)
> 
Well, this, actually is, IMO, from a behavioral perspective, a nice
point in favour of supporting a split-cpupool solution. In fact, I
think I can envision scenario and reasons for having different
schedulers between big cpus and LITTLE cpus (or same scheduler with
different parameters).

But then, yes, if we then want a domain to have both big and LITTLE
cpus, we'd need to allow a domain to live in more than one cpupool at a
time, which means a domain will have multiple schedulers.

I don't think this is impossible... almost all the scheduling happens
at the vcpu level already. The biggest challenge is probably the
interface. _HOWEVER_, I think this is something that can well come
later, like in phase 2 or 3, as an enhancement/possibility, instead
than be the foundation of big.LITTLE support in Xen.

> - What about scheduling parameters like weight and cap? How would
>   those apply (answer probably influencing pinning solution).
>   Remember that especially the downsides of pinning led to the
>   introduction of cpupools.
> 
Very important bit indeed. FWIW, there's already a scheduler that
supports per-vcpu parameters (so some glue code, or code from which to
take inspiration) is there already. And scheduling happens at the vcpu
level anyway. I.e., it would not be to hard to make it possible to pass
down to Xen, say, per-vcpu weights. Then, at, e.g., xl level, you
specify a set of parameters for big cpus, and another set for LITTLE
cpus, and either xl itself or libxl will do the mapping and prepare the
per-vcpu values.

Again, this is just to say that the "cpupool way" does not look too
impossible, and may be interesting. However, although I'd like to think
more (and see more thoughts) about designs and possibilities, I still
continue to think it should not be neither the only nor the first mode
that we will implement.

> - Is big.LITTLE to be expected to be combined with NUMA?
> 
> - Do we need to support live migration for domains containing both
>   types of cpus?
> 
Interesting points too.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list

Re: [Xen-devel] [PATCH v6 3/6] livepatch: NOP if func->new_addr is zero.

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 10:31:23AM -0600, Jan Beulich wrote:
> >>> On 19.09.16 at 18:11,  wrote:
> > On Mon, Sep 19, 2016 at 02:59:32AM -0600, Jan Beulich wrote:
> >> >>> On 16.09.16 at 17:29,  wrote:
> >> > @@ -31,11 +30,11 @@ void arch_livepatch_revive(void)
> >> >  
> >> >  int arch_livepatch_verify_func(const struct livepatch_func *func)
> >> >  {
> >> > -/* No NOP patching yet. */
> >> > -if ( !func->new_size )
> >> > +/* If NOPing only do up to maximum amount we can put in the 
> >> > ->opaque. */
> >> > +if ( !func->new_addr && func->new_size > sizeof(func->opaque) )
> >> >  return -EOPNOTSUPP;
> >> >  
> >> > -if ( func->old_size < PATCH_INSN_SIZE )
> >> > +if ( func->old_size < ARCH_PATCH_INSN_SIZE )
> >> >  return -EINVAL;
> >> 
> >> Is that indeed a requirement when NOPing? You can easily NOP out
> >> just a single byte on x86. Or shouldn't in that case old_size == new_size
> >> anyway? In which case the comment further down stating that new_size
> > 
> > The original intent behind .old_size was to guard against patching
> > functions that were less than our relative jump. 
> > 
> > (The tools end up computing the .old_size as the size of the whole function
> > which is fine).
> > 
> > But with this NOPing support, you are right - we could have now an
> > function that is say 4 bytes long and we only need to NOP three bytes
> > out of it (the last instruction I assume would be 'ret').
> > 
> > So perhaps this check needs just needs an 'else if' , like so:
> > 
> > int arch_livepatch_verify_func(const struct livepatch_func *func)
> > {
> > /* If NOPing.. */
> > if ( !func->new_addr )
> > {
> > /* Only do up to maximum amount we can put in the ->opaque. */
> > if ( func->new_size > sizeof(func->opaque) )
> > return -EOPNOTSUPP;
> > 
> > /* One instruction for 'ret' and the other to NOP. */
> > if ( func->old_size < 2 )
> > return -EINVAL;
> > }
> > else if ( func->old_size < ARCH_PATCH_INSN_SIZE )
> > return -EINVAL;
> > 
> > return 0;
> > }
> 
> Except that I wouldn't use 2, to not exclude patching out some
> single byte in the middle of a function, without regard to what the
> function's actual size is.

Uh-uh.

The _new_size_ determines how many bytes to NOP (in the context of
this patch). The old_size (where we check to be at min 2) is a safety
valve to make sure we don't NOP something outside the function.

..snip..
> >> NOP addition here, perhaps worth dropping the _jmp from the
> >> function name (and its revert counterpart)?
> > 
> > Ooh, good idea. But I think it maybe better as a seperate patch (as it
> > also touches the ARM code).
> 
> That's in the other series, isn't it?

It expands the existing ones. Right now in 'staging' branch we have an
arch/arm/livepatch.c which has these functions in it.

Granted nothing compiles them, so I could break it in this patch.

But I already cobbled up the patch so may as well use it?

From 45abdd6a0c3a6a2ca7180c7340032ac5b2b186a4 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 19 Sep 2016 12:20:27 -0400
Subject: [PATCH] livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp

With "livepatch: NOP if func->new_addr is zero." that name
makes no more sense.

Suggested-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
---
v7: New submission
---
 xen/arch/arm/livepatch.c| 4 ++--
 xen/arch/x86/livepatch.c| 4 ++--
 xen/include/xen/livepatch.h | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 755f596..7f067a0 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -21,11 +21,11 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return -ENOSYS;
 }
 
-void arch_livepatch_apply_jmp(struct livepatch_func *func)
+void arch_livepatch_apply(struct livepatch_func *func)
 {
 }
 
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+void arch_livepatch_revert(const struct livepatch_func *func)
 {
 }
 
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 118770e..36bbc5f 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -47,7 +47,7 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return 0;
 }
 
-void arch_livepatch_apply_jmp(struct livepatch_func *func)
+void arch_livepatch_apply(struct livepatch_func *func)
 {
 uint8_t *old_ptr;
 uint8_t insn[sizeof(func->opaque)];
@@ -76,7 +76,7 @@ void arch_livepatch_apply_jmp(struct livepatch_func *func)
 memcpy(old_ptr, insn, len);
 }
 
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+void arch_livepatch_revert(const struct livepatch_func *func)
 {
 memcpy(func->old_addr, func->opaque, livepatch_insn_len(func));
 }
diff --git 

Re: [Xen-devel] per-domain logging

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 04:23:06PM +0100, Ian Jackson wrote:
> Cedric Bosdonnat writes ("Re: [Xen-devel] per-domain logging"):
> > On Thu, 2016-09-15 at 16:11 +0100, Wei Liu wrote:
> > > IIRC there is already logfile abstraction inside libvirt -- can you just
> > > pass in a libvirt logfile fd and try to demux there?
> > 
> > The abstraction we have is something similar to the XenToolLogger,
> > not something abstracting the log files. Even if we had that, how
> > could we demux since there is no domain name in the libxl messages.
> 
> Right.
> 
> It's not trivial to change the xtl API because there is no
> negotiation, just a vops structure.  I can think of a way to do it,
> but do we want to make all xtl logger users (that is, all generators
> of log messages) pass a domid ?
> 
> Do we want to extend this to other information ?  (Not sure _what_
> other information.)

It would very much be useful for migration. So that you can
have mulitple logs.
> 
> Alternatively, we could have libxl (and perhaps libxc) put the domid
> in a standard format in the message, so it could be extracted ?
> 
> However we do it, we would have to add a domid to every LOG call in
> libxl.

Ugh. I am leaning towards the xtl API change (whatever that may be).
> 
> Ian.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: lift BUILD_BUG_ON to a tools header file

[Wei Liu]

On Mon, Sep 19, 2016 at 05:48:38PM +0100, Andrew Cooper wrote:
> On 19/09/16 17:46, Wei Liu wrote:
> >On Mon, Sep 19, 2016 at 04:07:30PM +0100, Wei Liu wrote:
> >>Only define BUILD_BUG_ON when there isn't one already, because mini-os
> >>currently leaks that.
> >>
> >>Signed-off-by: Wei Liu 
> >>---
> >>Cc: Ian Jackson 
> >>Cc: Paulina Szubarczyk 
> >>
> >>This is a patch taken out of my branch to clean up some build system
> >>issues. It is still a bit ugly because BUILD_BUG_ON is conditionally
> >>defined to work around mini-os leaking BUILD_BUG_ON.
> >>
> >>Either this patch or "[PATCH v2] libs/gnttab: introduce
> >>XENGNTTAB_BUILD_BUG_ON" should be taken to unblock Paulina's work.
> >>---
> >>  tools/firmware/hvmloader/rombios.c |  1 +
> >>  tools/firmware/hvmloader/smbios.c  |  1 +
> >>  tools/firmware/hvmloader/util.h|  1 -
> >Oops, I just realise that these changes need an ack from Jan / Andrew.
> >
> >Jan and Andrew: Since  I can do a partial revert if you're not happy
> >with those changes.
> >
> >Sorry for not having CC'ed you two earlier.
> 
> HVMLoader really should be standalone IMO.
> 
> However, while you are fixing that, can you also fix the broken header guard
> for xen-tools/libs.h ?
> 

Sure, first thing tomorrow.

Wei.

> ~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: lift BUILD_BUG_ON to a tools header file

[Andrew Cooper]

On 19/09/16 17:46, Wei Liu wrote:

On Mon, Sep 19, 2016 at 04:07:30PM +0100, Wei Liu wrote:

Only define BUILD_BUG_ON when there isn't one already, because mini-os
currently leaks that.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Paulina Szubarczyk 

This is a patch taken out of my branch to clean up some build system
issues. It is still a bit ugly because BUILD_BUG_ON is conditionally
defined to work around mini-os leaking BUILD_BUG_ON.

Either this patch or "[PATCH v2] libs/gnttab: introduce
XENGNTTAB_BUILD_BUG_ON" should be taken to unblock Paulina's work.
---
  tools/firmware/hvmloader/rombios.c |  1 +
  tools/firmware/hvmloader/smbios.c  |  1 +
  tools/firmware/hvmloader/util.h|  1 -

Oops, I just realise that these changes need an ack from Jan / Andrew.

Jan and Andrew: Since  I can do a partial revert if you're not happy
with those changes.

Sorry for not having CC'ed you two earlier.


HVMLoader really should be standalone IMO.

However, while you are fixing that, can you also fix the broken header 
guard for xen-tools/libs.h ?


~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: lift BUILD_BUG_ON to a tools header file

[Wei Liu]

On Mon, Sep 19, 2016 at 04:07:30PM +0100, Wei Liu wrote:
> Only define BUILD_BUG_ON when there isn't one already, because mini-os
> currently leaks that.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Paulina Szubarczyk 
> 
> This is a patch taken out of my branch to clean up some build system
> issues. It is still a bit ugly because BUILD_BUG_ON is conditionally
> defined to work around mini-os leaking BUILD_BUG_ON.
> 
> Either this patch or "[PATCH v2] libs/gnttab: introduce
> XENGNTTAB_BUILD_BUG_ON" should be taken to unblock Paulina's work.
> ---
>  tools/firmware/hvmloader/rombios.c |  1 +
>  tools/firmware/hvmloader/smbios.c  |  1 +
>  tools/firmware/hvmloader/util.h|  1 -

Oops, I just realise that these changes need an ack from Jan / Andrew.

Jan and Andrew: Since  I can do a partial revert if you're not happy
with those changes.

Sorry for not having CC'ed you two earlier.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Mon, 2016-09-19 at 11:33 +0100, George Dunlap wrote:
> On 19/09/16 11:06, Julien Grall wrote:
> > So, if I understand correctly, you would not recommend to extend
> > the
> > number of CPU pool per domain, correct?
> 
> Well imagine trying to set the scheduling parameters, such as weight,
> which in the past have been per-domain.  Now you have to specify
> parameters for a domain in each of the cpupools that its' in.
> 
True, and not really convenient indeed. I think we can think of a way
to shape the interface in such a way that it's not too bad to use
(provide sane defaults/default behavior, etc), but this should be
definitely kept in mind.

In general, I agree with Juergen that, before implementing anything, we
must come up with a design, bearing in mind both behavior and
interface.

(I'll reply in some more details directly to Juergen's email.)

> No, I think it would be a lot simpler to just teach the scheduler
> aboutIf we want to support heterogeneous CPUs, some like this is
> absolutely necessary. In fact, either we set (and enforce) very
> strict rules on cpupools and pinning, or we'd end up scheduling stuff
> built for arch A on a processor of arch B! :-O
> different classes of cpus.  credit1 would probably need to be
> modified
> so that its credit algorithm would be per-class rather than pool-
> wide;
> but credit2 shouldn't need much modification at all, other than to
> make
> sure that a given runqueue doesn't include more than one class; and
> to
> do load-balancing only with runqueues of the same class.
> 
If we want to support heterogeneous CPUs, some like this is absolutely
necessary. In fact, either we set (and enforce) very strict rules on
cpupools and pinning, or we'd end up scheduling stuff built for arch A
on a processor of arch B! :-O

The "strict limits" approach may be an option --and this patch is a
first example of it-- but it's easy to see that it's very inflexible
(cpus can't move between pools, domains can't be migrated, etc). On the
other hand, as soon as we "relax" the constraints a little bit, we
absolutely need to modify the scheduler code to avoid bad things to
happen.

As George is saying, both Credit1 and Credit2 needs to be modified in
order to make sure that a vcpu that is meant to run on a big cpu is not
picked up for being executed by a LITTLE cpu. This has to do with
tweaking the load balancing code in both of them (e.g., in Credit1, a
LITTLE cpu must not steal work from a big cpu). Whether or not it will
also be required to change the Credit-ing algorithm, it will have to be
seen. The effect would be similar to some sort of pinning, which indeed
does not play well with Credit1 accounting logic... but we can probably
see about this along the way (or just focus only con Credit2! :-P)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

flight 101010 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101010/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100993
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100993
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100993

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuu0f2fa73ba0ca19ebdaccf0d1785583d6601411b6
baseline version:
 qemuue3571ae30cd26d19efd4554c25e32ef64d6a36b3

Last test of basis   100993  2016-09-16 20:48:24 Z2 days
Testing same since   101010  2016-09-19 11:14:06 Z0 days1 attempts


People who touched revisions under test:
  Cornelia Huck  [ccw]
  Greg Kurz 
  Maxime Coquelin 
  Michael S. Tsirkin 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
 On 15.09.16 at 18:51,  wrote:
>> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
>> *hvmemul_ctxt,
>>  pfec |= PFEC_user_mode;
>>
>>  hvmemul_ctxt->insn_buf_eip = regs->eip;
>> -if ( !vio->mmio_insn_bytes )
>> +
>> +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>> +{
>> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
>> + sizeof(curr->arch.vm_event->emul.insn));
>
> This should quite clearly be !=, and I think it builds only because you
> use the wrong operand in the first sizeof().

Yea.. I don't know what I was thinking =)

>
>> +hvmemul_ctxt->insn_buf_bytes = 
>> sizeof(curr->arch.vm_event->emul.insn);
>> +memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul.insn,
>> +   hvmemul_ctxt->insn_buf_bytes);
>
> This memcpy()s between dissimilar types. Please omit the & and
> properly add .data on the second argument (and this .data
> addition should then also be mirrored in the BUILD_BUG_ON()).

Ack.

>
>> +}
>> +else if ( !vio->mmio_insn_bytes )
>
> And then - I'm sorry for not having thought of this before - I think
> this would better not live here, or have an effect more explicitly
> only when coming here through hvm_emulate_one_vm_event().
> Since the former seems impractical, I think giving _hvm_emulate_one()
> one or two extra parameters would be the most straightforward
> approach.
>
>> @@ -1944,11 +1954,11 @@ void hvm_mem_access_emulate_one(enum emul_kind kind, 
>> unsigned int trapnr,
>>  case EMUL_KIND_NOWRITE:
>>  rc = hvm_emulate_one_no_write();
>>  break;
>> -case EMUL_KIND_SET_CONTEXT:
>> -ctx.set_context = 1;
>> -/* Intentional fall-through. */
>>  default:
>> +ctx.set_context_data = (kind == EMUL_KIND_SET_CONTEXT_DATA);
>> +ctx.set_context_insn = (kind == EMUL_KIND_SET_CONTEXT_INSN);
>>  rc = hvm_emulate_one();
>> +break;
>>  }
>
> Thanks - this is a lot better readable now!
>
>> @@ -1983,7 +1993,8 @@ void hvm_emulate_prepare(
>>  hvmemul_ctxt->ctxt.force_writeback = 1;
>>  hvmemul_ctxt->seg_reg_accessed = 0;
>>  hvmemul_ctxt->seg_reg_dirty = 0;
>> -hvmemul_ctxt->set_context = 0;
>> +hvmemul_ctxt->set_context_data = 0;
>> +hvmemul_ctxt->set_context_insn = 0;
>
> I think you can almost guess the comment here and on the declaration
> of these fields: Please use false here and plain bool there.
>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -489,13 +489,16 @@ void hvm_do_resume(struct vcpu *v)
>>
>>  if ( v->arch.vm_event->emulate_flags &
>>   VM_EVENT_FLAG_SET_EMUL_READ_DATA )
>> -kind = EMUL_KIND_SET_CONTEXT;
>> +kind = EMUL_KIND_SET_CONTEXT_DATA;
>>  else if ( v->arch.vm_event->emulate_flags &
>>VM_EVENT_FLAG_EMULATE_NOWRITE )
>>  kind = EMUL_KIND_NOWRITE;
>> +else if ( v->arch.vm_event->emulate_flags &
>> + VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
>> +kind = EMUL_KIND_SET_CONTEXT_INSN;
>
> The header talking about incompatibilities between these flags -
> wouldn't it be a good idea to actually -EINVAL such combinations?

The header just points out that setting all these flags at the same
time won't have a "combined" effect - evident from the if-else
treatment above. There is really no point to do an error, the error
would never reach the user. Setting response flags through vm_event
doesn't have an error-path back.

>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -57,6 +57,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>
> I have to admit that looking through the header changes you do I
> can't figure why this adjustment is necessary.

Yea, it's just a residue (the patch was first made when this header
was still included).

>
>> --- a/xen/arch/x86/vm_event.c
>> +++ b/xen/arch/x86/vm_event.c
>> @@ -209,11 +209,18 @@ void vm_event_emulate_check(struct vcpu *v, 
>> vm_event_response_t *rsp)
>>  if ( p2m_mem_access_emulate_check(v, rsp) )
>>  {
>>  if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA )
>> -v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
>> +v->arch.vm_event->emul.read = rsp->data.emul.read;
>>
>>  v->arch.vm_event->emulate_flags = rsp->flags;
>>  }
>>  break;
>> +case VM_EVENT_REASON_SOFTWARE_BREAKPOINT:
>> +if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
>> +{
>> +v->arch.vm_event->emul.insn = rsp->data.emul.insn;
>> +v->arch.vm_event->emulate_flags = rsp->flags;
>> +}
>> +break;
>>  default:
>
> Blank lines between non-fall-through 

Re: [Xen-devel] [PATCH v6 3/6] livepatch: NOP if func->new_addr is zero.

[Jan Beulich]

>>> On 19.09.16 at 18:11,  wrote:
> On Mon, Sep 19, 2016 at 02:59:32AM -0600, Jan Beulich wrote:
>> >>> On 16.09.16 at 17:29,  wrote:
>> > @@ -31,11 +30,11 @@ void arch_livepatch_revive(void)
>> >  
>> >  int arch_livepatch_verify_func(const struct livepatch_func *func)
>> >  {
>> > -/* No NOP patching yet. */
>> > -if ( !func->new_size )
>> > +/* If NOPing only do up to maximum amount we can put in the ->opaque. 
>> > */
>> > +if ( !func->new_addr && func->new_size > sizeof(func->opaque) )
>> >  return -EOPNOTSUPP;
>> >  
>> > -if ( func->old_size < PATCH_INSN_SIZE )
>> > +if ( func->old_size < ARCH_PATCH_INSN_SIZE )
>> >  return -EINVAL;
>> 
>> Is that indeed a requirement when NOPing? You can easily NOP out
>> just a single byte on x86. Or shouldn't in that case old_size == new_size
>> anyway? In which case the comment further down stating that new_size
> 
> The original intent behind .old_size was to guard against patching
> functions that were less than our relative jump. 
> 
> (The tools end up computing the .old_size as the size of the whole function
> which is fine).
> 
> But with this NOPing support, you are right - we could have now an
> function that is say 4 bytes long and we only need to NOP three bytes
> out of it (the last instruction I assume would be 'ret').
> 
> So perhaps this check needs just needs an 'else if' , like so:
> 
> int arch_livepatch_verify_func(const struct livepatch_func *func)
> {
> /* If NOPing.. */
> if ( !func->new_addr )
> {
> /* Only do up to maximum amount we can put in the ->opaque. */
> if ( func->new_size > sizeof(func->opaque) )
> return -EOPNOTSUPP;
> 
> /* One instruction for 'ret' and the other to NOP. */
> if ( func->old_size < 2 )
> return -EINVAL;
> }
> else if ( func->old_size < ARCH_PATCH_INSN_SIZE )
> return -EINVAL;
> 
> return 0;
> }

Except that I wouldn't use 2, to not exclude patching out some
single byte in the middle of a function, without regard to what the
function's actual size is.

>> can be zero would also be wrong.
>> 
>> > @@ -43,23 +42,36 @@ int arch_livepatch_verify_func(const struct 
>> > livepatch_func *func)
>> >  
>> >  void arch_livepatch_apply_jmp(struct livepatch_func *func)
>> >  {
>> > -int32_t val;
>> >  uint8_t *old_ptr;
>> > -
>> > -BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
>> > -BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof(val)));
>> > +uint8_t insn[sizeof(func->opaque)];
>> > +unsigned int len;
>> >  
>> >  old_ptr = func->old_addr;
>> > -memcpy(func->opaque, old_ptr, PATCH_INSN_SIZE);
>> > +len = livepatch_insn_len(func);
>> > +if ( !len )
>> > +return;
>> > +
>> > +memcpy(func->opaque, old_ptr, len);
>> > +if ( func->new_addr )
>> > +{
>> > +int32_t val;
>> > +
>> > +BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != (1 + sizeof(val)));
>> > +
>> > +insn[0] = 0xe9;
>> > +val = func->new_addr - func->old_addr - ARCH_PATCH_INSN_SIZE;
>> > +
>> > +memcpy([1], , sizeof(val));
>> > +}
>> > +else
>> > +add_nops(, len);
>> >  
>> > -*old_ptr++ = 0xe9; /* Relative jump */
>> 
>> Are you btw intentionally getting rid of this comment? And with the
> 
> Not at all. Just missed it.
>> NOP addition here, perhaps worth dropping the _jmp from the
>> function name (and its revert counterpart)?
> 
> Ooh, good idea. But I think it maybe better as a seperate patch (as it
> also touches the ARM code).

That's in the other series, isn't it?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/5] x86/time: implement tsc as clocksource

[Jan Beulich]

>>> On 19.09.16 at 18:11,  wrote:
> On 09/19/2016 11:13 AM, Jan Beulich wrote:
> On 14.09.16 at 19:37,  wrote:
>>> Since b64438c7c ("x86/time: use correct (local) time stamp in
>>> constant-TSC calibration fast path") updates to cpu time use local
>>> stamps, which means platform timer is only used to seed the initial
>>> cpu time.  With clocksource=tsc there is no need to be in sync with
>>> another clocksource, so we reseed the local/master stamps to be values
>>> of TSC and update the platform time stamps accordingly. Time
>>> calibration is set to 1sec after we switch to TSC, thus these stamps
>>> are reseeded to also ensure monotonic returning values right after the
>>> point we switch to TSC. This is also to avoid the possibility of
>>> having inconsistent readings in this short period (i.e. until
>>> calibration fires).
>> 
>> And within this one second, which may cover some of Dom0's
>> booting up, it is okay to have inconsistencies?
> It's not okay which is why I am removing this possibility when switching to 
> TSC.
> The inconsistencies in those readings (if I wasn't adjusting) would be because
> we would be using (in that 1-sec) those cpu time tuples calculated by the
> previous calibration or platform time initialization (while still was HPET,
> ACPI, etc as clocksource). Would you prefer me removing the "avoid" and 
> instead
> change it to "remove the possibility" in this last sentence?

Let's not do the 2nd step before the 1st, which is the question of
what happens prior to and what actually changes at this first
calibration (after 1 sec).

>>> +static void __init try_platform_timer_tail(void)
>>> +{
>>> +init_timer(_overflow_timer, plt_overflow, NULL, 0);
>>> +plt_overflow(NULL);
>>> +
>>> +platform_timer_stamp = plt_stamp64;
>>> +stime_platform_stamp = NOW();
>>> +
>>> +if ( !clocksource_is_tsc() )
>>> +init_percpu_time();
>> 
>> This isn't really dependent on whether TSC is used as clocksource,
>> but solely on the point in time at which the call gets made, is it? If
>> so, I think an explicit boolean function parameter (named e.g. "late")
>> would be better than abusing the predicate here.
> 
> Correct, I will introduce this boolean parameter. Not that is critical but
> probably add an likely(...) there too, since the late case only happens for
> clocksource=tsc ?

Well, in __init code I prefer to avoid likely()/unlikely(), unless it's
in e.g. a performance critical loop.

>>> @@ -1480,6 +1570,25 @@ static int __init verify_tsc_reliability(void)
>>>  printk("TSC warp detected, disabling TSC_RELIABLE\n");
>>>  setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);
>>>  }
>>> +else if ( !strcmp(opt_clocksource, "tsc") &&
>>> +  (try_platform_timer(_tsc) > 0) )
>>> +{
>>> +/*
>>> + * Platform timer has changed and CPU time will only be updated
>>> + * after we set again the calibration timer, which means we 
>>> need to
>>> + * seed again each local CPU time. At this stage TSC is known 
>>> to be
>>> + * reliable i.e. monotonically increasing across all CPUs so 
>>> this
>>> + * lets us remove the skew between platform timer and TSC, 
>>> since
>>> + * these are now effectively the same.
>>> + */
>>> +on_selected_cpus(_online_map, reset_percpu_time, NULL, 1);
>>> +
>>> +/* Finish platform timer switch. */
>>> +try_platform_timer_tail();
>>> +
>>> +printk(XENLOG_INFO "Switched to Platform timer %s TSC\n",
>>> +   freq_string(plt_src.frequency));
>> 
>> This message should have the same log level as the one at the end
>> of init_platform_timer().
> Agreed, but at the end of init_platform_timer there is a plain printk with an
> omitted log level. Or do you mean to remove XENLOG_INFO from this printk above
> or, instead add XENLOG_INFO to one printk at the end of 
> init_platform_timer() ?

Well, info would again be too low a level for my taste. Hence either
remove the level here (slightly preferred from my pov), or make both
warning.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: lift BUILD_BUG_ON to a tools header file

[Wei Liu]

On Mon, Sep 19, 2016 at 04:38:15PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] tools: lift BUILD_BUG_ON to a tools header file"):
> > Only define BUILD_BUG_ON when there isn't one already, because mini-os
> > currently leaks that.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Ian Jackson 
> > Cc: Paulina Szubarczyk 
> > 
> > This is a patch taken out of my branch to clean up some build system
> > issues. It is still a bit ugly because BUILD_BUG_ON is conditionally
> > defined to work around mini-os leaking BUILD_BUG_ON.
> 
> Thanks!
> 
> Acked-by: Ian Jackson 

Pushed, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 1/2] libs/gnttab: introduce grant copy interface

[Wei Liu]

On Mon, Sep 19, 2016 at 04:58:23PM +0100, Wei Liu wrote:
> On Wed, Sep 14, 2016 at 09:10:02PM +0200, Paulina Szubarczyk wrote:
> > In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..)
> > system call is invoked. In mini-os the operation is yet not
> > implemented. For the OSs that does not implement gnttab the
> > call of the grant copy operation causes abort.
> > 
> > Signed-off-by: Paulina Szubarczyk 
> > Reviewed-by: David Vrabel 
> 
> Paulina, this is mostly for your information. No action is needed on
> your side. Thanks for putting in the effort to contribute to Xen.
> 
> Because Ian prefers another way of dealing with BUILD_BUG_ON, I've sent
> out another patch for that.  I also write the following patch to fix up
> this patch.
> 
> ---8<---
> From 096fef32bffaef5b3e273bdfe75d620d8a7c8792 Mon Sep 17 00:00:00 2001
> From: Wei Liu 
> Date: Mon, 19 Sep 2016 16:50:35 +0100
> Subject: [PATCH] fixup! libs/gnttab: introduce grant copy interface
> 

Squashed the fixup into this patch and pushed to staging.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 0/9] Introduce AMD SVM AVIC

[Suravee Suthikulpanit]

On 9/19/16 20:09, Konrad Rzeszutek Wilk wrote:

On Mon, Sep 19, 2016 at 12:52:39AM -0500, Suravee Suthikulpanit wrote:

GITHUB
==
Latest git tree can be found at:
http://github.com/ssuthiku/xen.gitxen_avic_part1_v1

OVERVIEW

This patch set is the first of the two-part patch series to introduce
the new AMD Advance Virtual Interrupt Controller (AVIC) support.

Basically, SVM AVIC hardware virtualizes local APIC registers of each
vCPU via the virtual APIC (vAPIC) backing page. This allows guest access
to certain APIC registers without the need to emulate the hardware behavior
in the hypervisor. More information about AVIC can be found in the
AMD64 Architecture Programmer’s Manual Volume 2 - System Programming.

  http://support.amd.com/TechDocs/24593.pdf

For SVM AVIC, we extend the existing kvm_amd driver to:


kvm_amd ?, heheh


Ooops. hehehe


.. snip..

Note: In "w/o evtchn" case, the Linux guest is built w/o
  Xen guest support.


You can also just boot Linux with 'xen_nopv' parameter which would
do the same thing.



Ok, Thanks for the tips.

Suravee

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 3/6] livepatch: NOP if func->new_addr is zero.

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 02:59:32AM -0600, Jan Beulich wrote:
> >>> On 16.09.16 at 17:29,  wrote:
> > @@ -31,11 +30,11 @@ void arch_livepatch_revive(void)
> >  
> >  int arch_livepatch_verify_func(const struct livepatch_func *func)
> >  {
> > -/* No NOP patching yet. */
> > -if ( !func->new_size )
> > +/* If NOPing only do up to maximum amount we can put in the ->opaque. 
> > */
> > +if ( !func->new_addr && func->new_size > sizeof(func->opaque) )
> >  return -EOPNOTSUPP;
> >  
> > -if ( func->old_size < PATCH_INSN_SIZE )
> > +if ( func->old_size < ARCH_PATCH_INSN_SIZE )
> >  return -EINVAL;
> 
> Is that indeed a requirement when NOPing? You can easily NOP out
> just a single byte on x86. Or shouldn't in that case old_size == new_size
> anyway? In which case the comment further down stating that new_size

The original intent behind .old_size was to guard against patching
functions that were less than our relative jump. 

(The tools end up computing the .old_size as the size of the whole function
which is fine).

But with this NOPing support, you are right - we could have now an
function that is say 4 bytes long and we only need to NOP three bytes
out of it (the last instruction I assume would be 'ret').

So perhaps this check needs just needs an 'else if' , like so:

int arch_livepatch_verify_func(const struct livepatch_func *func)
{
/* If NOPing.. */
if ( !func->new_addr )
{
/* Only do up to maximum amount we can put in the ->opaque. */
if ( func->new_size > sizeof(func->opaque) )
return -EOPNOTSUPP;

/* One instruction for 'ret' and the other to NOP. */
if ( func->old_size < 2 )
return -EINVAL;
}
else if ( func->old_size < ARCH_PATCH_INSN_SIZE )
return -EINVAL;

return 0;
}

[And update the design]
> can be zero would also be wrong.
> 
> > @@ -43,23 +42,36 @@ int arch_livepatch_verify_func(const struct 
> > livepatch_func *func)
> >  
> >  void arch_livepatch_apply_jmp(struct livepatch_func *func)
> >  {
> > -int32_t val;
> >  uint8_t *old_ptr;
> > -
> > -BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
> > -BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof(val)));
> > +uint8_t insn[sizeof(func->opaque)];
> > +unsigned int len;
> >  
> >  old_ptr = func->old_addr;
> > -memcpy(func->opaque, old_ptr, PATCH_INSN_SIZE);
> > +len = livepatch_insn_len(func);
> > +if ( !len )
> > +return;
> > +
> > +memcpy(func->opaque, old_ptr, len);
> > +if ( func->new_addr )
> > +{
> > +int32_t val;
> > +
> > +BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != (1 + sizeof(val)));
> > +
> > +insn[0] = 0xe9;
> > +val = func->new_addr - func->old_addr - ARCH_PATCH_INSN_SIZE;
> > +
> > +memcpy([1], , sizeof(val));
> > +}
> > +else
> > +add_nops(, len);
> >  
> > -*old_ptr++ = 0xe9; /* Relative jump */
> 
> Are you btw intentionally getting rid of this comment? And with the

Not at all. Just missed it.
> NOP addition here, perhaps worth dropping the _jmp from the
> function name (and its revert counterpart)?

Ooh, good idea. But I think it maybe better as a seperate patch (as it
also touches the ARM code).

> 
> > +static inline size_t livepatch_insn_len(const struct livepatch_func *func)
> 
> I think it would be nice to use consistent types: The current sole caller
> stores the result of the function in an unsigned int, and I see no reason
> why the function couldn't also return such.

/me nods.

> 
> Jan
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 4/5] x86/time: implement PVCLOCK_TSC_STABLE_BIT

[Joao Martins]

On 09/19/2016 11:22 AM, Jan Beulich wrote:
 On 14.09.16 at 19:37,  wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -951,6 +951,14 @@ static void __update_vcpu_system_time(struct vcpu *v, 
>> int force)
>>  _u.tsc_timestamp = tsc_stamp;
>>  _u.system_time   = t->stamp.local_stime;
>>  
>> +/*
>> + * It's expected that domains cope with this bit changing on every
>> + * pvclock read to check whether they can resort solely on this tuple
>> + * or if it further requires monotonicity checks with other vcpus.
>> + */
>> +if ( clocksource_is_tsc() )
>> +_u.flags|= XEN_PVCLOCK_TSC_STABLE_BIT;
> 
> Stray blanks ahead of the |=.
> 
Will fix it.

> With that taken care of
> Reviewed-by: Jan Beulich 
Thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 5/5] x86/time: extend "tsc" param with "stable:socket"

[Joao Martins]

On 09/19/2016 11:29 AM, Jan Beulich wrote:
 On 14.09.16 at 19:37,  wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -270,7 +270,9 @@ If set, override Xen's default choice for the platform 
>> timer.
>>  Having TSC as platform timer requires being explicitly set. This is because
>>  TSC can only be safely used if CPU hotplug isn't performed on the system. In
>>  some platforms, "maxcpus" parameter may require further adjustment to the
>> -number of online cpus.
>> +number of online cpus. When running under platforms that can guarantee a
> 
> ... running on platforms ...
> 
>> +monotonic TSC across sockets you require adjusting "tsc" command line 
>> parameter
> 
> ... you may want to adjust the ...
> 
>> +parameter to "stable:sockets".
> 
> Redundant "parameter" (I guess the one on the earlier line was meant
> to get moved due to line length). Also you say "sockets" here but ...
> 
>> @@ -1508,7 +1510,7 @@ pages) must also be specified via the tbuf\_size 
>> parameter.
>>  > `= `
>>  
>>  ### tsc
>> -> `= unstable | skewed`
>> +> `= unstable | skewed | stable:socket`
> 
> "socket" here - the two really should match.
Correct, I will fix this parameter name mismatch, and the spelling mistakes you
pointed out above.

>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -477,6 +477,10 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
>>  /
>>   * PLATFORM TIMER 4: TSC
>>   */
>> +static unsigned int __read_mostly tsc_flags;
> 
> __initdata instead of __read_mostly
OK.

Joao

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 3/5] x86/time: refactor read_platform_stime()

[Joao Martins]

On 09/19/2016 11:15 AM, Jan Beulich wrote:
 On 14.09.16 at 19:37,  wrote:
>> To allow the caller to fetch the last read from the clocksource which
>> was used to calculate system_time. This is a prerequisite for a
>> subsequent patch that will use this last read.
>>
>> Signed-off-by: Joao Martins 
> 
> Acked-by: Jan Beulich 
> with one further minor request:
> 
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -581,18 +581,22 @@ static void plt_overflow(void *unused)
>>  set_timer(_overflow_timer, NOW() + plt_overflow_period);
>>  }
>>  
>> -static s_time_t read_platform_stime(void)
>> +static s_time_t read_platform_stime(u64 *stamp)
>>  {
>> -u64 count;
>> +u64 plt_counter, count;
>>  s_time_t stime;
>>  
>>  ASSERT(!local_irq_is_enabled());
>>  
>>  spin_lock(_timer_lock);
>> -count = plt_stamp64 + ((plt_src.read_counter() - plt_stamp) & plt_mask);
>> +plt_counter = plt_src.read_counter();
>> +count = plt_stamp64 + ((plt_counter - plt_stamp) & plt_mask);
>>  stime = __read_platform_stime(count);
>>  spin_unlock(_timer_lock);
>>  
>> +if ( stamp )
>> +*stamp = plt_counter;
> 
> Considering that all current callers pass in NULL and you mean to
> add only one (iirc) which doesn't, please add unlikely() here.
OK, I will add it, Thank you!

Joao

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/5] x86/time: implement tsc as clocksource

[Joao Martins]

On 09/19/2016 11:13 AM, Jan Beulich wrote:
 On 14.09.16 at 19:37,  wrote:
>> This patch introduces support for using TSC as platform time source
>> which is the highest resolution time and most performant to get.
>> Though there are also several problems associated with its usage, and
>> there isn't a complete (and architecturally defined) guarantee that
>> all machines will provide reliable and monotonic TSC in all cases (I
>> believe Intel to be the only that can guarantee that?) For this reason
>> it's set with less priority when compared to HPET unless adminstrator
>> changes "clocksource" boot option to "tsc".
> 
> In the following sentence you removed the exclusive mentioning
> of HPET, but above you don't. Furthermore I don't think this
> sentence is in line with what the patch does: There's no priority
> given to it, and it won't be used at all when not requested on the
> command line.
You're right, let me change this sentence to be:

For this reason it's not used unless administrator changes "clocksource" boot
option to "tsc".

> 
>> Initializing TSC
>> clocksource requires all CPUs up to have the tsc reliability checks
>> performed. init_xen_time is called before all CPUs are up, so for
>> example we would start with HPET (or ACPI, PIT) at boot time, and
>> switch later to TSC. The switch then happens on verify_tsc_reliability
>> initcall that is invoked when all CPUs are up. When attempting to
>> initialize TSC we also check for time warps and if it has invariant
>> TSC. Note that while we deem reliable a CONSTANT_TSC with no deep
>> C-states, it might not always be the case, so we're conservative and
>> allow TSC to be used as platform timer only with invariant TSC.
>> Additionally we check if CPU Hotplug isn't meant to be performed on
>> the host which will either be when max vcpus and num_present_cpu are
>> the same. This is because a newly hotplugged CPU may not satisfy the
>> condition of having all TSCs synchronized - so when having tsc
>> clocksource being used we allow offlining CPUs but not onlining any
>> ones back. Finally we prevent TSC from being used as clocksource on
>> multiple sockets because it isn't guaranteed to be invariant. Further
>> relaxing of this last requirement is added in a separate patch, such
>> that we allow vendors with such guarantee to use TSC as clocksource.
>> In case any of these conditions is not met, we keep the clocksource
>> that was previously initialized on init_xen_time.
>>
>> Since b64438c7c ("x86/time: use correct (local) time stamp in
>> constant-TSC calibration fast path") updates to cpu time use local
>> stamps, which means platform timer is only used to seed the initial
>> cpu time.  With clocksource=tsc there is no need to be in sync with
>> another clocksource, so we reseed the local/master stamps to be values
>> of TSC and update the platform time stamps accordingly. Time
>> calibration is set to 1sec after we switch to TSC, thus these stamps
>> are reseeded to also ensure monotonic returning values right after the
>> point we switch to TSC. This is also to avoid the possibility of
>> having inconsistent readings in this short period (i.e. until
>> calibration fires).
> 
> And within this one second, which may cover some of Dom0's
> booting up, it is okay to have inconsistencies?
It's not okay which is why I am removing this possibility when switching to TSC.
The inconsistencies in those readings (if I wasn't adjusting) would be because
we would be using (in that 1-sec) those cpu time tuples calculated by the
previous calibration or platform time initialization (while still was HPET,
ACPI, etc as clocksource). Would you prefer me removing the "avoid" and instead
change it to "remove the possibility" in this last sentence?

> 
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -475,6 +475,50 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
>>  }
>>  
>>  /
>> + * PLATFORM TIMER 4: TSC
>> + */
>> +
>> +/*
>> + * Called in verify_tsc_reliability() under reliable TSC conditions
>> + * thus reusing all the checks already performed there.
>> + */
>> +static s64 __init init_tsc(struct platform_timesource *pts)
>> +{
>> +u64 ret = pts->frequency;
>> +
>> +if ( nr_cpu_ids != num_present_cpus() )
>> +{
>> +printk(XENLOG_INFO "TSC: CPU Hotplug intended\n");
>> +ret = 0;
>> +}
>> +
>> +if ( nr_sockets > 1 )
>> +{
>> +printk(XENLOG_INFO "TSC: Not invariant across sockets\n");
>> +ret = 0;
>> +}
>> +
>> +if ( !ret )
>> +printk(XENLOG_INFO "TSC: Not setting it as clocksource\n");
> 
> I think this last message is redundant with the former two. But since
> I also think that info level is too low for those earlier ones, perhaps
> keeping the latter (at info or even debug level) would be okay, once
> the other got bumped to warning level.
Makes sense and one can infer that message from the 

Re: [Xen-devel] [PATCH v6 10/15] x86/boot: implement early command line parser in C

[Jan Beulich]

>>> On 19.09.16 at 17:27,  wrote:
> On Mon, Sep 19, 2016 at 06:47:50AM -0600, Jan Beulich wrote:
>> >>> On 12.09.16 at 22:18,  wrote:
> 
> [...]
> 
>> > --- a/xen/arch/x86/boot/trampoline.S
>> > +++ b/xen/arch/x86/boot/trampoline.S
>> > @@ -220,8 +220,22 @@ trampoline_boot_cpu_entry:
>> >  /* Jump to the common bootstrap entry point. */
>> >  jmp trampoline_protmode_entry
>> >
>> > +#include "video.h"
>> > +
>> > +.align  2
>> > +.byte   0
>>
>> While this odd placement of the requested padding byte will fulfill
>> the immediate purpose, please do it the originally requested more
>> conventional way (putting it inside the structure and adding a
>> respective field to the C representation). For someone wanting to
>> add another field it'll then be far more obvious what to do without
>> re-introducing mis-alignment.
> 
> OK, however, I am still thinking how to automatically synchronize C and
> assembly early_boot_opts struct definitions or generate one from another.
> This way we can avoid __packed attribute and probably do not care about
> member alignments at all. Do you have an idea how to do that?

I would have ideas, but I think they're all not really suitable for this
little bit of data. If we had this problem in a more widespread manner,
then perhaps. But we're actually aiming at reducing the amount of
assembly language use.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 05/15] efi: create efi_enabled()

[Jan Beulich]

>>> On 19.09.16 at 17:38,  wrote:
> On Mon, Sep 19, 2016 at 08:57:02AM -0600, Jan Beulich wrote:
>> >>> On 19.09.16 at 16:27,  wrote:
>> > On Mon, Sep 19, 2016 at 05:58:46AM -0600, Jan Beulich wrote:
>> >> >>> On 12.09.16 at 22:18,  wrote:
>> >> > --- a/xen/arch/x86/domain_page.c
>> >> > +++ b/xen/arch/x86/domain_page.c
>> >> > @@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>> >> >   * domain's page tables but current may point at another domain's
>> > VCPU.
>> >> >   * Return NULL as though current is not properly set up yet.
>> >> >   */
>> >> > -if ( efi_enabled && efi_rs_using_pgtables() )
>> >> > +if ( efi_enabled(EFI_RS) && efi_rs_using_pgtables() )
>> >>
>> >> I think the efi_enabled() here is pointless now.
>> >
>> > Nope, it seems that Xen will blow up on BUG() in
>> > xen/arch/x86/efi/stub.c:efi_rs_using_pgtables() if
>> > compiler/linker cannot be used to build proper PE binary.
>>
>> Ah, true.
>>
>> > Of course we can change efi_rs_using_pgtables() to
>> > return false in such case.
>>
>> Except that it does already. You mean dropping the BUG() I guess.
> 
> Yep, right. However, should not we change "return 0" to "return false"
> in the same patch if efi_rs_using_pgtables() returns bool_t?

Since you don't touch that line anyway, and since using false
there would then also call for switching from bool_t to bool, I'd
rather leave this for another day.

>> Both ways should be fine then for now.
> 
> Dropping the BUG() from efi_rs_using_pgtables() and efi_enabled in
> above mentioned conditional makes final code, IMO, better. However,
> in this patch context it may look a bit strange. Is it acceptable
> for you to do both in this patch?

Yes, that what I tried to express with my previous reply.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 1/2] libs/gnttab: introduce grant copy interface

[Wei Liu]

On Wed, Sep 14, 2016 at 09:10:02PM +0200, Paulina Szubarczyk wrote:
> In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..)
> system call is invoked. In mini-os the operation is yet not
> implemented. For the OSs that does not implement gnttab the
> call of the grant copy operation causes abort.
> 
> Signed-off-by: Paulina Szubarczyk 
> Reviewed-by: David Vrabel 

Paulina, this is mostly for your information. No action is needed on
your side. Thanks for putting in the effort to contribute to Xen.

Because Ian prefers another way of dealing with BUILD_BUG_ON, I've sent
out another patch for that.  I also write the following patch to fix up
this patch.

---8<---
From 096fef32bffaef5b3e273bdfe75d620d8a7c8792 Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Mon, 19 Sep 2016 16:50:35 +0100
Subject: [PATCH] fixup! libs/gnttab: introduce grant copy interface

---
 tools/libs/gnttab/linux.c | 116 +++---
 1 file changed, 59 insertions(+), 57 deletions(-)

diff --git a/tools/libs/gnttab/linux.c b/tools/libs/gnttab/linux.c
index 6bd9bd2..69b7e26 100644
--- a/tools/libs/gnttab/linux.c
+++ b/tools/libs/gnttab/linux.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#include 
+
 #include "private.h"
 
 #define DEVXEN "/dev/xen/"
@@ -244,63 +246,63 @@ int osdep_gnttab_grant_copy(xengnttab_handle *xgt,
 int fd = xgt->fd;
 struct ioctl_gntdev_grant_copy copy;
 
-XENGNTTAB_BUILD_BUG_ON(sizeof(struct ioctl_gntdev_grant_copy_segment) !=
-   sizeof(xengnttab_grant_copy_segment_t));
-
-XENGNTTAB_BUILD_BUG_ON(__alignof__(struct ioctl_gntdev_grant_copy_segment) 
!=
-   __alignof__(xengnttab_grant_copy_segment_t));
-
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-source.virt) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-source.virt));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-source.foreign) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-source.foreign));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-source.foreign.ref) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-source.foreign));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-source.foreign.offset) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-source.foreign.offset));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-source.foreign.domid) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-source.foreign.domid));
-
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-dest.virt) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-dest.virt));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-dest.foreign) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-dest.foreign));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-dest.foreign.ref) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-dest.foreign));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-dest.foreign.offset) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-dest.foreign.offset));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-dest.foreign.domid) !=
-   offsetof(xengnttab_grant_copy_segment_t,
-dest.foreign.domid));
-
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-len) !=
-   offsetof(xengnttab_grant_copy_segment_t, len));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-flags) !=
-   offsetof(xengnttab_grant_copy_segment_t, flags));
-XENGNTTAB_BUILD_BUG_ON(offsetof(struct ioctl_gntdev_grant_copy_segment,
-status) !=
-   offsetof(xengnttab_grant_copy_segment_t, 

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

[Julien Grall]

Hi Edgar,

On 16/09/2016 18:17, Edgar E. Iglesias wrote:

On Fri, Sep 16, 2016 at 04:21:12PM +0200, Julien Grall wrote:

Hi Edgar,

On 07/09/2016 08:56, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Add support for describing normal non-cacheable memory.

Signed-off-by: Edgar E. Iglesias 
---
xen/arch/arm/p2m.c | 18 ++
xen/include/asm-arm/p2m.h  |  1 +
xen/include/asm-arm/page.h |  1 +
3 files changed, 20 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b648a9d..bfef77b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -282,6 +282,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
p2m_access_t a)
/* First apply type permissions */
switch ( t )
{
+case p2m_mem_nc:
case p2m_ram_rw:
e->p2m.xn = 0;
e->p2m.write = 1;
@@ -376,6 +377,23 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
p2m_access_t a)
e.p2m.sh = LPAE_SH_OUTER;
break;

+/*
+ * ARM ARM: Overlaying the shareability attribute (DDI
+ * 0406C.b B3-1376 to 1377)
+ *
+ * A memory region with a resultant memory type attribute of Normal,
+ * and a resultant cacheability attribute of Inner Non-cacheable,
+ * Outer Non-cacheable, must have a resultant shareability attribute
+ * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
+ *
+ * On ARMv8 sharability is ignored and explicitly treated as Outer


I know you copied it from mfn_to_xen_entry, but can we fixed the copy with:

s/sharability/shareability/


+ * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.


s/_/-/

Also I would like to see a spec reference for the ARMv8. I think it is the
note in D4-1788 ARM DDI 0487A.j.


+ */
+case p2m_mem_nc:
+e.p2m.mattr = MATTR_MEM_NC;
+e.p2m.sh = LPAE_SH_OUTER;
+break;
+
default:
e.p2m.mattr = MATTR_MEM;
e.p2m.sh = LPAE_SH_INNER;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 53c4d78..b012d50 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -93,6 +93,7 @@ typedef enum {
p2m_ram_ro, /* Read-only; writes are silently dropped */
p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
non-cacheable */
p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area cacheable */
+p2m_mem_nc, /* Read/write mapping of Non-cacheable Memory */


I find the name a bit confusing. Technically p2m_mem_nc is p2m_mmio_direct_c
version but non-cacheable.

I have got the feeling that the naming I used on a recent patch is not
correct. Because p2m_mmio_direct_nc is not doing what is expect (i.e mapping
non-cacheable). It maps with the device memory attribute.

Maybe we should rename p2m_mmio_direct_nc to p2m_mmio_direct_dev (because it
will use the device memory attribute) and then use p2m_mmio_direct_nc for
your purpose.

Any opinions?



Something that shows up after doing the rename and otherwise keeping the
patch is that we treat the XN bit differently for p2m_mmio_direct_nc
and p2m_mmio_direct_c.

Is there any reason why we can't allow execution for p2m_mmio_direct_c
mappings?
If so, perhaps that same reason also applies to p2m_mmio_direct_nc and
both should be non-executable.


I guess you mean your new p2m_mmio_direct_nc and not the current one. If 
so, I think it is more a safety. Until now, the p2m type was used to 
share ACPI tables which should not be executable.


I am not sure what would be the implication to unset the NX bit by 
default. The question to answer before any relaxation is could a 
potential misbehave guest harm the platform?


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[George Dunlap]

On 07/09/16 10:12, Razvan Cojocaru wrote:
> Currently it is only possible to set mem_access restrictions only for
> a contiguous range of GFNs (or, as a particular case, for a single GFN).
> This patch introduces a new libxc function taking an array of GFNs.
> The alternative would be to set each page in turn, using a userspace-HV
> roundtrip for each call, and triggering a TLB flush per page set.
> 
> Signed-off-by: Razvan Cojocaru 
> Acked-by: Wei Liu 

Looks good:

Acked-by: George Dunlap 

> 
> ---
> Changes since V3:
>  - Fixed ARM compilation (replaced ENOTSUP with EOPNOTSUPP, which is
>#defined in the in-tree errno.h). The multi code remains
>unimplemented for ARM (it depends on " [RFC 21/22] xen/arm: p2m:
>Re-implement p2m_set_mem_access using p2m_{set, get}_entry", and
>Julien Grall has gracefully accepted to defer implementation
>until after both patches go in).
>  - Reordered the xen/guest_access.h #include in p2m.c.
>  - Now passing a gfn_t to set_mem_access() instead of unsigned long.
>  - Removed the p2m prefix from p2m_xenmem_access_to_p2m_access().
>  - Switched from bool_t to bool.
>  - Moved the XENMEM_access_op case up with the other do-nothing
>XENMEM_* cases.
> ---
>  tools/libxc/include/xenctrl.h |   9 +++
>  tools/libxc/xc_mem_access.c   |  38 +++
>  xen/arch/arm/p2m.c|  10 +++
>  xen/arch/x86/mm/p2m.c | 150 
> --
>  xen/common/compat/memory.c|  23 +--
>  xen/common/mem_access.c   |  11 
>  xen/include/public/memory.h   |  14 +++-
>  xen/include/xen/p2m-common.h  |   6 ++
>  xen/include/xlat.lst  |   2 +-
>  9 files changed, 224 insertions(+), 39 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 560ce7b..5e685a6 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2126,6 +2126,15 @@ int xc_set_mem_access(xc_interface *xch, domid_t 
> domain_id,
>uint32_t nr);
>  
>  /*
> + * Set an array of pages to their respective access in the access array.
> + * The nr parameter specifies the size of the pages and access arrays.
> + * The same allowed access types as for xc_set_mem_access() apply.
> + */
> +int xc_set_mem_access_multi(xc_interface *xch, domid_t domain_id,
> +uint8_t *access, uint64_t *pages,
> +uint32_t nr);
> +
> +/*
>   * Gets the mem access for the given page (returned in access on success)
>   */
>  int xc_get_mem_access(xc_interface *xch, domid_t domain_id,
> diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
> index eee088c..9536635 100644
> --- a/tools/libxc/xc_mem_access.c
> +++ b/tools/libxc/xc_mem_access.c
> @@ -41,6 +41,44 @@ int xc_set_mem_access(xc_interface *xch,
>  return do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
>  }
>  
> +int xc_set_mem_access_multi(xc_interface *xch,
> +domid_t domain_id,
> +uint8_t *access,
> +uint64_t *pages,
> +uint32_t nr)
> +{
> +DECLARE_HYPERCALL_BOUNCE(access, nr, XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(uint64_t),
> + XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +int rc;
> +
> +xen_mem_access_op_t mao =
> +{
> +.op   = XENMEM_access_op_set_access_multi,
> +.domid= domain_id,
> +.access   = XENMEM_access_default + 1, /* Invalid value */
> +.pfn  = ~0UL, /* Invalid GFN */
> +.nr   = nr,
> +};
> +
> +if ( xc_hypercall_bounce_pre(xch, pages) ||
> + xc_hypercall_bounce_pre(xch, access) )
> +{
> +PERROR("Could not bounce memory for 
> XENMEM_access_op_set_access_multi");
> +return -1;
> +}
> +
> +set_xen_guest_handle(mao.pfn_list, pages);
> +set_xen_guest_handle(mao.access_list, access);
> +
> +rc = do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
> +
> +xc_hypercall_bounce_post(xch, access);
> +xc_hypercall_bounce_post(xch, pages);
> +
> +return rc;
> +}
> +
>  int xc_get_mem_access(xc_interface *xch,
>domid_t domain_id,
>uint64_t pfn,
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index b648a9d..5c5049f 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1836,6 +1836,16 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, 
> uint32_t nr,
>  return 0;
>  }
>  
> +long p2m_set_mem_access_multi(struct domain *d,
> +  const XEN_GUEST_HANDLE(const_uint64) pfn_list,
> +  const XEN_GUEST_HANDLE(const_uint8) 
> access_list,
> +  uint32_t nr, uint32_t start, uint32_t mask,
> + 

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder 
available to components other than hvmloader"):
> But we'd still have to deal with mk_dsdt.c which is where the second,
> larger, chunk of Lenovo patch went.

Right, sorry, I had misunderstood.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7, 4.6] libxl: do not assume Dom0 backend while getting nic info

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH for-4.7,4.6] libxl: do not assume Dom0 backend 
while getting nic info"):
> Marek Marczykowski-Górecki writes ("[PATCH for-4.7,4.6] libxl: do not assume 
> Dom0 backend while getting nic info"):
> > Fill backend_domid field based on backend path.
> 
> Thanks.  I've put this in my queue, which I'm processing now.  (That
> patch has been in master for a while now.)

I have backported this to 4.7 and 4.6.  It applies cleanly to 4.5 but
since the purpose is to enable driver domains, and 4.5 is very old
(out of bugfix support even), I don't propose to apply it there.

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

On 09/19/2016 11:30 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder 
> available to components other than hvmloader"):
>> _S5 object still exists but it's content has been modified by subsequent
>> non-Lenovo changes so I think we can not worry about lines 20-30.
>>
>> But lines 30-43 are still present in current code.
> Are we really having this much trouble over 13 lines ?  Do we have
> someone (who hasn't read the existing code) who could write 13 lines
> of DSDT ?

This is a bug fix (it implements section 5.8.1 of the spec, to be exact)
and presumably anyone with basic ASL knowledge would have been able to
write it.

But we'd still have to deal with mk_dsdt.c which is where the second,
larger, chunk of Lenovo patch went.

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 05/15] efi: create efi_enabled()

[Daniel Kiper]

On Mon, Sep 19, 2016 at 08:57:02AM -0600, Jan Beulich wrote:
> >>> On 19.09.16 at 16:27,  wrote:
> > On Mon, Sep 19, 2016 at 05:58:46AM -0600, Jan Beulich wrote:
> >> >>> On 12.09.16 at 22:18,  wrote:
> >> > --- a/xen/arch/x86/domain_page.c
> >> > +++ b/xen/arch/x86/domain_page.c
> >> > @@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
> >> >   * domain's page tables but current may point at another domain's
> > VCPU.
> >> >   * Return NULL as though current is not properly set up yet.
> >> >   */
> >> > -if ( efi_enabled && efi_rs_using_pgtables() )
> >> > +if ( efi_enabled(EFI_RS) && efi_rs_using_pgtables() )
> >>
> >> I think the efi_enabled() here is pointless now.
> >
> > Nope, it seems that Xen will blow up on BUG() in
> > xen/arch/x86/efi/stub.c:efi_rs_using_pgtables() if
> > compiler/linker cannot be used to build proper PE binary.
>
> Ah, true.
>
> > Of course we can change efi_rs_using_pgtables() to
> > return false in such case.
>
> Except that it does already. You mean dropping the BUG() I guess.

Yep, right. However, should not we change "return 0" to "return false"
in the same patch if efi_rs_using_pgtables() returns bool_t?

> Both ways should be fine then for now.

Dropping the BUG() from efi_rs_using_pgtables() and efi_enabled in
above mentioned conditional makes final code, IMO, better. However,
in this patch context it may look a bit strange. Is it acceptable
for you to do both in this patch?

> > By the way, do you see this patch series (as whole or
> > at least partially) in 4.8? Should I repost them before
> > hard freeze? However, I am not sure that it (v7) can be
> > taken into 4.8 because we are after last posting date.
> >
> > Wei, Jan, what is your standing in that case?
>
> We're not past that point afaik - we're past the last-posting-of-
> new-stuff date.

Thanks for clarification guys.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools: lift BUILD_BUG_ON to a tools header file

[Ian Jackson]

Wei Liu writes ("[PATCH] tools: lift BUILD_BUG_ON to a tools header file"):
> Only define BUILD_BUG_ON when there isn't one already, because mini-os
> currently leaks that.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Paulina Szubarczyk 
> 
> This is a patch taken out of my branch to clean up some build system
> issues. It is still a bit ugly because BUILD_BUG_ON is conditionally
> defined to work around mini-os leaking BUILD_BUG_ON.

Thanks!

Acked-by: Ian Jackson 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

[Daniel Kiper]

On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
> >>> On 12.09.16 at 22:18,  wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -520,6 +520,8 @@ static void noinline init_done(void)
> >
> >  system_state = SYS_STATE_active;
> >
> > +free_ebmalloc_unused_mem();
>
> Now that the allocator properly lives in common code, this appears
> to lack an ARM side counterpart.

Why? It is called only from xen/arch/x86/setup.c:__start_xen() and all
ebmalloc stuff is in #ifndef CONFIG_ARM. So, free_ebmalloc_unused_mem()
will be needed only if we add ARM support here.

[...]

> > +static unsigned long __initdata ebmalloc_allocated;
> > +
> > +/* EFI boot allocator. */
> > +static void __init *ebmalloc(size_t size)
> > +{
> > +void *ptr = ebmalloc_mem + ebmalloc_allocated;
> > +
> > +ebmalloc_allocated += (size + sizeof(void *) - 1) & 
> > ~((typeof(size))sizeof(void *) - 1);
>
> What's the point of this ugly cast?

In general ALIGN_UP() would be nice here. However, there is no such thing
in Xen headers (or I cannot find it). Should I add one? As separate patch?

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] per-domain logging

[Ian Jackson]

Cedric Bosdonnat writes ("Re: [Xen-devel] per-domain logging"):
> On Thu, 2016-09-15 at 16:11 +0100, Wei Liu wrote:
> > IIRC there is already logfile abstraction inside libvirt -- can you just
> > pass in a libvirt logfile fd and try to demux there?
> 
> The abstraction we have is something similar to the XenToolLogger,
> not something abstracting the log files. Even if we had that, how
> could we demux since there is no domain name in the libxl messages.

Right.

It's not trivial to change the xtl API because there is no
negotiation, just a vops structure.  I can think of a way to do it,
but do we want to make all xtl logger users (that is, all generators
of log messages) pass a domid ?

Do we want to extend this to other information ?  (Not sure _what_
other information.)

Alternatively, we could have libxl (and perhaps libxc) put the domid
in a standard format in the message, so it could be extracted ?

However we do it, we would have to add a domid to every LOG call in
libxl.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder 
available to components other than hvmloader"):
> _S5 object still exists but it's content has been modified by subsequent
> non-Lenovo changes so I think we can not worry about lines 20-30.
> 
> But lines 30-43 are still present in current code.

Are we really having this much trouble over 13 lines ?  Do we have
someone (who hasn't read the existing code) who could write 13 lines
of DSDT ?

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 09/15] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 19.09.16 at 17:18,  wrote:
> On Mon, Sep 19, 2016 at 06:29:55AM -0600, Jan Beulich wrote:
>> >>> On 12.09.16 at 22:18,  wrote:
>> > --- a/xen/arch/x86/efi/stub.c
>> > +++ b/xen/arch/x86/efi/stub.c
>> > @@ -3,6 +3,43 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +/*
>> > + * Here we are in EFI stub. EFI calls are not supported due to lack
>> > + * of relevant functionality in compiler and/or linker.
>> > + *
>> > + * efi_multiboot2() is an exception. Please look below for more details.
>> > + */
>> > +
>> > +paddr_t __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle, 
>> > EFI_SYSTEM_TABLE *SystemTable)
>>
>> Long line.
>>
>> > +{
>> > +CHAR16 *err = L"Xen does not have EFI code build in!!!\r\nSystem 
>> > halted!!!\r\n";
>> > +SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;
>> > +
>> > +StdErr = SystemTable->StdErr ? SystemTable->StdErr : 
>> > SystemTable->ConOut;
>> > +
>> > +/*
>> > + * Print error message and halt the system.
>> > + *
>> > + * We have to open code MS x64 calling convention
>> > + * in assembly because here this convention is not
>> > + * directly supported by C compiler and/or linker.
>>
>> So how can lack of calling convention support be due to missing
>> functionality in the linker? Please avoid such misleading comments:
>> Linker capabilities get probed solely for PE32+ output format
>> support. With the linker part dropped here,
> 
> The problem here is that we are not able to tell why stub.c is build.
> There is a chance that C compiler does not support MS x64 calling
> convention or linker is not able to emit PE32+ output or both. So,
> I think that we should say so. However, I can agree that comment
> can be improved.

The first comment (higher up, but still visible in context) already
mentions both compiler and linker. That's sufficient for the purpose
that you mention, imo. The second comment should be solely about
why this needs to be an asm(), and that has nothing to do with the
linker.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 19.09.16 at 17:04,  wrote:
> On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
>> >>> On 12.09.16 at 22:18,  wrote:
>> > --- a/xen/arch/x86/setup.c
>> > +++ b/xen/arch/x86/setup.c
>> > @@ -520,6 +520,8 @@ static void noinline init_done(void)
>> >
>> >  system_state = SYS_STATE_active;
>> >
>> > +free_ebmalloc_unused_mem();
>>
>> Now that the allocator properly lives in common code, this appears
>> to lack an ARM side counterpart.
> 
> Why? It is called only from xen/arch/x86/setup.c:__start_xen() and all
> ebmalloc stuff is in #ifndef CONFIG_ARM. So, free_ebmalloc_unused_mem()
> will be needed only if we add ARM support here.

Well, it being inside that conditional is part of the problem - there's
no apparent point for all of it to be. Arguably the one static function
may better be, as other workarounds to avoid the "unused"
compiler warning wouldn't be any better.

>> > +static unsigned long __initdata ebmalloc_allocated;
>> > +
>> > +/* EFI boot allocator. */
>> > +static void __init *ebmalloc(size_t size)
>> > +{
>> > +void *ptr = ebmalloc_mem + ebmalloc_allocated;
>> > +
>> > +ebmalloc_allocated += (size + sizeof(void *) - 1) & 
>> > ~((typeof(size))sizeof(void *) - 1);
>>
>> What's the point of this ugly cast?
> 
> In general ALIGN_UP() would be nice here. However, there is no such thing
> in Xen headers (or I cannot find it). Should I add one? As separate patch?

I understand what you want the expression for, but you didn't
answer my question. Or do you not realize that all this cast is
about is a strange way of converting an expression of type
size_t to type size_t?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] x86: add a user configurable Kconfig option for the EHCI debug port

[Derek Straka]

Julien,

On Mon, Sep 19, 2016 at 10:56 AM, Julien Grall  wrote:

> Hello,
>
> On 19/09/2016 16:51, Derek Straka wrote:
>
>> Allows for the conditional inclusion of EHCI debug port driver on the x86
>> platform rather than having it always enabled.
>>
>> The default configuration for the CONFIG_EHCI option remains 'y' on x86,
>> so the
>> behavior out of the box remains unchanged.  The addition of the option
>> allows
>> advanced users to enable/disable the inclusion of the EHCI debug port
>> driver.
>>
>> Signed-off-by: Derek Straka 
>> ---
>>  xen/drivers/char/Kconfig  |  5 +
>>  xen/drivers/char/Makefile |  2 +-
>>  xen/include/xen/serial.h  | 12 +---
>>  3 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
>> index 1d894a7..1c5400f 100644
>> --- a/xen/drivers/char/Kconfig
>> +++ b/xen/drivers/char/Kconfig
>> @@ -51,6 +51,11 @@ config HAS_SCIF
>>
>>  config HAS_EHCI
>> bool
>> +
>> +config EHCI
>> +   bool "EHCI debug port" if EXPERT = "y"
>> +   default y
>> +   depends on HAS_EHCI
>> help
>>   This selects the USB based EHCI debug port to be used as a
>> UART. If
>>   you have an x86 based system with USB, say Y.
>> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
>> index 0afadaf..40c193b 100644
>> --- a/xen/drivers/char/Makefile
>> +++ b/xen/drivers/char/Makefile
>> @@ -5,6 +5,6 @@ obj-$(CONFIG_HAS_PL011) += pl011.o
>>  obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
>>  obj-$(CONFIG_HAS_OMAP) += omap-uart.o
>>  obj-$(CONFIG_HAS_SCIF) += scif-uart.o
>> -obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
>> +obj-$(CONFIG_EHCI) += ehci-dbgp.o
>>  obj-$(CONFIG_ARM) += arm-uart.o
>>  obj-y += serial.o
>> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
>> index 46edff8..5c6cbe9 100644
>> --- a/xen/include/xen/serial.h
>> +++ b/xen/include/xen/serial.h
>> @@ -174,11 +174,17 @@ void ns16550_init(int index, struct
>> ns16550_defaults *defaults);
>>  static inline void ns16550_init(int index, struct ns16550_defaults
>> *defaults) {}
>>  #endif
>>
>> -void ehci_dbgp_init(void);
>> -void arm_uart_init(void);
>>
>
> Why did you move arm_uart_init? It does not seem related to this patch...
>
I moved the EHCI code above the arm_uart_init since ehci_dbgp_init preceded
the arm code originally, but I can certainly move the ECHI declarations
after if you'd prefer.

>
> -
>>  struct physdev_dbgp_op;
>> +
>> +#ifdef CONFIG_EHCI
>>  int dbgp_op(const struct physdev_dbgp_op *);
>> +void ehci_dbgp_init(void);
>> +#else
>> +static inline void ehci_dbgp_init(void) {}
>> +static inline int dbgp_op(const struct physdev_dbgp_op *op) { return 0; }
>> +#endif
>> +
>> +void arm_uart_init(void);
>>
>>  /* Baud rate was pre-configured before invoking the UART driver. */
>>  #define BAUD_AUTO (-1)
>>
>>
> Regards,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

[Ian Jackson]

Lars Kurth writes ("Re: [PATCH v2 3/3] Significant changes to decision making; 
some new roles and minor changes"):
> Almost everyone else has reviewed this series already: Jan, Stefano, Wei,
> Tim and I think Konrad.
> That leaves you and George amongst the committers: so I am not sure
> whether there is much point in doing so. But I am not against it.

I will review it as is, too, then.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 10/15] x86/boot: implement early command line parser in C

[Daniel Kiper]

On Mon, Sep 19, 2016 at 06:47:50AM -0600, Jan Beulich wrote:
> >>> On 12.09.16 at 22:18,  wrote:

[...]

> > --- a/xen/arch/x86/boot/trampoline.S
> > +++ b/xen/arch/x86/boot/trampoline.S
> > @@ -220,8 +220,22 @@ trampoline_boot_cpu_entry:
> >  /* Jump to the common bootstrap entry point. */
> >  jmp trampoline_protmode_entry
> >
> > +#include "video.h"
> > +
> > +.align  2
> > +.byte   0
>
> While this odd placement of the requested padding byte will fulfill
> the immediate purpose, please do it the originally requested more
> conventional way (putting it inside the structure and adding a
> respective field to the C representation). For someone wanting to
> add another field it'll then be far more obvious what to do without
> re-introducing mis-alignment.

OK, however, I am still thinking how to automatically synchronize C and
assembly early_boot_opts struct definitions or generate one from another.
This way we can avoid __packed attribute and probably do not care about
member alignments at all. Do you have an idea how to do that?

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 09/15] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Mon, Sep 19, 2016 at 06:29:55AM -0600, Jan Beulich wrote:
> >>> On 12.09.16 at 22:18,  wrote:
> > --- a/xen/arch/x86/efi/stub.c
> > +++ b/xen/arch/x86/efi/stub.c
> > @@ -3,6 +3,43 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*
> > + * Here we are in EFI stub. EFI calls are not supported due to lack
> > + * of relevant functionality in compiler and/or linker.
> > + *
> > + * efi_multiboot2() is an exception. Please look below for more details.
> > + */
> > +
> > +paddr_t __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle, 
> > EFI_SYSTEM_TABLE *SystemTable)
>
> Long line.
>
> > +{
> > +CHAR16 *err = L"Xen does not have EFI code build in!!!\r\nSystem 
> > halted!!!\r\n";
> > +SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;
> > +
> > +StdErr = SystemTable->StdErr ? SystemTable->StdErr : 
> > SystemTable->ConOut;
> > +
> > +/*
> > + * Print error message and halt the system.
> > + *
> > + * We have to open code MS x64 calling convention
> > + * in assembly because here this convention is not
> > + * directly supported by C compiler and/or linker.
>
> So how can lack of calling convention support be due to missing
> functionality in the linker? Please avoid such misleading comments:
> Linker capabilities get probed solely for PE32+ output format
> support. With the linker part dropped here,

The problem here is that we are not able to tell why stub.c is build.
There is a chance that C compiler does not support MS x64 calling
convention or linker is not able to emit PE32+ output or both. So,
I think that we should say so. However, I can agree that comment
can be improved.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/4] libxl: add HVM usb passthrough support

[George Dunlap]

On 19/09/16 13:40, Juergen Gross wrote:
> Add HVM usb passthrough support to libxl by using qemu's capability
> to emulate standard USB controllers.
> 
> A USB controller is added via qmp command to the emulated hardware
> when a usbctrl device of type DEVICEMODEL is requested. Depending on
> the requested speed the appropriate hardware type is selected. A host
> USB device can then be added to the emulated USB controller via qmp
> command.
> 
> Removing of the devices is done via qmp commands, too.
> 
> Signed-off-by: Juergen Gross 

Thanks Juergen!  That was a pretty great turn-around time. :-)

Overall everything looks reasonable, with just a few nits...

> ---
> V2: code style issues (Wei Liu)
> adding some assert()s (Wei Liu)
> split out libxl__device_usbctrl_del_xenstore() (Wei Liu)
> ---
>  tools/libxl/libxl_device.c |   3 +-
>  tools/libxl/libxl_usb.c| 397 
> +++--
>  tools/libxl/xl_cmdimpl.c   |   4 +-
>  3 files changed, 311 insertions(+), 93 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index f53f772..2acfb48 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -808,8 +808,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
> libxl__devices_remove_state *drs)
>  aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
>  aodev->dev = dev;
>  aodev->force = drs->force;
> -if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB ||
> -dev->backend_kind == LIBXL__DEVICE_KIND_QUSB)
> +if (dev->kind == LIBXL__DEVICE_KIND_VUSB)
>  libxl__initiate_device_usbctrl_remove(egc, aodev);
>  else
>  libxl__initiate_device_generic_remove(egc, aodev);
> diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
> index 2493464..09bfa24 100644
> --- a/tools/libxl/libxl_usb.c
> +++ b/tools/libxl/libxl_usb.c
> @@ -17,6 +17,7 @@
>  
>  #include "libxl_internal.h"
>  #include 
> +#include 
>  
>  #define USBBACK_INFO_PATH "/libxl/usbback"
>  
> @@ -43,12 +44,6 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
> uint32_t domid,
>  int rc;
>  libxl_domain_type domtype = libxl__domain_type(gc, domid);
>  
> -if (!usbctrl->version)
> -usbctrl->version = 2;
> -
> -if (!usbctrl->ports)
> -usbctrl->ports = 8;
> -
>  if (usbctrl->type == LIBXL_USBCTRL_TYPE_AUTO) {
>  if (domtype == LIBXL_DOMAIN_TYPE_PV) {
>  rc = usbback_is_loaded(gc);
> @@ -62,6 +57,71 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
> uint32_t domid,
>  }
>  }
>  
> +switch (usbctrl->type) {
> +case LIBXL_USBCTRL_TYPE_PV:
> +case LIBXL_USBCTRL_TYPE_QUSB:
> +if (!usbctrl->version)
> +usbctrl->version = 2;
> +if (usbctrl->version < 1 || usbctrl->version > 2) {
> +LOG(ERROR,
> +"USB version for paravirtualized devices must be 1 or 2");
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +if (!usbctrl->ports)
> +usbctrl->ports = 8;
> +if (usbctrl->ports < 1 || usbctrl->ports > USBIF_MAX_PORTNR) {
> +LOG(ERROR, "Number of ports for USB controller is limited to %u",
> +USBIF_MAX_PORTNR);
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +break;
> +case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
> +if (!usbctrl->version)
> +usbctrl->version = 2;
> +switch (usbctrl->version) {
> +case 1:
> +/* uhci controller in qemu has fixed number of ports. */
> +if (usbctrl->ports && usbctrl->ports != 2) {
> +LOG(ERROR,
> +"Number of ports for USB controller of version 1 is 
> always 2");
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +usbctrl->ports = 2;
> +break;
> +case 2:
> +/* ehci controller in qemu has fixed number of ports. */
> +if (usbctrl->ports && usbctrl->ports != 6) {
> +LOG(ERROR,
> +"Number of ports for USB controller of version 2 is 
> always 6");
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +usbctrl->ports = 6;
> +break;
> +case 3:
> +if (!usbctrl->ports)
> +usbctrl->ports = 8;
> +/* xhci controller in qemu supports up to 15 ports. */
> +if (usbctrl->ports > 15) {
> +LOG(ERROR,
> +"Number of ports for USB controller of version 3 is 
> limited to 15");
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +break;
> +default:
> +LOG(ERROR, "Illegal USB version");
> +rc = 

[Xen-devel] [PATCH] tools: lift BUILD_BUG_ON to a tools header file

[Wei Liu]

Only define BUILD_BUG_ON when there isn't one already, because mini-os
currently leaks that.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Paulina Szubarczyk 

This is a patch taken out of my branch to clean up some build system
issues. It is still a bit ugly because BUILD_BUG_ON is conditionally
defined to work around mini-os leaking BUILD_BUG_ON.

Either this patch or "[PATCH v2] libs/gnttab: introduce
XENGNTTAB_BUILD_BUG_ON" should be taken to unblock Paulina's work.
---
 tools/firmware/hvmloader/rombios.c |  1 +
 tools/firmware/hvmloader/smbios.c  |  1 +
 tools/firmware/hvmloader/util.h|  1 -
 tools/include/xen-tools/libs.h | 11 +++
 tools/libxc/xc_core_arm.c  |  4 +++-
 tools/libxc/xc_cpuid_x86.c | 15 ---
 tools/libxc/xc_dom_arm.c   |  3 ++-
 tools/libxc/xc_dom_bzimageloader.c |  4 +++-
 tools/libxc/xc_pm.c|  6 --
 tools/libxc/xc_private.h   |  7 ---
 tools/libxc/xc_sr_common.c | 24 +---
 tools/libxl/libxl_internal.h   |  8 
 tools/libxl/libxl_psr.c|  1 +
 13 files changed, 47 insertions(+), 39 deletions(-)
 create mode 100644 tools/include/xen-tools/libs.h

diff --git a/tools/firmware/hvmloader/rombios.c 
b/tools/firmware/hvmloader/rombios.c
index 9acf03f..1e853ec 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -31,6 +31,7 @@
 #include "option_rom.h"
 
 #include 
+#include 
 
 #define ROM_INCLUDE_ROMBIOS
 #define ROM_INCLUDE_VGABIOS
diff --git a/tools/firmware/hvmloader/smbios.c 
b/tools/firmware/hvmloader/smbios.c
index 210c7b0..0e61bd1 100644
--- a/tools/firmware/hvmloader/smbios.c
+++ b/tools/firmware/hvmloader/smbios.c
@@ -26,6 +26,7 @@
 #include "util.h"
 #include "hypercall.h"
 #include 
+#include 
 
 /* SBMIOS handle base values */
 #define SMBIOS_HANDLE_TYPE0   0x
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 0fb266e..94292d6 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -41,7 +41,6 @@ void __assert_failed(char *assertion, char *file, int line)
 void __bug(char *file, int line) __attribute__((noreturn));
 #define BUG() __bug(__FILE__, __LINE__)
 #define BUG_ON(p) do { if (p) BUG(); } while (0)
-#define BUILD_BUG_ON(p) ((void)sizeof(char[1 - 2 * !!(p)]))
 
 #define min_t(type,x,y) \
 ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
diff --git a/tools/include/xen-tools/libs.h b/tools/include/xen-tools/libs.h
new file mode 100644
index 000..9d8b4ab
--- /dev/null
+++ b/tools/include/xen-tools/libs.h
@@ -0,0 +1,11 @@
+#ifndef __XEN_TOOLS_LIBS__
+
+#ifndef BUILD_BUG_ON
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
+#define BUILD_BUG_ON(p) ({ _Static_assert(!(p), "!(" #p ")"); })
+#else
+#define BUILD_BUG_ON(p) ((void)sizeof(char[1 - 2 * !!(p)]))
+#endif
+#endif
+
+#endif /* __XEN_TOOLS_LIBS__ */
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
index d8570fd..362c1a7 100644
--- a/tools/libxc/xc_core_arm.c
+++ b/tools/libxc/xc_core_arm.c
@@ -19,6 +19,8 @@
 #include "xg_private.h"
 #include "xc_core.h"
 
+#include 
+
 int
 xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
   unsigned long pfn)
@@ -101,7 +103,7 @@ xc_core_arch_get_scratch_gpfn(xc_interface *xch, domid_t 
domid,
  * The Grant Table region space is not used until the guest is
  * booting. Use the first page for the scratch pfn.
  */
-XC_BUILD_BUG_ON(GUEST_GNTTAB_SIZE < XC_PAGE_SIZE);
+BUILD_BUG_ON(GUEST_GNTTAB_SIZE < XC_PAGE_SIZE);
 
 *gpfn = GUEST_GNTTAB_BASE >> XC_PAGE_SHIFT;
 
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index fbbac9e..de06b32 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -25,6 +25,7 @@
 #include "xc_private.h"
 #include "xc_bitops.h"
 #include 
+#include 
 
 enum {
 #define XEN_CPUFEATURE(name, value) X86_FEATURE_##name = value,
@@ -98,12 +99,12 @@ const uint32_t *xc_get_static_cpu_featuremask(
 hvm_hap[FEATURESET_NR_ENTRIES] = INIT_HVM_HAP_FEATURES,
 deep_features[FEATURESET_NR_ENTRIES] = INIT_DEEP_FEATURES;
 
-XC_BUILD_BUG_ON(ARRAY_SIZE(known) != FEATURESET_NR_ENTRIES);
-XC_BUILD_BUG_ON(ARRAY_SIZE(special) != FEATURESET_NR_ENTRIES);
-XC_BUILD_BUG_ON(ARRAY_SIZE(pv) != FEATURESET_NR_ENTRIES);
-XC_BUILD_BUG_ON(ARRAY_SIZE(hvm_shadow) != FEATURESET_NR_ENTRIES);
-XC_BUILD_BUG_ON(ARRAY_SIZE(hvm_hap) != FEATURESET_NR_ENTRIES);
-XC_BUILD_BUG_ON(ARRAY_SIZE(deep_features) != FEATURESET_NR_ENTRIES);
+BUILD_BUG_ON(ARRAY_SIZE(known) != FEATURESET_NR_ENTRIES);
+BUILD_BUG_ON(ARRAY_SIZE(special) != FEATURESET_NR_ENTRIES);
+BUILD_BUG_ON(ARRAY_SIZE(pv) != FEATURESET_NR_ENTRIES);
+BUILD_BUG_ON(ARRAY_SIZE(hvm_shadow) != FEATURESET_NR_ENTRIES);
+

Re: [Xen-devel] [PATCH v6 05/15] efi: create efi_enabled()

[Jan Beulich]

>>> On 19.09.16 at 16:27,  wrote:
> On Mon, Sep 19, 2016 at 05:58:46AM -0600, Jan Beulich wrote:
>> >>> On 12.09.16 at 22:18,  wrote:
>> > --- a/xen/arch/x86/domain_page.c
>> > +++ b/xen/arch/x86/domain_page.c
>> > @@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>> >   * domain's page tables but current may point at another domain's 
> VCPU.
>> >   * Return NULL as though current is not properly set up yet.
>> >   */
>> > -if ( efi_enabled && efi_rs_using_pgtables() )
>> > +if ( efi_enabled(EFI_RS) && efi_rs_using_pgtables() )
>>
>> I think the efi_enabled() here is pointless now.
> 
> Nope, it seems that Xen will blow up on BUG() in
> xen/arch/x86/efi/stub.c:efi_rs_using_pgtables() if
> compiler/linker cannot be used to build proper PE binary.

Ah, true.

> Of course we can change efi_rs_using_pgtables() to
> return false in such case.

Except that it does already. You mean dropping the BUG() I guess.
Both ways should be fine then for now.

> By the way, do you see this patch series (as whole or
> at least partially) in 4.8? Should I repost them before
> hard freeze? However, I am not sure that it (v7) can be
> taken into 4.8 because we are after last posting date.
> 
> Wei, Jan, what is your standing in that case?

We're not past that point afaik - we're past the last-posting-of-
new-stuff date.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel