[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