[Xen-devel] [PATCH] tools: make FLASK utils build unconditional
The flask utilities only have dependencies on libxc so there's no downside to always building it. Distros and projects based on Xen can put these in a different package to not install them for all users. Prior to this change FLASK_ENABLE needed to be set at the top level to build the utilities and the tools/configure script would build the FLASK policy by default, but only if the utilities were built. This change makes item 3 from http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01796.html a happen by default. CC: Ian Jackson CC: Stefano Stabellini CC: Ian Campbell CC: Wei Liu Signed-off-by: Doug Goldstein --- tools/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/Makefile b/tools/Makefile index 9f74ac7..3f9289b 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -5,7 +5,7 @@ SUBDIRS-y := SUBDIRS-y += include SUBDIRS-y += libs SUBDIRS-y += libxc -SUBDIRS-$(FLASK_ENABLE) += flask +SUBDIRS-y += flask SUBDIRS-y += xenstore SUBDIRS-y += misc SUBDIRS-y += examples -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
On Fri, 2016-01-15 at 17:24 +, Andrew Cooper wrote: > On 15/01/16 17:15, Jan Beulich wrote: > > > > > On 15.01.16 at 18:06, wrote: > > > On Thu, 2016-01-14 at 16:27 +, Ian Jackson wrote: > > > > * I don't have a clear design proposal for the above but I think Doug > > > > can probably provide one. I'm hoping this is more a matter of > > > > thinking carefully than of extensive build system programming! > > > I think we should: > > > > > > 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I previously > > > didn't care about what path it was, but the usecase of having grub be able > > > to react to the config (see below) is a strong reason to have it in /boot > > > IMHO. Jan has said he won't veto such a change, AFAICT everyone else is > > > happy with it. > > > > > > 2) Assume that grub (specifically the patch in > > > http://savannah.gnu.org/bugs > > > /?43420 and as used by osstest today) will at some point be modified to > > > look at /boot/xenconfig-$version to decide whether to create an XSM entry > > > or not instead of the presence of /boot/xenpolicy-$version. This step > > > belongs here logically but chronologically could come much later since > > > osstest will do the right thing even if there is a spurious > > > /boot/xenpolicy-$version file (which is to say it will ignore the spurious > > > entry and boot the right thing). > > > > > > 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK policy > > > and > > > to always install both. Any related configure options can go away and we > > > no > > > longer need to worry about synchronising the configuration of the tools > > > and > > > xen trees, this is desirable because we would prefer to have one set of > > > tools which gracefully handles differing hypervisor configurations over > > > needing different sets of tools (FLASK+XSM was one of the few exceptions > > > to > > > that rule AFAICT). > > > > > > I think with this plan there is no need to modify osstest.git, since it > > > already does the right thing (which is, it sets XSM for Xen builds, which > > > in turn enables FLASK and it does nothing for tools/* which is correct > > > once > > > #3 above has happened). > > > > > > The only downside is a spurious /boot/xenpolicy-$version installed when > > > the > > > corresponding Xen binary doesn't support XSM, however given the assumption > > > in #2 (which implies the user will never see a spurious grub entry, which > > > is the important thing) and the fact that it avoids the complexity of > > > having tools/* rely in some way on xen/.config I think that is a > > > worthwhile > > > trade-off. > > > > > > Hopefully this simplifies a bunch of the arguments we have been having and > > > provides a path forwards? > > > > > > Objections? > > My opinion on 1 and 2 is known; 3 seems like a good step to me. > > FWIW, I also prefer option 3. It lends itself better to a toolstack > which functions in the same way, irrespective of hypervisor configuration. To be clear: These are not options, they are steps in a plan, to be followed in order. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 4/4] x86/PV: enable the emulated PIT
The HVMlite series removed the initialization of the emulated PIT for PV
guests, this patch re-enables it.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
---
NB: Since it's not clear why an emulated PIT is needed, it won't be enabled
by default for HVMlite guests until we can figure out if/why it's needed.
---
Changes since v2:
- Change 'if ( (a && b) || (!a && c) )' into 'if ( a ? b : c )'.
Changes since v1:
- New in this version.
---
tools/libxl/libxl_x86.c | 8 +++-
xen/arch/x86/domain.c | 5 +++--
xen/arch/x86/setup.c| 4 +++-
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..7f47cc5 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -13,8 +13,14 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
LIBXL_DEVICE_MODEL_VERSION_NONE) {
/* HVM domains with a device model. */
xc_config->emulation_flags = XEN_X86_EMU_ALL;
+} else if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV) {
+/* PV domains. */
+xc_config->emulation_flags = XEN_X86_EMU_PIT;
} else {
-/* PV or HVM domains without a device model. */
+assert(d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM);
+assert(d_config->b_info.device_model_version ==
+ LIBXL_DEVICE_MODEL_VERSION_NONE);
+/* HVMlite domains. */
xc_config->emulation_flags = 0;
}
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 159d960..ae85e45 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -542,8 +542,9 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
d->domain_id, config->emulation_flags);
return -EINVAL;
}
-if ( config->emulation_flags != 0 &&
- (!is_hvm_domain(d) || config->emulation_flags != XEN_X86_EMU_ALL)
)
+if ( is_hvm_domain(d) ? (config->emulation_flags != XEN_X86_EMU_ALL &&
+ config->emulation_flags != 0) :
+ (config->emulation_flags != 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",
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 76c7b0f..08bd3fb 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -582,7 +582,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
.parity= 'n',
.stop_bits = 1
};
-struct xen_arch_domainconfig config = { .emulation_flags = 0 };
+struct xen_arch_domainconfig config = {
+.emulation_flags = XEN_X86_EMU_PIT,
+};
/* Critical region without IDT or TSS. Any fault is deadly! */
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote:
> On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote:
> > So smp_mb() provides transitivity, as do pairs of smp_store_release()
> > and smp_read_acquire(),
>
> But they provide different grades of transitivity, which is where all
> the confusion lays.
>
> smp_mb() is strongly/globally transitive, all CPUs will agree on the order.
>
> Whereas the RCpc release+acquire is weakly so, only the two cpus
> involved in the handover will agree on the order.
Good point!
Using grace periods in place of smp_mb() also provides strong/global
transitivity, but also insanely high latencies. ;-)
The patch below updates Documentation/memory-barriers.txt to define
local vs. global transitivity. The corresponding ppcmem litmus test
is included below as well.
Should we start putting litmus tests for the various examples
somewhere, perhaps in a litmus-tests directory within each participating
architecture? I have a pile of powerpc-related litmus tests on my laptop,
but they probably aren't doing all that much good there.
Thanx, Paul
PPC local-transitive
""
{
0:r1=1; 0:r2=u; 0:r3=v; 0:r4=x; 0:r5=y; 0:r6=z;
1:r1=1; 1:r2=u; 1:r3=v; 1:r4=x; 1:r5=y; 1:r6=z;
2:r1=1; 2:r2=u; 2:r3=v; 2:r4=x; 2:r5=y; 2:r6=z;
3:r1=1; 3:r2=u; 3:r3=v; 3:r4=x; 3:r5=y; 3:r6=z;
}
P0 | P1 | P2 | P3 ;
lwz r9,0(r4) | lwz r9,0(r5) | lwz r9,0(r6) | stw r1,0(r3) ;
lwsync | lwsync | lwsync | sync ;
stw r1,0(r2) | lwz r8,0(r3) | stw r1,0(r7) | lwz r9,0(r2) ;
lwsync | lwz r7,0(r2) | | ;
stw r1,0(r5) | lwsync | | ;
| stw r1,0(r6) | | ;
exists
(* (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r8=0 /\ 3:r9=0) *)
(* (0:r9=1 /\ 1:r9=1 /\ 2:r9=1) *)
(* (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r7=0) *)
(0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r7=0)
commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
Author: Paul E. McKenney
Date: Fri Jan 15 09:30:42 2016 -0800
documentation: Distinguish between local and global transitivity
The introduction of smp_load_acquire() and smp_store_release() had
the side effect of introducing a weaker notion of transitivity:
The transitivity of full smp_mb() barriers is global, but that
of smp_store_release()/smp_load_acquire() chains is local. This
commit therefore introduces the notion of local transitivity and
gives an example.
Reported-by: Peter Zijlstra
Reported-by: Will Deacon
Signed-off-by: Paul E. McKenney
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index c66ba46d8079..d8109ed99342 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1318,8 +1318,82 @@ or a level of cache, CPU 2 might have early access to
CPU 1's writes.
General barriers are therefore required to ensure that all CPUs agree
on the combined order of CPU 1's and CPU 2's accesses.
-To reiterate, if your code requires transitivity, use general barriers
-throughout.
+General barriers provide "global transitivity", so that all CPUs will
+agree on the order of operations. In contrast, a chain of release-acquire
+pairs provides only "local transitivity", so that only those CPUs on
+the chain are guaranteed to agree on the combined order of the accesses.
+For example, switching to C code in deference to Herman Hollerith:
+
+ int u, v, x, y, z;
+
+ void cpu0(void)
+ {
+ r0 = smp_load_acquire(&x);
+ WRITE_ONCE(u, 1);
+ smp_store_release(&y, 1);
+ }
+
+ void cpu1(void)
+ {
+ r1 = smp_load_acquire(&y);
+ r4 = READ_ONCE(v);
+ r5 = READ_ONCE(u);
+ smp_store_release(&z, 1);
+ }
+
+ void cpu2(void)
+ {
+ r2 = smp_load_acquire(&z);
+ smp_store_release(&x, 1);
+ }
+
+ void cpu3(void)
+ {
+ WRITE_ONCE(v, 1);
+ smp_mb();
+ r3 = READ_ONCE(u);
+ }
+
+Because cpu0(), cpu1(), and cpu2() participate in a local transitive
+chain of smp_store_release()/smp_load_acquire() pairs, the following
+outcome is prohibited:
+
+ r0 == 1 && r1 == 1 && r2 == 1
+
+Furthermore, because of the release-acquire relationship between cpu0()
+and cpu1(), cpu1() must see cpu0()'s writes, so that the following
+outcome is prohibited:
+
+ r1 == 1 && r5 == 0
+
+However, the transitivity of release-acquire is local to the participating
+CPUs and does not apply to cpu3(). Therefore, the following outcome
+is possible:
+
+ r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0
+
+Although cpu0(), cpu1
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote:
> > > So smp_mb() provides transitivity, as do pairs of smp_store_release()
> > > and smp_read_acquire(),
> >
> > But they provide different grades of transitivity, which is where all
> > the confusion lays.
> >
> > smp_mb() is strongly/globally transitive, all CPUs will agree on the order.
> >
> > Whereas the RCpc release+acquire is weakly so, only the two cpus
> > involved in the handover will agree on the order.
>
> And the stuff we're confused about is how best to express the difference
> and guarantees of these two forms of transitivity and how exactly they
> interact.
Hoping my memory-barrier.txt patch helps here...
> And smp_load_acquire()/smp_store_release() are RCpc because TSO archs
> and PPC. the atomic*_{acquire,release}() are RCpc because PPC and
> LOCK,UNLOCK are similarly RCpc because of PPC.
>
> Now we'd like PPC to stick a SYNC in either LOCK or UNLOCK so at least
> the locks are RCsc again, but they resist for performance reasons but
> waver because they don't want to be the ones finding all the nasty bugs
> because they're the only one.
I believe that the relevant proverb said something about starving to
death between two bales of hay... ;-)
> Now the thing I worry about, and still have not had an answer to is if
> weakly ordered MIPS will end up being RCsc or RCpc for their locks if
> they get implemented with SYNC_ACQUIRE and SYNC_RELEASE instead of the
> current SYNC.
It would be good to have better clarity on this, no two ways about it.
Thanx, Paul
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote:
> On Thu, Jan 14, 2016 at 02:55:10PM -0800, Paul E. McKenney wrote:
> > On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote:
> > > On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
> > > >
> > > >>On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
> > > >>>
> > > >>>The WRC+addr+addr is OK because data dependencies are not required to
> > > >>>be
> > > >>>transitive, in other words, they are not required to flow from one CPU
> > > >>>to
> > > >>>another without the help of an explicit memory barrier.
> > > >>I don't see any reliable way to fit WRC+addr+addr into "DATA
> > > >>DEPENDENCY BARRIERS" section recommendation to have data dependency
> > > >>barrier between read of a shared pointer/index and read the shared
> > > >>data based on that pointer. If you have this two reads, it doesn't
> > > >>matter the rest of scenario, you should put the dependency barrier
> > > >>in code anyway. If you don't do it in WRC+addr+addr scenario then
> > > >>after years it can be easily changed to different scenario which
> > > >>fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
> > > >>fails.
> > > >The trick is that lockless_dereference() contains an
> > > >smp_read_barrier_depends():
> > > >
> > > >#define lockless_dereference(p) \
> > > >({ \
> > > > typeof(p) _p1 = READ_ONCE(p); \
> > > > smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> > > > (_p1); \
> > > >})
> > > >
> > > >Or am I missing your point?
> > >
> > > WRC+addr+addr has no any barrier. lockless_dereference() has a
> > > barrier. I don't see a common points between this and that in your
> > > answer, sorry.
> >
> > Me, I am wondering what WRC+addr+addr has to do with anything at all.
>
> See my earlier reply [1] (but also, your WRC Linux example looks more
> like a variant on WWC and I couldn't really follow it).
I will revisit my WRC Linux example. And yes, creating litmus tests
that use non-fake dependencies is still a bit of an undertaking. :-/
I am sure that it will seem more natural with time and experience...
> >
> >
> > OK, so it looks like Will was asking not about WRC+addr+addr, but instead
> > about WRC+sync+addr. This would drop an smp_mb() into cpu2() in my
> > earlier example, which needs to provide ordering.
> >
> > I am guessing that the manual's "Older instructions which must be globally
> > performed when the SYNC instruction completes" provides the equivalent
> > of ARM/Power A-cumulativity, which can be thought of as transitivity
> > backwards in time.
>
> I couldn't make that leap. In particular, the manual's "Detailed
> Description" sections explicitly refer to program-order:
>
> Every synchronizable specified memory instruction (loads or stores or
> both) that occurs in the instruction stream before the SYNC
> instruction must reach a stage in the load/store datapath after which
> no instruction re-ordering is possible before any synchronizable
> specified memory instruction which occurs after the SYNC instruction
> in the instruction stream reaches the same stage in the load/store
> datapath.
>
> Will
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399765.html
All good points. I think we all agree that the MIPS documentation could
use significant help. And given that I work for the company that produced
the analogous documentation for PowerPC, that is saying something. ;-)
We simply can't know if MIPS's memory ordering is sufficient for the
Linux kernel given its current implementation of the ordering primitives
and its current documentation.
I feel a bit better than I did earlier due to Leonid's response to my
earlier litmus-test examples. But I do recommend some serious stress
testing of MIPS on a good set of litmus tests. Much nicer finding issues
that way than as random irreproducible strange behavior!
Thanx, Paul
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 10/11] dma: rename dma_*_writecombine() to dma_*_wc()
On Tue, Aug 25, 2015 at 9:21 PM, Ingo Molnar wrote: > > * Andrew Morton wrote: > >> > There's a catch-22 issue here either way, for instance this rename patch >> > has >> > been being baked for probably 2 releases already but the difficulty has >> > been >> > trying to find the appropriate time to merge it without conflict. >> > >> > If you do it in the beginning of the merge window, you have to ask >> > yourself in >> > what tree it will be done. Since subsystems are topic specific that means >> > that >> > subsystem will end up having a conflict at the end of the merge window. >> >> Yes it's a special case. I think the best way of handling such things is to >> get >> them in to Linus either right at the end of the merge window or the day >> after he >> releases -rc1. This is when most people's trees are mostly empty. > > Yes, that was the plan last time around as well - but the end of the merge > window > is when we have the least maintainer bandwidth as well ... > > Anyway, I applied most of the patches (sans the rename), so the rename patch > should be a lot simpler to execute at the right moment this time around. Ingo, should we try this again some time? I have some ideas on how to make these sorts of changes easier to manage in the future, it involves having an automatic git rebase option to use Coccinelle for you if a patch is annotated to have been completely done with Coccinelle, but future tooling is needed for that [0]. In the meantime I (or you) can simply run the script at any point in time to catch all the names as-is in the kernel / point in time we decide to merge this simple rename. [0] http://kernelnewbies.org/KernelProjects/linux-oven Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [BUG] Xen Remus, DRBD Protocol D and old Linux kernels
Good evening, people. More than a bug, it's an issue, a big one IMO. Even though information on the Remus project and its implementation is kind of scarce on the internet and is usually outdated (the project could use some love on that side of things, though it seems that on the coding side, it's still being properly maintained), there's a huge problem in the current implementation: its storage depends on a custom patch developed for a very old version of DRBD. Currently, the wiki points that in order to use Remus you must use it with a custom version of DRBD, forked from 8.3.11 (and there's also a patch for 8.3.9). Support for these versions have been dropped for almost 3 years, and they are only compatible with Linux kernels 3.0-3.4: most distros have already dropped these kernels and deleted them from their repositories: even kernel.org plans to drop support for the 3.4 kernel in September this year. Building your own is an unnecessary hassle. These problems make Remus practically unusable, despite being one of the coolest features Xen has in my honest opinion. This issue has also been brought up at least once on the DRBD mailing list[1] and until there's more cooperation between the Xen project and LINBIT to develop a more robust Protocol D, they've refused to pull the patch into their tree to be maintained. It's worth noting that the "official" patch (by rshiriam) is somewhat simple[2][3]. A solution to this for the short term would be to port the patch to the current DRBD version (8.4.7-1) and in the long term, to collaborate with LINBIT so the Xen project doesn't have to maintain their own downstream changes, and we benefit from LINBIT's experience on realiable storage. The short term solution seems like a very quick one, since the original patch is small-ish, and I've been trying to do it[4] but simply C isn't my strong suit and I don't know much of DRBD's source, even after doing a cursory reading of it. I know this is an open source project and thus most developers are volunteers, but this kind of issue really is a show-stopper that keeps me (and presumably many other people) from using the awesome feature that Remus is. [1]: http://lists.linbit.com/pipermail/drbd-user/2013-October/020370.html [2]: http://remusha.wdfiles.com/local--files/configuring-and-installing-remus/drbd-8.3.9-remus.patch [3]: https://github.com/macrosheep/remus-drbd/commit/2685b294f5b416d827bdf446a69c88ab04df50dd [4]: https://github.com/superpatosainz/remus-drbd -- Pato Sáinz - @superpatosainz ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On 01/15/2016 01:57 AM, Will Deacon wrote: Paul, I think you figured this out while I was sleeping, but just to confirm: 1. The MIPS64 ISA doc [1] talks about SYNC in a way that applies only to memory accesses appearing in *program-order* before the SYNC 2. We need WRC+sync+addr to work, which means that the SYNC in P1 must also capture the store in P0 as being "before" the barrier. Leonid reckons it works, but his explanation [2] focussed on the address dependency in P2 as to why this works. If that is the case (i.e. address dependency provides global transitivity), then WRC+addr+addr should also work (even though its not required). No, it is not correct. There is one old design which provides access to core (thread0 + thread1) write-buffers for threads load in advance of it is visible to other cores. It means, that WRC+sync+addr passes because of SYNC in write thread and register dependency inside other thread but WRC+addr+addr may fail because other core may get a stale data. 3. It seems that WRC+addr+addr doesn't work, so I'm still suspicious about WRC+sync+addr, because neither the architecture document or Leonid's explanation tell me that it should be forbidden. Will [1] https://imgtec.com/?do-download=4302 [2] http://lkml.kernel.org/r/569565da.2010...@imgtec.com (scroll to the end) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote:
> > On Thu, Jan 14, 2016 at 02:55:10PM -0800, Paul E. McKenney wrote:
> > > On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote:
> > > > On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
> > > > >
> > > > >>On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
> > > > >>>
> > > > >>>The WRC+addr+addr is OK because data dependencies are not required
> > > > >>>to be
> > > > >>>transitive, in other words, they are not required to flow from one
> > > > >>>CPU to
> > > > >>>another without the help of an explicit memory barrier.
> > > > >>I don't see any reliable way to fit WRC+addr+addr into "DATA
> > > > >>DEPENDENCY BARRIERS" section recommendation to have data dependency
> > > > >>barrier between read of a shared pointer/index and read the shared
> > > > >>data based on that pointer. If you have this two reads, it doesn't
> > > > >>matter the rest of scenario, you should put the dependency barrier
> > > > >>in code anyway. If you don't do it in WRC+addr+addr scenario then
> > > > >>after years it can be easily changed to different scenario which
> > > > >>fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
> > > > >>fails.
> > > > >The trick is that lockless_dereference() contains an
> > > > >smp_read_barrier_depends():
> > > > >
> > > > >#define lockless_dereference(p) \
> > > > >({ \
> > > > > typeof(p) _p1 = READ_ONCE(p); \
> > > > > smp_read_barrier_depends(); /* Dependency order vs. p above. */
> > > > > \
> > > > > (_p1); \
> > > > >})
> > > > >
> > > > >Or am I missing your point?
> > > >
> > > > WRC+addr+addr has no any barrier. lockless_dereference() has a
> > > > barrier. I don't see a common points between this and that in your
> > > > answer, sorry.
> > >
> > > Me, I am wondering what WRC+addr+addr has to do with anything at all.
> >
> > See my earlier reply [1] (but also, your WRC Linux example looks more
> > like a variant on WWC and I couldn't really follow it).
>
> I will revisit my WRC Linux example. And yes, creating litmus tests
> that use non-fake dependencies is still a bit of an undertaking. :-/
> I am sure that it will seem more natural with time and experience...
Hmmm... You are quite right, I did do WWC. I need to change cpu2()'s
last access from a store to a load to get WRC. Plus the levels of
indirection definitely didn't match up, did they?
struct foo {
struct foo *next;
};
struct foo a;
struct foo b;
struct foo c = { &a };
struct foo d = { &b };
struct foo x = { &c };
struct foo y = { &d };
struct foo *r1, *r2, *r3;
void cpu0(void)
{
WRITE_ONCE(x.next, &y);
}
void cpu1(void)
{
r1 = lockless_dereference(x.next);
WRITE_ONCE(r1->next, &x);
}
void cpu2(void)
{
r2 = lockless_dereference(y.next);
r3 = READ_ONCE(r2->next);
}
In this case, it is legal to end the run with:
r1 == &y && r2 == &x && r3 == &c
Please see below for a ppcmem litmus test.
So, did I get it right this time? ;-)
Thanx, Paul
PS. And yes, working through this does help me understand the
benefits of fake dependencies. Why do you ask? ;-)
PPC WRCnf+addrs
""
{
0:r2=x; 0:r3=y;
1:r2=x; 1:r3=y;
2:r2=x; 2:r3=y;
c=a; d=b; x=c; y=d;
}
P0 | P1| P2;
stw r3,0(r2) | lwz r8,0(r2) | lwz r8,0(r3) ;
| stw r2,0(r3) | lwz r9,0(r8) ;
exists
(1:r8=y /\ 2:r8=x /\ 2:r9=c)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't
put it on stack.
Some compilers (e.g. 5.2.1) complain:
drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’:
drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes
is larger than 1024 bytes [-Wframe-larger-than=]
Signed-off-by: Boris Ostrovsky
---
drivers/xen/gntdev.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index dc49538..43a2c1c 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -915,15 +915,19 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch
*batch,
static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
{
struct ioctl_gntdev_grant_copy copy;
- struct gntdev_copy_batch batch;
+ struct gntdev_copy_batch *batch;
unsigned int i;
int ret = 0;
if (copy_from_user(©, u, sizeof(copy)))
return -EFAULT;
- batch.nr_ops = 0;
- batch.nr_pages = 0;
+ batch = kmalloc(sizeof(*batch), GFP_KERNEL);
+ if (!batch)
+ return -ENOMEM;
+
+ batch->nr_ops = 0;
+ batch->nr_pages = 0;
for (i = 0; i < copy.count; i++) {
struct gntdev_grant_copy_segment seg;
@@ -933,18 +937,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv
*priv, void __user *u)
goto out;
}
- ret = gntdev_grant_copy_seg(&batch, &seg,
©.segments[i].status);
+ ret = gntdev_grant_copy_seg(batch, &seg,
+ ©.segments[i].status);
if (ret < 0)
goto out;
cond_resched();
}
- if (batch.nr_ops)
- ret = gntdev_copy(&batch);
+ if (batch->nr_ops)
+ ret = gntdev_copy(batch);
return ret;
out:
- gntdev_put_pages(&batch);
+ gntdev_put_pages(batch);
+ kfree(batch);
return ret;
}
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: make FLASK utils build unconditional
On 15/01/16 17:39, Doug Goldstein wrote: > The flask utilities only have dependencies on libxc so there's no > downside to always building it. Distros and projects based on Xen can > put these in a different package to not install them for all users. > Prior to this change FLASK_ENABLE needed to be set at the top level to > build the utilities and the tools/configure script would build the FLASK > policy by default, but only if the utilities were built. > > This change makes item 3 from > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01796.html > a happen by default. > > CC: Ian Jackson > CC: Stefano Stabellini > CC: Ian Campbell > CC: Wei Liu > Signed-off-by: Doug Goldstein Reviewed-by: Andrew Cooper > --- > tools/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/Makefile b/tools/Makefile > index 9f74ac7..3f9289b 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -5,7 +5,7 @@ SUBDIRS-y := > SUBDIRS-y += include > SUBDIRS-y += libs > SUBDIRS-y += libxc > -SUBDIRS-$(FLASK_ENABLE) += flask > +SUBDIRS-y += flask > SUBDIRS-y += xenstore > SUBDIRS-y += misc > SUBDIRS-y += examples ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
On 15/01/16 19:43, Boris Ostrovsky wrote:
> struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't
> put it on stack.
>
> Some compilers (e.g. 5.2.1) complain:
> drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’:
> drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes
> is larger than 1024 bytes [-Wframe-larger-than=]
>
> Signed-off-by: Boris Ostrovsky
> ---
> drivers/xen/gntdev.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index dc49538..43a2c1c 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -915,15 +915,19 @@ static int gntdev_grant_copy_seg(struct
> gntdev_copy_batch *batch,
> static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
> {
> struct ioctl_gntdev_grant_copy copy;
> - struct gntdev_copy_batch batch;
> + struct gntdev_copy_batch *batch;
> unsigned int i;
> int ret = 0;
>
> if (copy_from_user(©, u, sizeof(copy)))
> return -EFAULT;
>
> - batch.nr_ops = 0;
> - batch.nr_pages = 0;
> + batch = kmalloc(sizeof(*batch), GFP_KERNEL);
> + if (!batch)
> + return -ENOMEM;
> +
> + batch->nr_ops = 0;
> + batch->nr_pages = 0;
>
> for (i = 0; i < copy.count; i++) {
> struct gntdev_grant_copy_segment seg;
> @@ -933,18 +937,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv
> *priv, void __user *u)
> goto out;
> }
>
> - ret = gntdev_grant_copy_seg(&batch, &seg,
> ©.segments[i].status);
> + ret = gntdev_grant_copy_seg(batch, &seg,
> + ©.segments[i].status);
> if (ret < 0)
> goto out;
>
> cond_resched();
> }
> - if (batch.nr_ops)
> - ret = gntdev_copy(&batch);
> + if (batch->nr_ops)
> + ret = gntdev_copy(batch);
You presumably want a kfree() here?
> return ret;
>
>out:
> - gntdev_put_pages(&batch);
> + gntdev_put_pages(batch);
> + kfree(batch);
> return ret;
> }
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
On 01/15/2016 02:50 PM, Andrew Cooper wrote: On 15/01/16 19:43, Boris Ostrovsky wrote: @@ -933,18 +937,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u) goto out; } - ret = gntdev_grant_copy_seg(&batch, &seg, ©.segments[i].status); + ret = gntdev_grant_copy_seg(batch, &seg, + ©.segments[i].status); if (ret < 0) goto out; cond_resched(); } - if (batch.nr_ops) - ret = gntdev_copy(&batch); + if (batch->nr_ops) + ret = gntdev_copy(batch); You presumably want a kfree() here? Ah, missed it. Thanks. return ret; ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1 net] xen-netfront: request Tx response events more often
From: David Vrabel Date: Fri, 15 Jan 2016 11:56:42 + > @@ -364,6 +364,7 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue) > RING_IDX cons, prod; > unsigned short id; > struct sk_buff *skb; > + int more_to_do; I hate to be difficult, but could you please use 'bool' for this variable? Thanks! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't
put it on stack.
Some compilers (e.g. 5.2.1) complain:
drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’:
drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes
is larger than 1024 bytes [-Wframe-larger-than=]
Signed-off-by: Boris Ostrovsky
---
v2: Missed kfree on non-error path
drivers/xen/gntdev.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index dc49538..6a5a6ef 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -915,15 +915,19 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch
*batch,
static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
{
struct ioctl_gntdev_grant_copy copy;
- struct gntdev_copy_batch batch;
+ struct gntdev_copy_batch *batch;
unsigned int i;
int ret = 0;
if (copy_from_user(©, u, sizeof(copy)))
return -EFAULT;
- batch.nr_ops = 0;
- batch.nr_pages = 0;
+ batch = kmalloc(sizeof(*batch), GFP_KERNEL);
+ if (!batch)
+ return -ENOMEM;
+
+ batch->nr_ops = 0;
+ batch->nr_pages = 0;
for (i = 0; i < copy.count; i++) {
struct gntdev_grant_copy_segment seg;
@@ -933,18 +937,22 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv
*priv, void __user *u)
goto out;
}
- ret = gntdev_grant_copy_seg(&batch, &seg,
©.segments[i].status);
+ ret = gntdev_grant_copy_seg(batch, &seg,
+ ©.segments[i].status);
if (ret < 0)
goto out;
cond_resched();
}
- if (batch.nr_ops)
- ret = gntdev_copy(&batch);
+ if (batch->nr_ops)
+ ret = gntdev_copy(batch);
+
+ kfree(batch);
return ret;
out:
- gntdev_put_pages(&batch);
+ gntdev_put_pages(batch);
+ kfree(batch);
return ret;
}
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 0/3 net] xen-netback: use skb to determine number of required (etc.)
From: David Vrabel Date: Fri, 15 Jan 2016 14:55:33 + > "xen-netback: use skb to determine number of required" plus two other > minor fixes I found down the back of the sofa. Series applied, thanks David. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 38642: tolerable FAIL
This run is configured for baseline tests only. flight 38642 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38642/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 38638 test-amd64-amd64-xl 19 guest-start/debian.repeatfail like 38638 test-amd64-amd64-pygrub 18 guest-start/debian.repeatfail like 38638 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 38638 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-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-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail 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 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuuf02ccf53693758b65843264e077f90cf295e7d98 baseline version: qemuu91728bda76c1bfe49ac680af763154ec51988732 Last test of basis38638 2016-01-15 01:55:10 Z0 days Testing same since38642 2016-01-15 11:53:41 Z0 days1 attempts People who touched revisions under test: Alex Bennée Amit Shah Bharata B Rao Cao jin Christian Borntraeger Cornelia Huck David Hildenbrand Fam Zheng Halil Pasic Jason J. Herne Markus Armbruster Markus Armbruster Peter Maydell Pierre Morel Shmulik Ladkani Yi Min Zhao 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 fail test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd6
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > > And the stuff we're confused about is how best to express the difference > > and guarantees of these two forms of transitivity and how exactly they > > interact. > > Hoping my memory-barrier.txt patch helps here... Yes, that seems a good start. But yesterday you raised the 'fun' point of two globally ordered sequences connected by a single local link. And I think I'm still confused on LWSYNC (in the smp_wmb case) when one of the stores looses a conflict, and if that scenario matters. If it does, we should inspect the same case for other barriers. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > Should we start putting litmus tests for the various examples > somewhere, perhaps in a litmus-tests directory within each participating > architecture? I have a pile of powerpc-related litmus tests on my laptop, > but they probably aren't doing all that much good there. Yeah, or a version of them in C that we can 'compile'? > > commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41 > Author: Paul E. McKenney > Date: Fri Jan 15 09:30:42 2016 -0800 > > documentation: Distinguish between local and global transitivity > > The introduction of smp_load_acquire() and smp_store_release() had > the side effect of introducing a weaker notion of transitivity: > The transitivity of full smp_mb() barriers is global, but that > of smp_store_release()/smp_load_acquire() chains is local. This > commit therefore introduces the notion of local transitivity and > gives an example. > > Reported-by: Peter Zijlstra > Reported-by: Will Deacon > Signed-off-by: Paul E. McKenney I think it fails to mention smp_mb__after_release_acquire(), although I suspect we didn't actually introduce the primitive yet, which raises the point, do we want to? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Nested virtualization off VMware vSphere 6.0 with EL6 guests crashes on Xen 4.6
On Tue, Jan 12, 2016 at 02:22:03AM -0700, Jan Beulich wrote:
> >>> On 12.01.16 at 04:38, wrote:
> > (XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698
> > (XEN) [ Xen-4.6.0 x86_64 debug=y Tainted:C ]
> > (XEN) CPU:39
> > (XEN) RIP:e008:[] virtual_vmentry+0x487/0xac9
> > (XEN) RFLAGS: 00010246 CONTEXT: hypervisor (d1v3)
> > (XEN) rax: rbx: 83007786c000 rcx:
> > (XEN) rdx: 0e00 rsi: 000f rdi: 83407f81e010
> > (XEN) rbp: 834008a47ea8 rsp: 834008a47e38 r8:
> > (XEN) r9: r10: r11:
> > (XEN) r12: r13: 82c000341000 r14: 834008a47f18
> > (XEN) r15: 83407f7c4000 cr0: 80050033 cr4: 001526e0
> > (XEN) cr3: 00407fb22000 cr2:
> > (XEN) ds: es: fs: gs: ss: cs: e008
> > (XEN) Xen stack trace from rsp=834008a47e38:
> > (XEN)834008a47e68 82d0801d2cde 834008a47e68 0d00
> > (XEN) 834008a47e88 0004801cc30e
> > (XEN)83007786c000 83007786c000 834008a4
> > (XEN)834008a47f18 834008a47f08 82d0801edf94
> > (XEN)834008a47ef8 834008f62000 834008a47f18
> > (XEN)00ae8c99eb8d 83007786c000
> > (XEN) 82d0801ee2ab
> > (XEN)
> > (XEN)
> > (XEN)
> > (XEN)078bfbff beefbeef
> > (XEN)fc4b3440 00bfbeef 00040046 fc607f00
> > (XEN)beef beef beef beef
> > (XEN)beef 0027 83007786c000 006f88716300
> > (XEN)
> > (XEN) Xen call trace:
> > (XEN)[] virtual_vmentry+0x487/0xac9
> > (XEN)[] nvmx_switch_guest+0x8ff/0x915
> > (XEN)[] vmx_asm_vmexit_handler+0x4b/0xc0
> > (XEN)
> > (XEN)
> > (XEN)
> > (XEN) Panic on CPU 39:
> > (XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698
> > (XEN)
> > (XEN)
> >
> > ..and then to my surprise the hypervisor stopped hitting this.
>
> Since we can (I hope) pretty much exclude a paging type, the
> ASSERT() must have triggered because of vapic_pg being NULL.
> That might be verifiable without extra printk()s, just by checking
> the disassembly (assuming the value sits in a register). In which
> case vapic_gpfn would be of interest too.
The vapic_gpfn is 0x.
To be exact:
nvmx_update_virtual_apic_address:vCPU0 0x(vAPIC) 0x0(APIC),
0x0(TPR) ctrl=b5b9effe
Based on this:
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index cb6f9b8..8a0abfc 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -695,7 +695,15 @@ static void nvmx_update_virtual_apic_address(struct vcpu
*v)
vapic_gpfn = __get_vvmcs(nvcpu->nv_vvmcx, VIRTUAL_APIC_PAGE_ADDR) >>
PAGE_SHIFT;
vapic_pg = get_page_from_gfn(v->domain, vapic_gpfn, &p2mt, P2M_ALLOC);
-ASSERT(vapic_pg && !p2m_is_paging(p2mt));
+ if ( !vapic_pg ) {
+ printk("%s:vCPU%d 0x%lx(vAPIC) 0x%lx(APIC), 0x%lx(TPR)
ctrl=%x\n", __func__,v->vcpu_id,
+ __get_vvmcs(nvcpu->nv_vvmcx, VIRTUAL_APIC_PAGE_ADDR),
+ __get_vvmcs(nvcpu->nv_vvmcx, APIC_ACCESS_ADDR),
+ __get_vvmcs(nvcpu->nv_vvmcx, TPR_THRESHOLD),
+ ctrl);
+ }
+ASSERT(vapic_pg);
+ ASSERT(vapic_pg && !p2m_is_paging(p2mt));
__vmwrite(VIRTUAL_APIC_PAGE_ADDR, page_to_maddr(vapic_pg));
put_page(vapic_pg);
}
>
> What looks odd to me is the connection between
> CPU_BASED_TPR_SHADOW being set and the use of a (valid)
> virtual APIC page: Wouldn't this rather need to depend on
> SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES, just like in
> nvmx_update_apic_access_address()?
Could be. I added in an read for the secondary control:
nvmx_update_virtual_apic_address:vCPU2 0x(vAPIC) 0x0(APIC),
0x0(TPR) ctrl=b5b9effe sec=0
So trying your recommendation:
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index cb6f9b8..d291c91 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -686,8 +686,8 @@ static void nvmx_update_virtual_apic_address(struct vcpu *v)
struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
u32 ctrl;
-ctrl = __n2_ex
Re: [Xen-devel] [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -126,6 +126,17 @@ endef
>> check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least
>> gcc-4.1")
>> $(eval $(check-y))
>>
>> +ld-ver = $(shell if [ $$((`$(1) --version | head -1 | sed 's/[^0-9]/ /g' |
>> awk \
>> + '{ printf "0x%02x%02x", $$1, $$2}'`)) -ge $$(($(2))) ]; \
>> + then echo y; else echo n; fi ;)
>> +
>> +# binutils 2.18 implement build-id.
>> +ifeq ($(call ld-ver,$(LD),0x0212),n)
>> +build_id :=
>> +else
>> +build_id := --build-id=sha1
>> +endif
>
> Wouldn't it be better to probe the linker for recognizing the --build-id
> command line option, along the lines of $(cc-option)?
+ld-ver-build-id = $(shell $(1) --build-id 2>&1 | \
+ grep -q unrecognized && echo n
|| echo y)
-ish ?
>
> In any event the option should be added to LDFLAGS unless this
> conflicts with something else.
That had some interesting side-effect:
$ find . -name *.o | xargs readelf -n | more
File: ./arch/x86/built_in.o
Displaying notes found at file offset 0x0040 with length 0x0240:
Owner Data size Description
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: a114d1fdec2ace38448f141013f5a659122f2390
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 4a913d3d1ece4d175fc0df0b36745b801f88bfab
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: ead89ba3aa9a8257cfc863966b7a9a725ecce133
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 9b034a93573015c611d0900e949370d9f776bac1
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 0e5fab6126ce69edd5720b96e2d5414618259c78
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 49eca2138553b5e85ee45bb47c52aca394c31c31
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: f1cc2c8ae09fefe1440662efc44208a0b9ff8ddd
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 29991f03f7a1aeeb59c8f83c0e7a349384a7262c
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 3e2c4df9f60fdbd970bd1a35d03c7b68fd794385
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 2c4f5cd9bcf553a022dace08b7741d85a4eb657f
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 41c502289e5b28722ab5df6ae5bd7b99fb90c09e
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: f268afebdf211de6bb6d12e513520bba969130cc
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: b73b7296f6165d3dcacee36691d92ab1996d9908
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: ff8e080d8e01966cf8d893ce6cd258dd0d1c6124
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: dcc8964716f74bb710911d80faaae016820f72d9
GNU 0x0014 NT_GNU_BUILD_ID (unique build
ID bitstring)
Build ID: 649f4bb66df2fead426edda62d0c90ab088c5fd4
And during build:
ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored.
ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored.
ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored.
With:
[konrad@char xen]$ readelf -n xen-syms | grep Build | wc
38 1142090
I think we should skip on the LDFLAGS idea.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote:
>
> > > And the stuff we're confused about is how best to express the difference
> > > and guarantees of these two forms of transitivity and how exactly they
> > > interact.
> >
> > Hoping my memory-barrier.txt patch helps here...
>
> Yes, that seems a good start. But yesterday you raised the 'fun' point
> of two globally ordered sequences connected by a single local link.
The conclusion that I am slowly coming to is that litmus tests should
not be thought of as linear chains, but rather as cycles. If you think
of it as a cycle, then it doesn't matter where the local link is, just
how many of them and how they are connected.
But I will admit that there are some rather strange litmus tests that
challenge this cycle-centric view, for example, the one shown below.
It turns out that herd and ppcmem disagree on the outcome. (The Power
architects side with ppcmem.)
> And I think I'm still confused on LWSYNC (in the smp_wmb case) when one
> of the stores looses a conflict, and if that scenario matters. If it
> does, we should inspect the same case for other barriers.
Indeed. I am still working on how these should be described. My
current thought is to be quite conservative on what ordering is
actually respected, however, the current task is formalizing how
RCU plays with the rest of the memory model.
Thanx, Paul
PPC Overlapping Group-B sets version 4
""
(* When the Group-B sets from two different barriers involve instructions in
the same thread, within that thread one set must contain the other.
P0 P1 P2
Rx=1Wy=1Wz=2
dep.lwsync lwsync
Ry=0Wz=1Wx=1
Rz=1
assert(!(z=2))
Forbidden by ppcmem, allowed by herd.
*)
{
0:r1=x; 0:r2=y; 0:r3=z;
1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1;
2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2;
}
P0 | P1| P2;
lwz r6,0(r1) | stw r4,0(r2) | stw r5,0(r3) ;
xor r7,r6,r6 | lwsync| lwsync;
lwzx r7,r7,r2 | stw r4,0(r3) | stw r4,0(r1) ;
lwz r8,0(r3) | | ;
exists
(z=2 /\ 0:r6=1 /\ 0:r7=0 /\ 0:r8=1)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 10:29:12PM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > > Should we start putting litmus tests for the various examples > > somewhere, perhaps in a litmus-tests directory within each participating > > architecture? I have a pile of powerpc-related litmus tests on my laptop, > > but they probably aren't doing all that much good there. > > Yeah, or a version of them in C that we can 'compile'? That would be good as well. I am guessing that architecture-specific litmus tests will also be needed, but you are right that architecture-independent versions are higher priority. > > commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41 > > Author: Paul E. McKenney > > Date: Fri Jan 15 09:30:42 2016 -0800 > > > > documentation: Distinguish between local and global transitivity > > > > The introduction of smp_load_acquire() and smp_store_release() had > > the side effect of introducing a weaker notion of transitivity: > > The transitivity of full smp_mb() barriers is global, but that > > of smp_store_release()/smp_load_acquire() chains is local. This > > commit therefore introduces the notion of local transitivity and > > gives an example. > > > > Reported-by: Peter Zijlstra > > Reported-by: Will Deacon > > Signed-off-by: Paul E. McKenney > > I think it fails to mention smp_mb__after_release_acquire(), although I > suspect we didn't actually introduce the primitive yet, which raises the > point, do we want to? Well, it is not in v4.4. I believe that we need good use cases before we add it. Thanx, Paul ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Unifying x86_64 / Xen init paths and reading hardware_subarch early
I will be respinning the generic Linux linker table solution [0] soon
based on hpa's feedback again now that I'm back from vacation. As I do
that though I wanted to highlight a feature I'm throwing into the
linker table solution which I am not sure many have paid close
attention to but I think is important to Xen. I'm making use of the
zero page hardware_subarch to enable us to detect if we're a specific
hypervisor solution *as early as is possible*. This has a few
implications, short term it is designed to provides a proactive
technical solution to bugs such as the cr4 shadow crash (see
5054daa285beaf706f051fbd395dc36c9f0f907f) and ensure that *new* x86
features get a proper Xen implementation proactively *or* at the very
least get annotated as unsupported properly, instead of having them
crash and later finding out. A valid example here is Kasan, which to
this day lacks proper Xen support. In the future, if the generic
linker table solution gets merged, it would mean developers would have
to *think* about if they support Xen or not at development time. It
does this in a not-disruptive way to Xen / x86_64 but most
*importantly* it does not extend pvops! This should avoid issues in
cases of developer / maintainer bandwidth, should some new features be
pushed onto Linux for x86_64 but a respective Xen solution is not
addressed, and that was not caught early in patch review, such as with
Kasan.
[0]
https://lkml.kernel.org/r/1450217797-19295-1-git-send-email-mcg...@do-not-panic.com
Two things I'd like to request a bit of help with and review / consideration:
1) I'd like some advice on a curious problem I've stumbled on. I'd
like to access hardware_subarch super early, and in my review with at
least two x86 folks this *should* work:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index c913b7eb5056..9168842821c8 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -141,6 +141,7 @@ static void __init copy_bootdata(char *real_mode_data)
asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
{
+ struct boot_params *params = (struct boot_params *)__va(real_mode_data);
int i;
/*
@@ -157,6 +158,8 @@ asmlinkage __visible void __init
x86_64_start_kernel(char * real_mode_data)
(__START_KERNEL & PGDIR_MASK)));
BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END);
+ boot_params.hdr.hardware_subarch = params->hdr.hardware_subarch;
+
cr4_init_shadow();
/* Kill off the identity-map trampoline */
In practice today though this crashes the kernel. One does not need to
try to run Xen to test this, simply applying this change should crash
a bare metal / qemu instance. If you'd like to force a different value
for the subarch you could use this *debug patch* and just use kvm
which would set the subarch to a value not yet assigned on Linux:
http://drvbp1.linux-foundation.org/~mcgrof/patches/2016/01/15/qemu-add-subarch.patch
Simply getting away from he crash is my goal for now. The earliest I
can read the subarch as it stands is right after load_idt() on the x86
init path and I simply have no clue why! I'm told this in theory
should work. But clearly it does not. I tried running qemu with gdb
and I can't get anything sensible out of this so -- I need a bit more
x86 help.
Why do I want this? It would mean we can cover a proactive solution
all the way up to the earliest calls on Linux. Without this the
subarch becomes useful only after load_idt(). Since I'm using the
subarch to build dependency maps early on it also means that the
linker table solution becomes only useful on
x86_64_start_reservations() and not x86_64_start_kernel() which is the
first C Linux entry point for 64-bit. Having the subarch readible as
early as x86_64_start_kernel() means the linker table solution can be
used to proactively prevent issues even with discrepancies between
x86_64_start_kernel() and x86_64_start_reservations() and
xen_start_kernel(). There's another important reason listed below...
2) Provided we address 1) above it could mean it being possible to
unify *at least* the C Xen x86_64 init path and the bare metal x86_64
init paths without much code shuffling. Based on discussions at the
last Xen developer summit it seemed this was being considered and
perhaps desirable. Now the patch below would need a bit more work, but
ultimately this gives a small glance at what this could in theory
possibly look like:
http://drvbp1.linux-foundation.org/~mcgrof/patches/2015/12/15/x86-merge-x86-init-v1.patch
The xen init stuff just becomes a Xen specific subarch call. Folks
interested in this prospect are welcomed to help review or expand on
this work. If you are working on another type of unifying init
solution I'd like to hear it as well.
Luis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 78159: regressions - FAIL
flight 78159 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/78159/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-amd64-xl-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-i386-xl-xsm5 xen-install fail REGR. vs. 77892 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 77892 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 77892 test-amd64-i386-xl-qemut-win7-amd64 9 windows-installfail REGR. vs. 77892 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 7 host-ping-check-xen fail pass in 78129 test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail pass in 78129 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-amd64-libvirt-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 77892 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 77892 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 77892 test-armhf-armhf-xl-rtds 9 debian-install fail like 77892 test-amd64-amd64-libvirt-vhd 9 debian-di-installfail like 77892 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 78129 never pass test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 78129 never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 78129 never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestore fail in 78129 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-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-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-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 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass version targeted for testing: xen 7167222b15dc661ff0b44cc93d558f6bb4ff6492 baseline version: xen f7347a282420a5edc74afb31e7c42c2765f24de5 Last test of basis77892 2016-01-12 11:30:40 Z3 days Failing since 77945 2016-01-13 04:01:14 Z2 days5 attempts Testing same since78129 2016-01-15 00:12:12 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Boris Ostrovsky Brendan Gregg Daniel De Graaf Doug Goldstein Haozhong Zhang Jan Beulich Juergen Gross Kevin Tian Razvan Cojocaru Roger Pau Monné Tamas K Lengyel Wei Liu Wei Liu for tools bits jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64
Re: [Xen-devel] Unifying x86_64 / Xen init paths and reading hardware_subarch early
On Fri, Jan 15, 2016 at 2:08 PM, Luis R. Rodriguez wrote:
> I will be respinning the generic Linux linker table solution [0] soon
> based on hpa's feedback again now that I'm back from vacation. As I do
> that though I wanted to highlight a feature I'm throwing into the
> linker table solution which I am not sure many have paid close
> attention to but I think is important to Xen. I'm making use of the
> zero page hardware_subarch to enable us to detect if we're a specific
> hypervisor solution *as early as is possible*. This has a few
> implications, short term it is designed to provides a proactive
> technical solution to bugs such as the cr4 shadow crash (see
> 5054daa285beaf706f051fbd395dc36c9f0f907f) and ensure that *new* x86
> features get a proper Xen implementation proactively *or* at the very
> least get annotated as unsupported properly, instead of having them
> crash and later finding out. A valid example here is Kasan, which to
> this day lacks proper Xen support. In the future, if the generic
> linker table solution gets merged, it would mean developers would have
> to *think* about if they support Xen or not at development time. It
> does this in a not-disruptive way to Xen / x86_64 but most
> *importantly* it does not extend pvops! This should avoid issues in
> cases of developer / maintainer bandwidth, should some new features be
> pushed onto Linux for x86_64 but a respective Xen solution is not
> addressed, and that was not caught early in patch review, such as with
> Kasan.
>
> [0]
> https://lkml.kernel.org/r/1450217797-19295-1-git-send-email-mcg...@do-not-panic.com
>
> Two things I'd like to request a bit of help with and review / consideration:
>
> 1) I'd like some advice on a curious problem I've stumbled on. I'd
> like to access hardware_subarch super early, and in my review with at
> least two x86 folks this *should* work:
>
> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> index c913b7eb5056..9168842821c8 100644
> --- a/arch/x86/kernel/head64.c
> +++ b/arch/x86/kernel/head64.c
> @@ -141,6 +141,7 @@ static void __init copy_bootdata(char *real_mode_data)
>
> asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
> {
> + struct boot_params *params = (struct boot_params *)__va(real_mode_data);
> int i;
This is a mess :-p
If you want to access real_mode_data before load_idt, you'll need to do:
for (i = 0; i < sizeof(boot_params); i += 4096)
early_make_pgtable((unsigned long)params + i);
Of course, it's entirely possible that that will blow up if you try to
do it on Xen.
I think this would all be easier to understand if you try to separate
out the ideas of linker tables from the idea of rearranging early
init. AFAICT the linker table thing is just an implementation detail.
If I understand right, you're trying to unify the Xen and native
startup as much as possible. Why not add little shims, though?
Create a new start_kernel_common(int subarch, ...) where subarch
indicates native vs Xen and have its callers tell it which mode it's
in?
--Andy
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 78164: regressions - FAIL
flight 78164 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/78164/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 78054 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 78054 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 78054 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 78054 test-amd64-i386-xl-xsm 15 guest-localmigratefail REGR. vs. 78054 test-amd64-i386-xl 15 guest-localmigratefail REGR. vs. 78054 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 78054 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail REGR. vs. 78054 test-armhf-armhf-xl 18 leak-check/check fail REGR. vs. 78054 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 14 guest-saverestore.2 fail REGR. vs. 78054 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestore fail REGR. vs. 78054 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 78054 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail REGR. vs. 78054 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail REGR. vs. 78054 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 78054 test-amd64-i386-libvirt 15 guest-saverestore.2 fail REGR. vs. 78054 test-armhf-armhf-libvirt-raw 6 xen-boot fail REGR. vs. 78054 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 78054 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 78054 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 78054 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail REGR. vs. 78054 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 78054 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 78054 test-armhf-armhf-xl-cubietruck 6 xen-boot fail like 78054 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 78054 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 78054 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 78054 test-amd64-amd64-libvirt-vhd 9 debian-di-installfail like 78054 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 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-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass version targeted for testing: linux39750fe2d360d6f1ccdc6b33d0a5cb624c97a5fd baseline version: linux1289ace5b4f70f1e68ce785735b82c7e483de863 Last test of basis
[Xen-devel] [4.2.y-ckt stable] Patch "x86/paravirt: Prevent rtc_cmos platform device init on PV guests" has been added to the 4.2.y-ckt tree
This is a note to let you know that I have just added a patch titled
x86/paravirt: Prevent rtc_cmos platform device init on PV guests
to the linux-4.2.y-queue branch of the 4.2.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-4.2.y-queue
This patch is scheduled to be released in version 4.2.8-ckt2.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 4.2.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
---8<
>From 0dd88836fb7f14a4d4a3d5e179e70f4aff8d9e6c Mon Sep 17 00:00:00 2001
From: David Vrabel
Date: Fri, 11 Dec 2015 09:07:53 -0500
Subject: x86/paravirt: Prevent rtc_cmos platform device init on PV guests
commit d8c98a1d1488747625ad6044d423406e17e99b7a upstream.
Adding the rtc platform device in non-privileged Xen PV guests causes
an IRQ conflict because these guests do not have legacy PIC and may
allocate irqs in the legacy range.
In a single VCPU Xen PV guest we should have:
/proc/interrupts:
CPU0
0: 4934 xen-percpu-virq timer0
1: 0 xen-percpu-ipi spinlock0
2: 0 xen-percpu-ipi resched0
3: 0 xen-percpu-ipi callfunc0
4: 0 xen-percpu-virq debug0
5: 0 xen-percpu-ipi callfuncsingle0
6: 0 xen-percpu-ipi irqwork0
7:321 xen-dyn-event xenbus
8: 90 xen-dyn-event hvc_console
...
But hvc_console cannot get its interrupt because it is already in use
by rtc0 and the console does not work.
genirq: Flags mismatch irq 8. (hvc_console) vs. (rtc0)
We can avoid this problem by realizing that unprivileged PV guests (both
Xen and lguests) are not supposed to have rtc_cmos device and so
adding it is not necessary.
Privileged guests (i.e. Xen's dom0) do use it but they should not have
irq conflicts since they allocate irqs above legacy range (above
gsi_top, in fact).
Instead of explicitly testing whether the guest is privileged we can
extend pv_info structure to include information about guest's RTC
support.
Reported-and-tested-by: Sander Eikelenboom
Signed-off-by: David Vrabel
Signed-off-by: Boris Ostrovsky
Cc: vkuzn...@redhat.com
Cc: xen-de...@lists.xenproject.org
Cc: konrad.w...@oracle.com
Link:
http://lkml.kernel.org/r/1449842873-2613-1-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Kamal Mostafa
---
arch/x86/include/asm/paravirt.h | 6 ++
arch/x86/include/asm/paravirt_types.h | 5 +
arch/x86/include/asm/processor.h | 1 +
arch/x86/kernel/rtc.c | 3 +++
arch/x86/lguest/boot.c| 1 +
arch/x86/xen/enlighten.c | 4 +++-
6 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index d143bfa..d0791ac 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -19,6 +19,12 @@ static inline int paravirt_enabled(void)
return pv_info.paravirt_enabled;
}
+static inline int paravirt_has_feature(unsigned int feature)
+{
+ WARN_ON_ONCE(!pv_info.paravirt_enabled);
+ return (pv_info.features & feature);
+}
+
static inline void load_sp0(struct tss_struct *tss,
struct thread_struct *thread)
{
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index a6b8f9f..af3b3b7 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -70,9 +70,14 @@ struct pv_info {
#endif
int paravirt_enabled;
+ unsigned int features;/* valid only if paravirt_enabled is set */
const char *name;
};
+#define paravirt_has(x) paravirt_has_feature(PV_SUPPORTED_##x)
+/* Supported features */
+#define PV_SUPPORTED_RTC(1<<0)
+
struct pv_init_ops {
/*
* Patch may replace one of the defined code sequences with
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 944f178..9b3bb51 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -478,6 +478,7 @@ static inline unsigned long current_top_of_stack(void)
#else
#define __cpuidnative_cpuid
#define paravirt_enabled() 0
+#define paravirt_has(x)0
static inline void load_sp0(struct tss_struct *tss,
struct thread_struct *thread)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index cd96852..4af8d06 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
#endif
+ if (paravirt_enabled() && !paravirt_has(RTC))
+ return -ENODEV;
+
platform_device_register(&rtc_device)
[Xen-devel] [PATCH 4.2.y-ckt 286/305] x86/paravirt: Prevent rtc_cmos platform device init on PV guests
4.2.8-ckt2 -stable review patch. If anyone has any objections, please let me
know.
---8<
From: David Vrabel
commit d8c98a1d1488747625ad6044d423406e17e99b7a upstream.
Adding the rtc platform device in non-privileged Xen PV guests causes
an IRQ conflict because these guests do not have legacy PIC and may
allocate irqs in the legacy range.
In a single VCPU Xen PV guest we should have:
/proc/interrupts:
CPU0
0: 4934 xen-percpu-virq timer0
1: 0 xen-percpu-ipi spinlock0
2: 0 xen-percpu-ipi resched0
3: 0 xen-percpu-ipi callfunc0
4: 0 xen-percpu-virq debug0
5: 0 xen-percpu-ipi callfuncsingle0
6: 0 xen-percpu-ipi irqwork0
7:321 xen-dyn-event xenbus
8: 90 xen-dyn-event hvc_console
...
But hvc_console cannot get its interrupt because it is already in use
by rtc0 and the console does not work.
genirq: Flags mismatch irq 8. (hvc_console) vs. (rtc0)
We can avoid this problem by realizing that unprivileged PV guests (both
Xen and lguests) are not supposed to have rtc_cmos device and so
adding it is not necessary.
Privileged guests (i.e. Xen's dom0) do use it but they should not have
irq conflicts since they allocate irqs above legacy range (above
gsi_top, in fact).
Instead of explicitly testing whether the guest is privileged we can
extend pv_info structure to include information about guest's RTC
support.
Reported-and-tested-by: Sander Eikelenboom
Signed-off-by: David Vrabel
Signed-off-by: Boris Ostrovsky
Cc: vkuzn...@redhat.com
Cc: xen-de...@lists.xenproject.org
Cc: konrad.w...@oracle.com
Link:
http://lkml.kernel.org/r/1449842873-2613-1-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Kamal Mostafa
---
arch/x86/include/asm/paravirt.h | 6 ++
arch/x86/include/asm/paravirt_types.h | 5 +
arch/x86/include/asm/processor.h | 1 +
arch/x86/kernel/rtc.c | 3 +++
arch/x86/lguest/boot.c| 1 +
arch/x86/xen/enlighten.c | 4 +++-
6 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index d143bfa..d0791ac 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -19,6 +19,12 @@ static inline int paravirt_enabled(void)
return pv_info.paravirt_enabled;
}
+static inline int paravirt_has_feature(unsigned int feature)
+{
+ WARN_ON_ONCE(!pv_info.paravirt_enabled);
+ return (pv_info.features & feature);
+}
+
static inline void load_sp0(struct tss_struct *tss,
struct thread_struct *thread)
{
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index a6b8f9f..af3b3b7 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -70,9 +70,14 @@ struct pv_info {
#endif
int paravirt_enabled;
+ unsigned int features;/* valid only if paravirt_enabled is set */
const char *name;
};
+#define paravirt_has(x) paravirt_has_feature(PV_SUPPORTED_##x)
+/* Supported features */
+#define PV_SUPPORTED_RTC(1<<0)
+
struct pv_init_ops {
/*
* Patch may replace one of the defined code sequences with
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 944f178..9b3bb51 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -478,6 +478,7 @@ static inline unsigned long current_top_of_stack(void)
#else
#define __cpuidnative_cpuid
#define paravirt_enabled() 0
+#define paravirt_has(x)0
static inline void load_sp0(struct tss_struct *tss,
struct thread_struct *thread)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index cd96852..4af8d06 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
#endif
+ if (paravirt_enabled() && !paravirt_has(RTC))
+ return -ENODEV;
+
platform_device_register(&rtc_device);
dev_info(&rtc_device.dev,
"registered platform RTC device (no PNP device found)\n");
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index f2dc08c..5c4792e 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1419,6 +1419,7 @@ __init void lguest_init(void)
pv_info.kernel_rpl = 1;
/* Everyone except Xen runs with this set. */
pv_info.shared_kernel_pmd = 1;
+ pv_info.features = 0;
/*
* We set up all the lguest overrides for sensitive operations. These
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 3cebc65..f83c0ba 100644
--- a/arch/x86/xen/enlighte
[Xen-devel] [seabios test] 78178: tolerable FAIL - PUSHED
flight 78178 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78178/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 78109
Tests which did not succeed, but are not blocking:
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
seabios 9720484aec619d6414bbeed90e203f752742fa5c
baseline version:
seabios 3e8d75f3bef0f36a807303d58523ef5eba4a386f
Last test of basis78109 2016-01-14 17:15:19 Z1 days
Testing same since78178 2016-01-15 14:53:32 Z0 days1 attempts
People who touched revisions under test:
Kevin O'Connor
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-qemuu-nested-amdfail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3pass
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=seabios
+ revision=9720484aec619d6414bbeed90e203f752742fa5c
+ . ./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 seabios
9720484aec619d6414bbeed90e203f752742fa5c
+ branch=seabios
+ revision=9720484aec619d6414bbeed90e203f752742fa5c
+ . ./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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upst
Re: [Xen-devel] Unifying x86_64 / Xen init paths and reading hardware_subarch early
On Fri, Jan 15, 2016 at 03:47:25PM -0800, Andy Lutomirski wrote:
> On Fri, Jan 15, 2016 at 2:08 PM, Luis R. Rodriguez wrote:
> > I will be respinning the generic Linux linker table solution [0] soon
> > based on hpa's feedback again now that I'm back from vacation. As I do
> > that though I wanted to highlight a feature I'm throwing into the
> > linker table solution which I am not sure many have paid close
> > attention to but I think is important to Xen. I'm making use of the
> > zero page hardware_subarch to enable us to detect if we're a specific
> > hypervisor solution *as early as is possible*. This has a few
> > implications, short term it is designed to provides a proactive
> > technical solution to bugs such as the cr4 shadow crash (see
> > 5054daa285beaf706f051fbd395dc36c9f0f907f) and ensure that *new* x86
> > features get a proper Xen implementation proactively *or* at the very
> > least get annotated as unsupported properly, instead of having them
> > crash and later finding out. A valid example here is Kasan, which to
> > this day lacks proper Xen support. In the future, if the generic
> > linker table solution gets merged, it would mean developers would have
> > to *think* about if they support Xen or not at development time. It
> > does this in a not-disruptive way to Xen / x86_64 but most
> > *importantly* it does not extend pvops! This should avoid issues in
> > cases of developer / maintainer bandwidth, should some new features be
> > pushed onto Linux for x86_64 but a respective Xen solution is not
> > addressed, and that was not caught early in patch review, such as with
> > Kasan.
> >
> > [0]
> > https://lkml.kernel.org/r/1450217797-19295-1-git-send-email-mcg...@do-not-panic.com
> >
> > Two things I'd like to request a bit of help with and review /
> > consideration:
> >
> > 1) I'd like some advice on a curious problem I've stumbled on. I'd
> > like to access hardware_subarch super early, and in my review with at
> > least two x86 folks this *should* work:
> >
> > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> > index c913b7eb5056..9168842821c8 100644
> > --- a/arch/x86/kernel/head64.c
> > +++ b/arch/x86/kernel/head64.c
> > @@ -141,6 +141,7 @@ static void __init copy_bootdata(char *real_mode_data)
> >
> > asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
> > {
> > + struct boot_params *params = (struct boot_params *)__va(real_mode_data);
> > int i;
>
> This is a mess :-p
Agreed. Doing what I can without extending pvops though ;)
> If you want to access real_mode_data before load_idt, you'll need to do:
>
> for (i = 0; i < sizeof(boot_params); i += 4096)
> early_make_pgtable((unsigned long)params + i);
Thanks I'll give this a shot.
> Of course, it's entirely possible that that will blow up if you try to
> do it on Xen.
I'll check, if its safe and if the subarch strategy is desirable to help with
unifying init, then great. Otherwise we'd need to figure this out.
> I think this would all be easier to understand if you try to separate
> out the ideas of linker tables from the idea of rearranging early
> init.
Oh absolutely. The goal to unify init *or* to access subarch earlier provides
slightly different gains and possiblities. This is why I am addressing this
separately. Its important to highlight the prospects though given I think a few
folks may not have realized what might be possible here...
> AFAICT the linker table thing is just an implementation detail.
Indeed, but just as a linker table is one thing, the *use* of the linker table
for x86 early init is another. Its a good example how how to use the linker
tables though.
The things I make mention of here are just possible *enhancements* of that work
provided the subarch can be read earlier. Another possibility which I also had
not mentioned is the ability to also free annotated code on x86 init which we
*know* for sure we don't need, much as __init code after we boot, only this
could be done later at run time. That's also best technically considered later
but perhaps worth mentioning now as a future possibility.
Although the linker table series does not address unifying init, in this thread
we are talking about the prospect of being able to do that in the future. Its
best to consider this early than late.
> If I understand right, you're trying to unify the Xen and native
> startup as much as possible.
That ultimately is a possibility. The original patches don't do that though.
They just pave the way with linker tables as baby steps.
Without access to the subarch so early unifying init is not possible with a
linker table solution though. As the series was posted though its late use
(after load_idt()) still holds promise to help annotate subarch support, which
in turn also helps provide dependency maps. This should help with a proactive
solution to ensure x86 developers think about x86 early requirements. Only
that gain would be restricted to after loa
[Xen-devel] [ovmf test] 78189: regressions - FAIL
flight 78189 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/78189/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543 version targeted for testing: ovmf 0196c24a94c65a7d8ccbd111adff06b84d595a55 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 38 days Failing since 65593 2015-12-08 23:44:51 Z 38 days 28 attempts Testing same since78189 2016-01-15 16:53:56 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Yao, Jiewen" Andrew Fish Ard Biesheuvel Cecil Sheng Chao Zhang Dandan Bi Daocheng Bu Daryl McDaniel Eric Dong Eric Dong Eugene Cohen Feng Tian Fu Siyuan Hao Wu Hess Chen Heyi Guo Jaben Carsey Jeff Fan Jiaxin Wu Jim Dailey Jordan Justen Larry Hauch Laszlo Ersek Leekha Shaveta Liming Gao Mark Rutland Michael Kinney Michael Thomas Paulo Alcantara Qin Long Qiu Shumin Ruiyu Ni Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Star Zeng Tapan Shah Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zhang Lubo jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail 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 Not pushing. (No revision log; it would be 5029 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Unifying x86_64 / Xen init paths and reading hardware_subarch early
On January 15, 2016 4:43:04 PM PST, "Luis R. Rodriguez" wrote:
>On Fri, Jan 15, 2016 at 03:47:25PM -0800, Andy Lutomirski wrote:
>> On Fri, Jan 15, 2016 at 2:08 PM, Luis R. Rodriguez
>wrote:
>> > I will be respinning the generic Linux linker table solution [0]
>soon
>> > based on hpa's feedback again now that I'm back from vacation. As I
>do
>> > that though I wanted to highlight a feature I'm throwing into the
>> > linker table solution which I am not sure many have paid close
>> > attention to but I think is important to Xen. I'm making use of the
>> > zero page hardware_subarch to enable us to detect if we're a
>specific
>> > hypervisor solution *as early as is possible*. This has a few
>> > implications, short term it is designed to provides a proactive
>> > technical solution to bugs such as the cr4 shadow crash (see
>> > 5054daa285beaf706f051fbd395dc36c9f0f907f) and ensure that *new* x86
>> > features get a proper Xen implementation proactively *or* at the
>very
>> > least get annotated as unsupported properly, instead of having them
>> > crash and later finding out. A valid example here is Kasan, which
>to
>> > this day lacks proper Xen support. In the future, if the generic
>> > linker table solution gets merged, it would mean developers would
>have
>> > to *think* about if they support Xen or not at development time. It
>> > does this in a not-disruptive way to Xen / x86_64 but most
>> > *importantly* it does not extend pvops! This should avoid issues in
>> > cases of developer / maintainer bandwidth, should some new features
>be
>> > pushed onto Linux for x86_64 but a respective Xen solution is not
>> > addressed, and that was not caught early in patch review, such as
>with
>> > Kasan.
>> >
>> > [0]
>https://lkml.kernel.org/r/1450217797-19295-1-git-send-email-mcg...@do-not-panic.com
>> >
>> > Two things I'd like to request a bit of help with and review /
>consideration:
>> >
>> > 1) I'd like some advice on a curious problem I've stumbled on. I'd
>> > like to access hardware_subarch super early, and in my review with
>at
>> > least two x86 folks this *should* work:
>> >
>> > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
>> > index c913b7eb5056..9168842821c8 100644
>> > --- a/arch/x86/kernel/head64.c
>> > +++ b/arch/x86/kernel/head64.c
>> > @@ -141,6 +141,7 @@ static void __init copy_bootdata(char
>*real_mode_data)
>> >
>> > asmlinkage __visible void __init x86_64_start_kernel(char *
>real_mode_data)
>> > {
>> > + struct boot_params *params = (struct boot_params
>*)__va(real_mode_data);
>> > int i;
>>
>> This is a mess :-p
>
>Agreed. Doing what I can without extending pvops though ;)
>
>> If you want to access real_mode_data before load_idt, you'll need to
>do:
>>
>> for (i = 0; i < sizeof(boot_params); i += 4096)
>> early_make_pgtable((unsigned long)params + i);
>
>Thanks I'll give this a shot.
>
>> Of course, it's entirely possible that that will blow up if you try
>to
>> do it on Xen.
>
>I'll check, if its safe and if the subarch strategy is desirable to
>help with
>unifying init, then great. Otherwise we'd need to figure this out.
>
>> I think this would all be easier to understand if you try to separate
>> out the ideas of linker tables from the idea of rearranging early
>> init.
>
>Oh absolutely. The goal to unify init *or* to access subarch earlier
>provides
>slightly different gains and possiblities. This is why I am addressing
>this
>separately. Its important to highlight the prospects though given I
>think a few
>folks may not have realized what might be possible here...
>
>> AFAICT the linker table thing is just an implementation detail.
>
>Indeed, but just as a linker table is one thing, the *use* of the
>linker table
>for x86 early init is another. Its a good example how how to use the
>linker
>tables though.
>
>The things I make mention of here are just possible *enhancements* of
>that work
>provided the subarch can be read earlier. Another possibility which I
>also had
>not mentioned is the ability to also free annotated code on x86 init
>which we
>*know* for sure we don't need, much as __init code after we boot, only
>this
>could be done later at run time. That's also best technically
>considered later
>but perhaps worth mentioning now as a future possibility.
>
>Although the linker table series does not address unifying init, in
>this thread
>we are talking about the prospect of being able to do that in the
>future. Its
>best to consider this early than late.
>
>> If I understand right, you're trying to unify the Xen and native
>> startup as much as possible.
>
>That ultimately is a possibility. The original patches don't do that
>though.
>They just pave the way with linker tables as baby steps.
>
>Without access to the subarch so early unifying init is not possible
>with a
>linker table solution though. As the series was posted though its late
>use
>(after load_idt()) still holds promise to help annotate subarch
>support, which
>in turn al
Re: [Xen-devel] Unifying x86_64 / Xen init paths and reading hardware_subarch early
On Fri, Jan 15, 2016 at 4:43 PM, Luis R. Rodriguez wrote:
>> for (i = 0; i < sizeof(boot_params); i += 4096)
>> early_make_pgtable((unsigned long)params + i);
>
> I'll give this a shot.
Thanks again for this! It seems to let this boot now! But it does not
seem to provided the right value. If I use the qemu debug patch as I
listed before to set this to 5 for kvm, and boot it doesn't come up.
This can be tested with the qemu debug patch + this debug kernel patch
which prints it out and resets it from what it finds early.
If you comment out the boot_params.hdr.hardware_subarch =
my_hardware_subarch; assignment we get the right value from the
copy_bootdata() work. I use my_hardware_subarch just as a quick hack
to test and cache the value early code gets but that I can't print
early on.
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index c913b7eb5056..6fc92553f272 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -139,9 +139,12 @@ static void __init copy_bootdata(char *real_mode_data)
}
}
+__u32 my_hardware_subarch;
+
asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
{
int i;
+ struct boot_params *params = (struct boot_params *)__va(real_mode_data);
/*
* Build-time sanity checks on the kernel image and module
@@ -157,6 +160,13 @@ asmlinkage __visible void __init
x86_64_start_kernel(char * real_mode_data)
(__START_KERNEL & PGDIR_MASK)));
BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END);
+ /* Make the zero page accessible as early as possible */
+ for (i = 0; i < sizeof(boot_params); i += 4096)
+ early_make_pgtable((unsigned long)params + i);
+
+ boot_params.hdr.hardware_subarch = params->hdr.hardware_subarch;
+ my_hardware_subarch = params->hdr.hardware_subarch;
+
cr4_init_shadow();
/* Kill off the identity-map trampoline */
@@ -173,6 +183,7 @@ asmlinkage __visible void __init
x86_64_start_kernel(char * real_mode_data)
load_idt((const struct desc_ptr *)&idt_descr);
copy_bootdata(__va(real_mode_data));
+ boot_params.hdr.hardware_subarch = my_hardware_subarch;
/*
* Load microcode early on BSP.
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d3d80e6d42a2..c2f85f8ab52b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -851,6 +851,8 @@ void __init setup_arch(char **cmdline_p)
(unsigned long)__bss_stop - (unsigned long)_text);
early_reserve_initrd();
+ pr_info("boot_params.hdr.hardware_subarch: 0x%04x\n",
+ boot_params.hdr.hardware_subarch);
/*
* At this point everything still needed from the boot loader
Luis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 78190: regressions - FAIL
test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpupass test-armhf-armhf-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrubpass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-xl-qcow2pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass 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 Not pushing. commit 5a57acb66f19ee52723aa05b8afbbc41c3e9ec99 Merge: f02ccf5 67736a2 Author: Peter Maydell Date: Fri Jan 15 15:49:43 2016 + Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20160115' into staging target-arm queue: * use the right MMU index when handling unaligned accesses * xlnx-zynqmp: Add support for high DDR memory regions * target-arm: support QMP dump-guest-memory * ARM: virt: Don't generate RTC ACPI device when using UEFI # gpg: Signature made Fri 15 Jan 2016 15:16:19 GMT using RSA key ID 14360CDE # gpg: Good signature from "Peter Maydell " # gpg: aka "Peter Maydell " # gpg: aka "Peter Maydell " * remotes/pmaydell/tags/pull-target-arm-20160115: ARM: virt: Don't generate RTC ACPI device when using UEFI target-arm: dump-guest-memory: add vfp notes for arm elf: add arm note types target-arm: dump-guest-memory: add prfpreg notes for aarch64 target-arm: support
[Xen-devel] [PATCH v4 02/10] ACPI / table: Add new function to get table entries
From: Ashwin Chaugule
The acpi_table_parse() function has a callback that
passes a pointer to a table_header. Add a new function
which takes this pointer and parses its entries. This
eliminates the need to re-traverse all the tables for
each call. e.g. as in acpi_table_parse_madt() which is
normally called after acpi_table_parse().
Acked-by: Grant Likely
Signed-off-by: Ashwin Chaugule
Signed-off-by: Tomasz Nowicki
Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
[Linux commit f08bb472bff3c0397fb7d6f47bc5cec41dad76e3]
Signed-off-by: Shannon Zhao
---
Cc: Jan Beulich
---
xen/drivers/acpi/tables.c | 50 +++
xen/include/xen/acpi.h| 4
2 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 39f1223..4e590de 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -199,27 +199,23 @@ void __init acpi_table_print_madt_entry(struct
acpi_subtable_header *header)
int __init
-acpi_table_parse_entries(char *id,
-unsigned long table_size,
-int entry_id,
-acpi_table_entry_handler handler,
-unsigned int max_entries)
+acpi_parse_entries(char *id, unsigned long table_size,
+ acpi_table_entry_handler handler,
+ struct acpi_table_header *table_header,
+ int entry_id, unsigned int max_entries)
{
- struct acpi_table_header *table_header = NULL;
struct acpi_subtable_header *entry;
- unsigned int count = 0;
+ int count = 0;
unsigned long table_end;
if (acpi_disabled)
return -ENODEV;
- if (!handler)
+ if (!id || !handler)
return -EINVAL;
- if (strncmp(id, ACPI_SIG_MADT, 4) == 0)
- acpi_get_table(id, acpi_apic_instance, &table_header);
- else
- acpi_get_table(id, 0, &table_header);
+ if (!table_size)
+ return -EINVAL;
if (!table_header) {
printk(KERN_WARNING PREFIX "%4.4s not present\n", id);
@@ -252,6 +248,7 @@ acpi_table_parse_entries(char *id,
entry = (struct acpi_subtable_header *)
((unsigned long)entry + entry->length);
}
+
if (max_entries && count > max_entries) {
printk(KERN_WARNING PREFIX "[%4.4s:%#x] ignored %i entries of "
"%i found\n", id, entry_id, count - max_entries, count);
@@ -261,6 +258,35 @@ acpi_table_parse_entries(char *id,
}
int __init
+acpi_table_parse_entries(char *id,
+unsigned long table_size,
+int entry_id,
+acpi_table_entry_handler handler,
+unsigned int max_entries)
+{
+ struct acpi_table_header *table_header = NULL;
+ u32 instance = 0;
+
+ if (acpi_disabled)
+ return -ENODEV;
+
+ if (!id || !handler)
+ return -EINVAL;
+
+ if (!strncmp(id, ACPI_SIG_MADT, 4))
+ instance = acpi_apic_instance;
+
+ acpi_get_table(id, instance, &table_header);
+ if (!table_header) {
+ printk(KERN_WARNING PREFIX "%4.4s not present\n", id);
+ return -ENODEV;
+ }
+
+ return acpi_parse_entries(id, table_size, handler, table_header,
+ entry_id, max_entries);
+}
+
+int __init
acpi_table_parse_madt(enum acpi_madt_type id,
acpi_table_entry_handler handler, unsigned int
max_entries)
{
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index 0f1077d..65e53a6 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -64,6 +64,10 @@ void acpi_hest_init(void);
int acpi_table_init (void);
int acpi_table_parse(char *id, acpi_table_handler handler);
+int acpi_parse_entries(char *id, unsigned long table_size,
+ acpi_table_entry_handler handler,
+ struct acpi_table_header *table_header,
+ int entry_id, unsigned int max_entries);
int acpi_table_parse_entries(char *id, unsigned long table_size,
int entry_id, acpi_table_entry_handler handler, unsigned int
max_entries);
int acpi_table_parse_madt(enum acpi_madt_type id, acpi_table_entry_handler
handler, unsigned int max_entries);
--
2.0.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 03/10] acpi/pmstat: Build pmstat for x86 only
From: Parth Dixit Pmstat is currently not supported for ARM in Xen. Configure and build pmstat for x86 architecture only. Cc: Jan Beulich Signed-off-by: Parth Dixit Signed-off-by: Shannon Zhao --- v4: keep both CONFIG_HAS_ACPI and CONFIG_HAS_CPUFREQ --- xen/common/sysctl.c | 2 +- xen/drivers/acpi/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index a3007b8..1624024 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) op->u.availheap.avail_bytes <<= PAGE_SHIFT; break; -#ifdef CONFIG_HAS_ACPI +#if defined (CONFIG_HAS_ACPI) && defined (CONFIG_HAS_CPUFREQ) case XEN_SYSCTL_get_pmstat: ret = do_get_pm_info(&op->u.get_pmstat); break; diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile index 3bb626e..0ef3efd 100644 --- a/xen/drivers/acpi/Makefile +++ b/xen/drivers/acpi/Makefile @@ -5,7 +5,7 @@ subdir-$(x86) += apei obj-bin-y += tables.init.o obj-$(HAS_NUMA) += numa.o obj-y += osl.o -obj-y += pmstat.o +obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o obj-$(x86) += hwregs.o obj-$(x86) += reboot.o -- 2.0.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 07/10] arm/gic-v2: Refactor gicv2_init into generic and dt specific parts
From: Shannon Zhao
Refactor gic-v2 related functions into dt and generic parts. This will be
helpful when adding acpi support for gic.
Signed-off-by: Parth Dixit
Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
---
xen/arch/arm/gic-v2.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 793dca7..3fb5823 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -628,13 +628,12 @@ static bool_t gicv2_is_aliased(paddr_t cbase, paddr_t
csize)
return ((val_low & 0xfff0fff) == 0x0202043B && val_low == val_high);
}
-static int __init gicv2_init(void)
+static paddr_t __initdata hbase, dbase, cbase, csize, vbase;
+
+static void __init gicv2_dt_init(void)
{
int res;
-paddr_t hbase, dbase;
-paddr_t cbase, csize;
-paddr_t vbase, vsize;
-uint32_t aliased_offset = 0;
+paddr_t vsize;
const struct dt_device_node *node = gicv2_info.node;
res = dt_device_get_address(node, 0, &dbase, NULL);
@@ -680,6 +679,13 @@ static int __init gicv2_init(void)
if ( csize != vsize )
panic("GICv2: Sizes of GICC (%#"PRIpaddr") and GICV (%#"PRIpaddr")
don't match\n",
csize, vsize);
+}
+
+static int __init gicv2_init(void)
+{
+uint32_t aliased_offset = 0;
+
+gicv2_dt_init();
printk("GICv2 initialization:\n"
"gic_dist_addr=%"PRIpaddr"\n"
@@ -765,7 +771,8 @@ const static struct gic_hw_operations gicv2_ops = {
};
/* Set up the GIC */
-static int __init gicv2_preinit(struct dt_device_node *node, const void *data)
+static int __init gicv2_dt_preinit(struct dt_device_node *node,
+ const void *data)
{
gicv2_info.hw_version = GIC_V2;
gicv2_info.node = node;
@@ -783,7 +790,7 @@ static const struct dt_device_match gicv2_dt_match[]
__initconst =
DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
.dt_match = gicv2_dt_match,
-.init = gicv2_preinit,
+.init = gicv2_dt_preinit,
DT_DEVICE_END
/*
--
2.0.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 01/10] ACPI: check acpi_disabled in acpi_table_parse() and acpi_table_parse_entries()
From: Len Brown
Allow consumers of the acpi_table_parse()/acpi_table_parse_entries() API
to gracefully handle the acpi_disabled=1 case via return value
rather than checking the global flag themselves.
Signed-off-by: Feng Tang
Signed-off-by: Len Brown
[Linux commit e5b8fc6ac158f65598f58dba2c0d52ba3b412f52]
Signed-off-by: Shannon Zhao
---
Cc: Jan Beulich
---
xen/drivers/acpi/tables.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 60c4ab1..39f1223 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -210,6 +210,9 @@ acpi_table_parse_entries(char *id,
unsigned int count = 0;
unsigned long table_end;
+ if (acpi_disabled)
+ return -ENODEV;
+
if (!handler)
return -EINVAL;
@@ -279,6 +282,9 @@ int __init acpi_table_parse(char *id, acpi_table_handler
handler)
{
struct acpi_table_header *table = NULL;
+ if (acpi_disabled)
+ return -ENODEV;
+
if (!handler)
return -EINVAL;
--
2.0.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 10/10] pl011: Refactor pl011 driver to dt and common initialization parts
From: Shannon Zhao
Refactor pl011 driver to dt and common initialization parts. This will
be useful later when acpi specific uart initialization function is
introduced.
Signed-off-by: Parth Dixit
Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
---
xen/drivers/char/pl011.c | 64
1 file changed, 38 insertions(+), 26 deletions(-)
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 67e6df5..7e16294 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -226,12 +226,42 @@ static struct uart_driver __read_mostly pl011_driver = {
.vuart_info = pl011_vuart,
};
+static int __init pl011_uart_init(int irq, u64 addr, u64 size)
+{
+struct pl011 *uart;
+
+uart = &pl011_com;
+uart->irq = irq;
+uart->clock_hz = 0x16e3600;
+uart->baud = BAUD_AUTO;
+uart->data_bits = 8;
+uart->parity= PARITY_NONE;
+uart->stop_bits = 1;
+
+uart->regs = ioremap_nocache(addr, size);
+if ( !uart->regs )
+{
+printk("pl011: Unable to map the UART memory\n");
+return -ENOMEM;
+}
+
+uart->vuart.base_addr = addr;
+uart->vuart.size = size;
+uart->vuart.data_off = DR;
+uart->vuart.status_off = FR;
+uart->vuart.status = 0;
+
+/* Register with generic serial driver. */
+serial_register_uart(SERHND_DTUART, &pl011_driver, uart);
+
+return 0;
+}
+
/* TODO: Parse UART config from the command line */
-static int __init pl011_uart_init(struct dt_device_node *dev,
- const void *data)
+static int __init pl011_dt_uart_init(struct dt_device_node *dev,
+ const void *data)
{
const char *config = data;
-struct pl011 *uart;
int res;
u64 addr, size;
@@ -240,14 +270,6 @@ static int __init pl011_uart_init(struct dt_device_node
*dev,
printk("WARNING: UART configuration is not supported\n");
}
-uart = &pl011_com;
-
-uart->clock_hz = 0x16e3600;
-uart->baud = BAUD_AUTO;
-uart->data_bits = 8;
-uart->parity= PARITY_NONE;
-uart->stop_bits = 1;
-
res = dt_device_get_address(dev, 0, &addr, &size);
if ( res )
{
@@ -262,24 +284,14 @@ static int __init pl011_uart_init(struct dt_device_node
*dev,
printk("pl011: Unable to retrieve the IRQ\n");
return -EINVAL;
}
-uart->irq = res;
-uart->regs = ioremap_nocache(addr, size);
-if ( !uart->regs )
+res = pl011_uart_init(res, addr, size);
+if ( res < 0 )
{
-printk("pl011: Unable to map the UART memory\n");
-return -ENOMEM;
+printk("pl011: Unable to initialize\n");
+return res;
}
-uart->vuart.base_addr = addr;
-uart->vuart.size = size;
-uart->vuart.data_off = DR;
-uart->vuart.status_off = FR;
-uart->vuart.status = 0;
-
-/* Register with generic serial driver. */
-serial_register_uart(SERHND_DTUART, &pl011_driver, uart);
-
dt_device_set_used_by(dev, DOMID_XEN);
return 0;
@@ -293,7 +305,7 @@ static const struct dt_device_match pl011_dt_match[]
__initconst =
DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
.dt_match = pl011_dt_match,
-.init = pl011_uart_init,
+.init = pl011_dt_uart_init,
DT_DEVICE_END
/*
--
2.0.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 09/10] arm/uart: Rename dt-uart.c to arm-uart.c
From: Shannon Zhao
Since we will add ACPI initialization for UART in this file later,
rename it with a generic name.
Signed-off-by: Shannon Zhao
---
v4: split the original patch to renaming this and adding ACPI parts.
---
MAINTAINERS | 2 +-
xen/drivers/char/Makefile | 2 +-
xen/drivers/char/arm-uart.c | 107
xen/drivers/char/dt-uart.c | 107
4 files changed, 109 insertions(+), 109 deletions(-)
create mode 100644 xen/drivers/char/arm-uart.c
delete mode 100644 xen/drivers/char/dt-uart.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 09fe823..5d2b354 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -133,7 +133,7 @@ S: Supported
L: xen-devel@lists.xen.org
F: xen/arch/arm/
F: xen/include/asm-arm/
-F: xen/drivers/char/dt-uart.c
+F: xen/drivers/char/arm-uart.c
F: xen/drivers/char/exynos4210-uart.c
F: xen/drivers/char/omap-uart.c
F: xen/drivers/char/pl011.c
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index aa620fc..aa169d7 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -6,5 +6,5 @@ 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_ARM) += dt-uart.o
+obj-$(CONFIG_ARM) += arm-uart.o
obj-y += serial.o
diff --git a/xen/drivers/char/arm-uart.c b/xen/drivers/char/arm-uart.c
new file mode 100644
index 000..883e615
--- /dev/null
+++ b/xen/drivers/char/arm-uart.c
@@ -0,0 +1,107 @@
+/*
+ * xen/drivers/char/arm-uart.c
+ *
+ * Generic uart retrieved via the device tree
+ *
+ * Julien Grall
+ * Copyright (c) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Configure UART port with a string:
+ * path:options
+ *
+ * @path: full path used in the device tree for the UART. If the path
+ * doesn't start with '/', we assuming that it's an alias.
+ * @options: UART speficic options (see in each UART driver)
+ */
+static char __initdata opt_dtuart[256] = "";
+string_param("dtuart", opt_dtuart);
+
+void __init dt_uart_init(void)
+{
+struct dt_device_node *dev;
+int ret;
+const char *devpath = opt_dtuart;
+char *options;
+
+if ( !console_has("dtuart") )
+return; /* Not for us */
+
+if ( !strcmp(opt_dtuart, "") )
+{
+const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+
+if ( chosen )
+{
+const char *stdout;
+
+ret = dt_property_read_string(chosen, "stdout-path", &stdout);
+if ( ret >= 0 )
+{
+printk("Taking dtuart configuration from
/chosen/stdout-path\n");
+if ( strlcpy(opt_dtuart, stdout, sizeof(opt_dtuart))
+ >= sizeof(opt_dtuart) )
+printk("WARNING: /chosen/stdout-path too long,
truncated\n");
+}
+else if ( ret != -EINVAL /* Not present */ )
+printk("Failed to read /chosen/stdout-path (%d)\n", ret);
+}
+}
+
+if ( !strcmp(opt_dtuart, "") )
+{
+printk("No dtuart path configured\n");
+return;
+}
+
+options = strchr(opt_dtuart, ':');
+if ( options != NULL )
+*(options++) = '\0';
+else
+options = "";
+
+printk("Looking for dtuart at \"%s\", options \"%s\"\n", devpath, options);
+if ( *devpath == '/' )
+dev = dt_find_node_by_path(devpath);
+else
+dev = dt_find_node_by_alias(devpath);
+
+if ( !dev )
+{
+printk("Unable to find device \"%s\"\n", devpath);
+return;
+}
+
+ret = device_init(dev, DEVICE_SERIAL, options);
+
+if ( ret )
+printk("Unable to initialize dtuart: %d\n", ret);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/dt-uart.c b/xen/drivers/char/dt-uart.c
deleted file mode 100644
index d599322..000
--- a/xen/drivers/char/dt-uart.c
+++ /dev/null
@@ -1,107 +0,0 @@
-/*
- * xen/drivers/char/dt-uart.c
- *
- * Generic uart retrieved via the device tree
- *
- * Julien Grall
- * Copyright (c) 2013 Linaro Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public Lice
[Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent
From: Shannon Zhao
Current acpi_os_map_memory is specific to x86. Refactor it to be
architecturally independent.
Cc: Jan Beulich
Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
---
xen/arch/x86/acpi/lib.c | 16
xen/drivers/acpi/osl.c | 12 +---
xen/include/xen/acpi.h | 2 ++
3 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
index cc15ea3..1e2e124 100644
--- a/xen/arch/x86/acpi/lib.c
+++ b/xen/arch/x86/acpi/lib.c
@@ -33,6 +33,22 @@ u8 __read_mostly acpi_disable_value;
u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
{[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+{
+ if (system_state >= SYS_STATE_active) {
+ mfn_t mfn = _mfn(PFN_DOWN(phys));
+ unsigned int offs = phys & (PAGE_SIZE - 1);
+
+ /* The low first Mb is always mapped. */
+ if ( !((phys + size - 1) >> 20) )
+ return __va(phys);
+ return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
+ PAGE_HYPERVISOR_NOCACHE) + offs;
+ }
+ return __acpi_map_table(phys, size);
+}
+
/*
* Important Safety Note: The fixed ACPI page numbers are *subtracted*
* from the fixed base. That's why we start at FIX_ACPI_END and
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index ce15470..dc971af 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -86,17 +86,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
void __iomem *
acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
{
- if (system_state >= SYS_STATE_active) {
- mfn_t mfn = _mfn(PFN_DOWN(phys));
- unsigned int offs = phys & (PAGE_SIZE - 1);
-
- /* The low first Mb is always mapped. */
- if ( !((phys + size - 1) >> 20) )
- return __va(phys);
- return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
- PAGE_HYPERVISOR_NOCACHE) + offs;
- }
- return __acpi_map_table(phys, size);
+ return arch_acpi_os_map_memory(phys, size);
}
void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index 65e53a6..9d90d6b 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -54,6 +54,8 @@ typedef int (*acpi_table_handler) (struct acpi_table_header
*table);
typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header,
const unsigned long end);
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size);
unsigned int acpi_get_processor_id (unsigned int cpu);
char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
int acpi_boot_init (void);
--
2.0.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 00/10] Refactor DT specific codes preparing for ACPI support on ARM64
From: Shannon Zhao These patches are Part 2 of the previous patch set I sent which adds ACPI support for arm64 on Xen[1]. Split them as an individual set for convenient reviewing. The first two patches ports two ACPI changes from Linux kernel, which are missed at Part 1. The second three patches solve pmstat compiling errors for ACPI on ARM64 and refactor acpi_os_map_memory to be architecturally independent. The last five patches refactor some ARM codes into generic and DT specific parts. Cc: Jan Beulich Thanks, Shannon [1] http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg01831.html Ashwin Chaugule (1): ACPI / table: Add new function to get table entries Len Brown (1): ACPI: check acpi_disabled in acpi_table_parse() and acpi_table_parse_entries() Parth Dixit (1): acpi/pmstat: Build pmstat for x86 only Shannon Zhao (7): acpi: Don't do traditional BIOS table scan for ARM64 acpi: Refactor acpi_os_map_memory to be architecturally independent arm/smpboot: Move dt specific code in smp to seperate functions arm/gic-v2: Refactor gicv2_init into generic and dt specific parts arm/gic-v3: Refactor gicv3_init into generic and dt specific parts arm/uart: Rename dt-uart.c to arm-uart.c pl011: Refactor pl011 driver to dt and common initialization parts MAINTAINERS| 2 +- xen/arch/arm/arm64/smpboot.c | 7 ++- xen/arch/arm/gic-v2.c | 21 --- xen/arch/arm/gic-v3.c | 114 - xen/arch/arm/smpboot.c | 29 ++ xen/arch/x86/acpi/lib.c| 16 ++ xen/common/sysctl.c| 2 +- xen/drivers/acpi/Makefile | 2 +- xen/drivers/acpi/osl.c | 12 +--- xen/drivers/acpi/tables.c | 56 ++ xen/drivers/acpi/tables/tbxfroot.c | 7 +++ xen/drivers/char/Makefile | 2 +- xen/drivers/char/arm-uart.c| 107 ++ xen/drivers/char/dt-uart.c | 107 -- xen/drivers/char/pl011.c | 64 - xen/include/xen/acpi.h | 6 ++ 16 files changed, 322 insertions(+), 232 deletions(-) create mode 100644 xen/drivers/char/arm-uart.c delete mode 100644 xen/drivers/char/dt-uart.c -- 2.0.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 04/10] acpi: Don't do traditional BIOS table scan for ARM64
From: Shannon Zhao
With the addition of ARM64 that does not have a traditional BIOS to
scan, stub out acpi_find_root_pointer to do nothing for ARM.
Cc: Jan Beulich
Signed-off-by: Shannon Zhao
---
v4: stub out acpi_find_root_pointer fro ARM
---
xen/drivers/acpi/tables/tbxfroot.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/drivers/acpi/tables/tbxfroot.c
b/xen/drivers/acpi/tables/tbxfroot.c
index 0efb603..90e52e9 100644
--- a/xen/drivers/acpi/tables/tbxfroot.c
+++ b/xen/drivers/acpi/tables/tbxfroot.c
@@ -49,6 +49,12 @@
#define _COMPONENT ACPI_TABLES
ACPI_MODULE_NAME("tbxfroot")
+#ifdef CONFIG_ARM
+acpi_status __init acpi_find_root_pointer(acpi_native_uint * table_address)
+{
+ return_ACPI_STATUS(AE_NOT_FOUND);
+}
+#else
/* Local prototypes */
static u8 *acpi_tb_scan_memory_for_rsdp(u8 * start_address, u32 length);
@@ -271,3 +277,4 @@ static u8 *__init acpi_tb_scan_memory_for_rsdp(u8 *
start_address, u32 length)
start_address));
return_PTR(NULL);
}
+#endif
--
2.0.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 06/10] arm/smpboot: Move dt specific code in smp to seperate functions
From: Shannon Zhao
Partition smp initialization functions into generic and dt specific
parts, this will be useful when introducing new functions for smp
initialization based on acpi.
Signed-off-by: Parth Dixit
Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
---
xen/arch/arm/arm64/smpboot.c | 7 ++-
xen/arch/arm/smpboot.c | 29 ++---
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
index 62e6abb..7928f69 100644
--- a/xen/arch/arm/arm64/smpboot.c
+++ b/xen/arch/arm/arm64/smpboot.c
@@ -70,7 +70,7 @@ int __init arch_smp_init(void)
return 0;
}
-int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
+static int __init dt_arch_cpu_init(int cpu, struct dt_device_node *dn)
{
const char *enable_method;
@@ -94,6 +94,11 @@ int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
return 0;
}
+int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
+{
+return dt_arch_cpu_init(cpu, dn);
+}
+
int __init arch_cpu_up(int cpu)
{
if ( !smp_enable_ops[cpu].prepare_cpu )
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 00b2b2a..b6119d1 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -92,7 +92,7 @@ smp_clear_cpu_maps (void)
* MPIDR values related to logical cpus
* Code base on Linux arch/arm/kernel/devtree.c
*/
-void __init smp_init_cpus(void)
+static void __init dt_smp_init_cpus(void)
{
register_t mpidr;
struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
@@ -106,16 +106,6 @@ void __init smp_init_cpus(void)
bool_t bootcpu_valid = 0;
int rc;
-/* scan the DTB for a PSCI node and set a global variable */
-psci_init();
-
-if ( (rc = arch_smp_init()) < 0 )
-{
-printk(XENLOG_WARNING "SMP init failed (%d)\n"
- "Using only 1 CPU\n", rc);
-return;
-}
-
mpidr = boot_cpu_data.mpidr.bits & MPIDR_HWID_MASK;
if ( !cpus )
@@ -243,6 +233,23 @@ void __init smp_init_cpus(void)
}
}
+void __init smp_init_cpus(void)
+{
+int rc;
+
+/* initialize PSCI and set a global variable */
+psci_init();
+
+if ( (rc = arch_smp_init()) < 0 )
+{
+printk(XENLOG_WARNING "SMP init failed (%d)\n"
+ "Using only 1 CPU\n", rc);
+return;
+}
+
+dt_smp_init_cpus();
+}
+
int __init
smp_get_max_cpus (void)
{
--
2.0.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 08/10] arm/gic-v3: Refactor gicv3_init into generic and dt specific parts
From: Shannon Zhao
Refactor gic-v3 related functions into dt and generic parts. This will be
helpful when adding acpi support for gic-v3.
Signed-off-by: Shannon Zhao
---
v4: Use INVALID_PADDR and move ioremap to common init function
---
xen/arch/arm/gic-v3.c | 114 +++---
1 file changed, 61 insertions(+), 53 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a245b56..65a4de6 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1138,41 +1138,14 @@ static int __init cmp_rdist(const void *a, const void
*b)
return ( l->base < r->base) ? -1 : 0;
}
+static paddr_t __initdata dbase = INVALID_PADDR, vbase = INVALID_PADDR;
+static paddr_t __initdata cbase = INVALID_PADDR, csize = INVALID_PADDR;
+
/* If the GICv3 supports GICv2, initialize it */
-static void __init gicv3_init_v2(const struct dt_device_node *node,
- paddr_t dbase)
+static void __init gicv3_init_v2(void)
{
-int res;
-paddr_t cbase, csize;
-paddr_t vbase, vsize;
-
-/*
- * For GICv3 supporting GICv2, GICC and GICV base address will be
- * provided.
- */
-res = dt_device_get_address(node, 1 + gicv3.rdist_count,
-&cbase, &csize);
-if ( res )
-return;
-
-res = dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
-&vbase, &vsize);
-if ( res )
-return;
-
-/*
- * We emulate a vGICv2 using a GIC CPU interface of GUEST_GICC_SIZE.
- * So only support GICv2 on GICv3 when the virtual CPU interface is
- * at least GUEST_GICC_SIZE.
- */
-if ( vsize < GUEST_GICC_SIZE )
-{
-printk(XENLOG_WARNING
- "GICv3: WARNING: Not enabling support for GICv2 compat mode.\n"
- "Size of GICV (%#"PRIpaddr") must at least be %#llx.\n",
- vsize, GUEST_GICC_SIZE);
+if ( cbase == INVALID_PADDR || vbase == INVALID_PADDR )
return;
-}
printk("GICv3 compatible with GICv2 cbase %#"PRIpaddr" vbase
%#"PRIpaddr"\n",
cbase, vbase);
@@ -1180,20 +1153,12 @@ static void __init gicv3_init_v2(const struct
dt_device_node *node,
vgic_v2_setup_hw(dbase, cbase, csize, vbase, 0);
}
-/* Set up the GIC */
-static int __init gicv3_init(void)
+static void __init gicv3_dt_init(void)
{
struct rdist_region *rdist_regs;
int res, i;
-uint32_t reg;
const struct dt_device_node *node = gicv3_info.node;
-paddr_t dbase;
-
-if ( !cpu_has_gicv3 )
-{
-dprintk(XENLOG_ERR, "GICv3: driver requires system register
support\n");
-return -ENODEV;
-}
+paddr_t vsize;
res = dt_device_get_address(node, 0, &dbase, NULL);
if ( res )
@@ -1203,14 +1168,6 @@ static int __init gicv3_init(void)
panic("GICv3: Found unaligned distributor address %"PRIpaddr"",
dbase);
-gicv3.map_dbase = ioremap_nocache(dbase, SZ_64K);
-if ( !gicv3.map_dbase )
-panic("GICv3: Failed to ioremap for GIC distributor\n");
-
-reg = readl_relaxed(GICD + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
-if ( reg != GIC_PIDR2_ARCH_GICv3 && reg != GIC_PIDR2_ARCH_GICv4 )
- panic("GICv3: no distributor detected\n");
-
if ( !dt_property_read_u32(node, "#redistributor-regions",
&gicv3.rdist_count) )
gicv3.rdist_count = 1;
@@ -1248,6 +1205,57 @@ static int __init gicv3_init(void)
panic("GICv3: Cannot find the maintenance IRQ");
gicv3_info.maintenance_irq = res;
+/*
+ * For GICv3 supporting GICv2, GICC and GICV base address will be
+ * provided.
+ */
+res = dt_device_get_address(node, 1 + gicv3.rdist_count,
+&cbase, &csize);
+if ( res )
+return;
+
+res = dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
+&vbase, &vsize);
+if ( res )
+return;
+
+/*
+ * We emulate a vGICv2 using a GIC CPU interface of GUEST_GICC_SIZE.
+ * So only support GICv2 on GICv3 when the virtual CPU interface is
+ * at least GUEST_GICC_SIZE.
+ */
+if ( vsize < GUEST_GICC_SIZE )
+{
+printk(XENLOG_WARNING
+ "GICv3: WARNING: Not enabling support for GICv2 compat mode.\n"
+ "Size of GICV (%#"PRIpaddr") must at least be %#llx.\n",
+ vsize, GUEST_GICC_SIZE);
+return;
+}
+}
+
+/* Set up the GIC */
+static int __init gicv3_init(void)
+{
+int res, i;
+uint32_t reg;
+
+if ( !cpu_has_gicv3 )
+{
+dprintk(XENLOG_ERR, "GICv3: driver requires system register
support\n");
+return -ENODEV;
+}
+
+gicv3_dt_init();
+
+gicv3.map_dbase = ioremap_nocache(dbase, SZ_64K);
+if ( !gicv3.map_dbase )
+panic("GICv3: Failed to ioremap for GIC distributor\n");
+
+reg = readl_relaxed(GICD + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
+if ( reg !=
[Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough
This patch was just a initial patch, not sure whether this way
is ok from you side for handlding clk when doing platform device
passhthrough. Any comments are appreciated, and your comments may
give me a better direction.
Patch was basically tested with passthrough uart2 to DomU on
freescale i.MX7D(Cortex-A7 Dual) platform with two linux os
running based on xen hypervisor.
I have not written the userspace libxl pvclk code, so I use the libxl pvusb
code for test, only need to change the compatible string in this patch
from "vclk" to "vusb", and "clk-ring-ref" to "urb-ring-ref". If this patch
is a acceptable way, I'll begin coding the userspace libxl pvclk.
I follow this doc [1] to do platform device passthrough, but I also
met the issue how to handle clk in the DomU guest. I do not want
to remove the clk api such clk_prepare_enable/disable and etc in the
uart driver, since it work well without xen. But if want the uart driver
to work well in DomU, I need to take care the clk usage. Without
this patch, clk_prepare_enable/disable will fail because no clk tree
in DomU. So I wrote this patch,
Since xen pv use asynchronous notification, clk_enable/disable can not
be implemented in the map, so I use clk_prepare_enable/disable in backend
to map clk_prepare/unprepare in frontend.
Partial dts for DomU linux:
"
aliases {
serial0 = &uart2;
clk0 = &clks;
};
passthrough {
compatible = "simple-bus";
ranges; #address-cells = <1>;
#size-cells = <1>;
clks: clks {
compatible = "xen,xen-clk";
#clock-cells = <1>;
clock-output-names = "uart2_root_clk";
};
uart2: serial@1000 {
compatible = "fsl,imx7d-uart", "fsl,imx6q-uart",
"fsl,imx21-uart";
reg = <0x1000 0x1>;
interrupts = <0 27 4>;
interrupt-parent = <65000>;
clocks = <&clks 0>, <&clks 0>;
clock-names = "ipg", "per";
};
};
"
Xen front clk driver will register itself by probing "xen,xen-clk", register
clk tree by parsing "clock-output-names" and register as ROOT clk.
See the uart2 node, ipg and per clks are also registered in Dom0,
when DomU want to prepare or set rate for the ipg clk, DomU will use pvclk
interface to pass the name "ipg" and the ID(PREPARE, SET_RATE and etc)to Dom0,
Dom0 will use __clk_lookup to find out the "struct clk *" structure and
prepare_enable or set_rate according to the ID from DomU. The ID is defined
in clkif.h in this patch.
The mapping between frontend and backend is as following:
Frontend Backend
clk_prepare clk_prepare_enable
clk_unprepare clk_unprepare_disable
clk_set_rateclk_set_rate
clk_get_rateclk_get_rate
Frontend work flow example:
1. clk_prepare("ipg")
|->ID: PREPARE, name: "ipg" packed into a structure
|->notify backend
2. wait_completion
Dom0 finished clk_prepare_enable and send event channel interrupt
to DomU, In DomU frontend interrupt handler, call complete to wakeup.
[1] https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf
Signed-off-by: Peng Fan
Cc: xen-de...@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Julien Grall
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Michael Turquette
Cc: Stephen Boyd
---
drivers/clk/Makefile | 2 +
drivers/clk/xen/Makefile | 1 +
drivers/clk/xen/clk-xen.c| 197 ++
drivers/clk/xen/xen-clkback.c| 357
drivers/clk/xen/xen-clkfront.c | 432 +++
include/xen/interface/io/clkif.h | 41
6 files changed, 1030 insertions(+)
create mode 100644 drivers/clk/xen/Makefile
create mode 100644 drivers/clk/xen/clk-xen.c
create mode 100644 drivers/clk/xen/xen-clkback.c
create mode 100644 drivers/clk/xen/xen-clkfront.c
create mode 100644 include/xen/interface/io/clkif.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 820714c..7668ecc 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -15,6 +15,8 @@ ifeq ($(CONFIG_OF), y)
obj-$(CONFIG_COMMON_CLK) += clk-conf.o
endif
+obj-$(CONFIG_XEN) += xen/
+
# hardware specific clock types
# please keep this section sorted lexicographically by file/directory path name
obj-$(CONFIG_MACH_ASM9260) += clk-asm9260.o
diff --git a/drivers/clk/xen/Makefile b/drivers/clk/xen/Makefile
new file mode 100644
index 000..60abe25
--- /dev/null
+++ b/drivers/clk/xen/Makefile
@@ -0,0 +1 @@
+obj-y += clk-xen.o xen-clkfront.o xen-clkback.o
diff --git a/drivers/clk/xen/clk-xen.c b/drivers/clk/xen/clk-xen.c
new file mode 100644
in
[Xen-devel] [seabios baseline-only test] 38644: tolerable FAIL
This run is configured for baseline tests only. flight 38644 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38644/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 38639 test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail like 38639 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: seabios 9720484aec619d6414bbeed90e203f752742fa5c baseline version: seabios 3e8d75f3bef0f36a807303d58523ef5eba4a386f Last test of basis38639 2016-01-15 01:55:58 Z1 days Testing same since38644 2016-01-16 00:23:21 Z0 days1 attempts People who touched revisions under test: Kevin O'Connor jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xl-qemuu-winxpsp3pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 9720484aec619d6414bbeed90e203f752742fa5c Author: Kevin O'Connor Date: Sun Jan 10 13:26:26 2016 -0500 kbd: Refactor capslock and numlock handling Simplify the scan_to_keycode[] table by implementing numlock and capslock checking in the code. Signed-off-by: Kevin O'Connor commit ea5d60a1542e6a95f5a737ed6f886006c7120074 Author: Kevin O'Connor Date: Sun Jan 10 13:01:48 2016 -0500 kbd: Don't treat scancode and asciicode as separate values The scancode/asciicode pair can be more easily handled as a single 16bit value. Signed-off-by: Kevin O'Connor commit a48f602c2099d3bd325729fe64e5b237d1b597f8 Author: Kevin O'Connor Date: Tue Jan 12 14:22:33 2016 -0500 post: Always set HaveRunPost prior to setting any other global variable The HaveRunPost flag controls whether post or reboot handling is entered on a reset signal. The flag needs to be set before any other global variable because an external reboot signal could occur at any time. (If any global variable is modified prior to setting HaveRunPost then the code might enter post with global variables in a dirty state.) Signed-off-by: Kevin O'Connor commit b837e68d5a6c1a5945513f1995875445a1594c8a Author: Kevin O'Connor Date: Mon Nov 9 15:00:19 2015 -0500 resume: Make KVM soft reboot loop detection more flexible Move the check for soft reboot loops from resume.c to sha
