>>> On 06.01.17 at 18:28, wrote:
> On 01/06/2017 10:43 AM, Jan Beulich wrote:
>
> On 06.01.17 at 17:24, wrote:
>>> On 01/06/2017 08:58 AM, Jan Beulich wrote:
>>> On 05.01.17 at 23:39, wrote:
> @@ -1118,6 +1118,20 @@ static void __init ns16550_parse_port_config(
>uart
>>> On 06.01.17 at 19:34, wrote:
> Jan Beulich writes ("Re: [PATCH v2] ns16550: Add command line parsing
> adjustments"):
>> On 06.01.17 at 17:24, wrote:
>> Well, as you may have seen, things are getting complicated here:
>> The two currently-last elements are permitted only with
>> CONFIG_HAS_P
>>> On 09.01.17 at 02:19, wrote:
> On 17-01-06 12:04:36, Wei Liu wrote:
>> On Wed, Dec 14, 2016 at 12:08:01PM +0800, Yi Sun wrote:
>> > This patch implements xl/xc changes to support get HW info
>> > for L2 CAT.
>> >
>> > 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
>> > info.
>> >
>>> On 07.01.17 at 07:05, wrote:
> Question: Why this address is not mapped?. If mapped where this va is
> mapped?.
Well, I think this is the wrong question to ask. Why would it be mapped
if there's no memory there?
> (XEN) Walking Hypervisor VA 0x847f on CPU0 via TTBR
> 0xffcf
flight 104080 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104080/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 02263214ef20f1577b62f810016dce801aa95b4f
baseline version:
ovmf 3613af913983148a3865e
>>> On 06.01.17 at 21:11, wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 06.01.17 at 21:11, wrote:
> As the comment says, the guest shouldn't be able to change X86_EFLAGS_TF,
> although we don't care which value it currently has.
If we don't care about its value, why bother checking? IF and IOPL
are different, see XSA-202 (albeit with that workaround, strictly
> -Original Message-
> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> Sent: 06 January 2017 20:09
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ; Stefano
> Stabellini
> Subject: Re: [RFC] netif: staging grants for requests
>
> On 01/06/2017 0
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 06 January 2017 19:18
> To: Paul Durrant
> Cc: Joao Martins ; xen-
> de...@lists.xenproject.org; Andrew Cooper ;
> Wei Liu ; Stefano Stabellini
> Subject: RE: [RFC] netif: staging grants for requests
>
On Mon, Jan 09, 2017 at 01:31:35AM -0700, Jan Beulich wrote:
> >>> On 09.01.17 at 02:19, wrote:
> > On 17-01-06 12:04:36, Wei Liu wrote:
> >> On Wed, Dec 14, 2016 at 12:08:01PM +0800, Yi Sun wrote:
> >> > This patch implements xl/xc changes to support get HW info
> >> > for L2 CAT.
> >> >
> >> >
On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
>
> In fact, all headers under uapi directorie
flight 104078 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104078/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-amd64 15 guest-saverestore.2 fail pass in 104075
Regressions which are regarded a
On Mon, Jan 09, 2017 at 09:24:54AM +0800, Yi Sun wrote:
> On 17-01-06 12:04:43, Wei Liu wrote:
> > On Wed, Dec 14, 2016 at 12:08:02PM +0800, Yi Sun wrote:
> > > - 'xl psr-cat-show' is updated to show CBM of a domain
> > > according to input cache level.
> > >
> > > Examples:
> > > root@:~$ xl ps
On Thu, 2017-01-05 at 15:19 +, Wei Liu wrote:
> On Thu, Jan 05, 2017 at 04:12:46PM +0100, Cedric Bosdonnat wrote:
> > On Thu, 2017-01-05 at 15:01 +, Wei Liu wrote:
> > > On Wed, Jan 04, 2017 at 04:49:25PM +0100, Cedric Bosdonnat wrote:
> > > > On Wed, 2017-01-04 at 15:07 +, Wei Liu wrot
On 09/01/17 08:53, Jan Beulich wrote:
On 06.01.17 at 21:11, wrote:
>> As the comment says, the guest shouldn't be able to change X86_EFLAGS_TF,
>> although we don't care which value it currently has.
> If we don't care about its value, why bother checking? IF and IOPL
> are different, see XSA
On Sun, Jan 8, 2017 at 4:20 AM, Marc Tousignant wrote:
> I first tried upgrading to 4.8 but then none of my VM’s would launch. I’m
> guessing there was a change to the config files that I did not look in to.
>
> I then tried going to 4.6.2 before, but the issue happens there as well.
>
> I was abl
>>> On 09.01.17 at 11:48, wrote:
> On 09/01/17 08:53, Jan Beulich wrote:
> On 06.01.17 at 21:11, wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -3395,7 +3395,8 @@ static int emulate_privileged_op(struct cpu_user_regs
>>> *regs)
>>> * Un-mirror virtualized s
Featuresets will eventually live only once in a struct cpuid_policy, but lots
of code currently uses the global featuresets as a linear bitmap. Remove the
existing global *_featureset bitmaps, replacing them with *_policy objects
containing named featureset words and a fs[] linear bitmap.
Two new
Longterm, pv_cpuid() and hvm_cpuid() will be merged into a single
guest_cpuid(), which is also capable of working outside of current context.
To aid this transtion, introduce guest_cpuid() with the intended API, which
simply defers back to pv_cpuid() or hvm_cpuid() as appropriate.
Introduce struc
Introduce init_domain_cpuid_policy() to allocate an appropriate cpuid policy
for the domain (currently the domains maximum applicable policy), and call it
during domain construction.
init_guest_cpuid() now needs calling before dom0 is constructed.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Be
Presented herewith is v2 of the first part of improvement work to support full
per-domain CPUID policies. More work is pending on top of this series.
This series is available in git form from:
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-cpuid-v2
Tes
struct cpuid_policy will eventually be a complete replacement for the cpuids[]
array, with a fixed layout and named fields to allow O(1) access to specific
information.
For now, the CPUID content is capped at the 0xd and 0x801c leaves, which
matches the maximum policy that the toolstack will g
Introduce recalculate_cpuid_policy() which clamps a CPUID policy based on the
domains current restrictions.
Each adjustment introduced here mirrors what currently happens in
{pv,hvm}_cpuid(), although some logic is expressed differently.
* The clearing X86_FEATURE_LM for 32bit PV guests, sanitis
Pick the appropriate cpuid_policy object rather than using hvm_cpuid() or
boot_cpu_data. This breaks the dependency on current.
As data is read straight out of cpuid_policy, there is no need to work around
the fact that X86_FEATURE_SYSCALL might be clear because of the dynamic
adjustment in hvm_c
... rather than from the legacy path. Update the API to match guest_cpuid(),
and remove its dependence on current.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
v2:
* Introduce a break statement into guest_cpuid().
* Retain the explicit zeroing of SP and Service branch.
It greatly aids the readibility of code to express feature checks with their
direct name (e.g. p->basic.mtrr or p->extd.lm), rarther that by a field and a
bitmask. gen-cpuid.py is augmented to calculate a suitable declaration to
live in a union with the underlying feature word.
gen-cpuid.py doesn
... rather than from the legacy path. Update the API to match guest_cpuid(),
and remove its dependence on current.
Make use of guest_cpuid() unconditionally zeroing res to avoid repeated
re-zeroing. To use a const struct domain, domain_cpuid() needs to be
const-corrected.
Signed-off-by: Andrew
On Mon, Jan 09, 2017 at 11:39:06AM +0100, Cedric Bosdonnat wrote:
> On Thu, 2017-01-05 at 15:19 +, Wei Liu wrote:
> > On Thu, Jan 05, 2017 at 04:12:46PM +0100, Cedric Bosdonnat wrote:
> > > On Thu, 2017-01-05 at 15:01 +, Wei Liu wrote:
> > > > On Wed, Jan 04, 2017 at 04:49:25PM +0100, Cedri
More work is required before maxphysaddr can be read straight out of the
cpuid_policy block, but in the meantime hvm_cpuid() wants to disappear so
update the code to use the newer interface.
Use the behaviour of max_leaf handling (returning all zeros) to avoid a double
call into guest_cpuid().
Si
Clamp the toolstack-providied max_leaf values in recalculate_cpuid_policy(),
causing the per-domain policy to have guest-accurate data.
Have guest_cpuid() exit early if a requested leaf is out of range, rather than
falling into the legacy path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
This avoids hvm_cpuid() recursing into itself, and the MSR paths using
hvm_cpuid() to obtain information which is directly available.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 95 +++---
1 file changed, 29 inse
This avoids refering back to domain_cpuid() or native CPUID to obtain
information which is directly available.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/arch/x86/traps.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/xen/arch/x86/
Derive host_policy from raw_policy, and {pv,hvm}_max_policy from host_policy.
Clamp the raw values to the maximum we will offer to guests.
This simplifies the PV and HVM policy calculations, removing the need for an
intermediate linear host_featureset bitmap.
Signed-off-by: Andrew Cooper
Reviewe
All callers of pv_cpuid() and hvm_cpuid() (other than guest_cpuid() legacy
path) have been removed from the codebase. Move them into cpuid.c to avoid
any further use, leaving guest_cpuid() as the sole API to use.
This is purely code motion, with no functional change.
Signed-off-by: Andrew Cooper
Reuse the logic in hvm_cr4_guest_valid_bits() instead of duplicating it.
This fixes a bug to do with the handling of X86_CR4_PCE. The RDPMC
instruction predate the architectural performance feature, and has been around
since the P6. X86_CR4_PCE is like X86_CR4_TSD and only controls whether RDPMC
... rather than dynamically clamping against the PV maximum policy.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v2:
* Spelling fix in the commit message
---
xen/arch/x86/domctl.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/domctl.
This avoids calling into hvm_cpuid() to obtain information which is directly
available. In particular, this avoids the need to overload flag_dr_dirty
because of hvm_cpuid() being unavailable in svm_save_dr().
flag_dr_dirty is returned to a boolean (as it was before c/s c097f549 which
introduced t
All per-domain policy data concerning leaf 7 is accurate. Handle it all in
guest_cpuid() by reading out of the raw array block, and introduing a dynamic
adjustment for OSPKE.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* Extend the comment concerning dynamic adjustments out of curren
Alter the function to return the valid CR4 bits, rather than the invalid CR4
bits. This will allow reuse in other areas of code.
Pick the appropriate cpuid_policy object rather than using hvm_cpuid() or
boot_cpu_data. This breaks the dependency on current.
Signed-off-by: Andrew Cooper
Reviewed
With most uses of the *_featureset API removed, the remaining uses are only
during XEN_SYSCTL_get_cpu_featureset, init_guest_cpuid(), and
recalculate_cpuid_policy(), none of which are hot paths.
Drop the temporary infrastructure, and have the current users recreate the
linear bitmap using cpuid_po
... rather than performing runtime adjustments. This is safe now that
recalculate_cpuid_policy() perfoms suitable sanitisation when the policy data
is loaded.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/arch/x86/traps.c | 44
1 fil
This allows the compiler to have a far easier time inlining the legacy paths
into guest_cpuid(), and avoids the need to have a full struct cpu_user_regs in
the guest_cpuid() stack frame.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v2:
* Reduce scope of guest_cpu_user_regs().
* Dr
More work is required before LWP details can be read straight out of the
cpuid_policy block, but in the meantime hvm_cpuid() wants to disappear so
update the code to use the newer interface.
Signed-off-by: Andrew Cooper
Reviewed-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
v2:
* Reduce sco
... rather than performing runtime adjustments.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 113 +++--
1 file changed, 44 insertions(+), 69 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm
On Thu, Nov 24, Olaf Hering wrote:
> Backport from qemu-2.8:
> Update unplug in Xen HVM guests to cover more cases.
> The patches are used since years in the SUSE xen-tools package.
Are these patches in the review queue, or did they get dropped?
Olaf
signature.asc
Description: PGP signature
__
flight 104081 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104081/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 133834858a3ab5ba61ca1dc2bb37d322095fcf07
baseline version:
ovmf 02263214ef20f1577b62f
On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
>
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> index a53cdb8f068c..c48fee3d7b3b 100644
> --- a/arch/arm/include/asm/types.h
> +++ b/arch/arm/include/asm/types.h
> @@ -1,40 +1,6 @@
> #ifndef _ASM_TYPE
On Friday, January 6, 2017 10:43:55 AM CET Nicolas Dichtel wrote:
> diff --git a/arch/nios2/include/uapi/asm/setup.h
> b/arch/nios2/include/uapi/asm/setup.h
> new file mode 100644
> index ..8d8285997ba8
> --- /dev/null
> +++ b/arch/nios2/include/uapi/asm/setup.h
> @@ -0,0 +1,6 @@
> +#
Hello,
We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
to eat up all the RAM it can:
(XEN) [ 394.379760] d1v1 Over-allocation for domain 1: 524545 > 524544
This leads to a problem with xen-access, speci
On 09/01/17 11:03, Andrew Cooper wrote:
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 09d9959..fee4b17 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -115,6 +115,11 @@ long arch_do_domctl(struct xen_domctl *domctl, struct
> domain *d,
>
>
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 09 January 2017 11:03
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant
> Subject: [PATCH v2 06/25] x86/hvm: Dispatch cpuid_viridian_leaves() from
> guest_cpuid()
>
> ... rather than fr
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 09 January 2017 11:03
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Jun
> Nakajima ; Kevin Tian ;
> Boris Ostrovsky ; Suravee Suthikulpanit
>
> Subject: [PATCH v2 01/25] x86/cpuid:
On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> Here is the v2 of this series. The first 5 patches are just cleanup: some
> exported headers were still under a non-uapi directory.
Since this is meant as a cleanup, I commented on this to point out a cleaner
way to do the same.
>>> On 09.01.17 at 12:36, wrote:
> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
> to eat up all the RAM it can:
>
> (XEN) [ 394.379760] d1v1 Over-allocation for domain 1: 524545 > 524544
>
> This l
On 01/09/2017 01:52 PM, Jan Beulich wrote:
On 09.01.17 at 12:36, wrote:
>> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
>> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
>> to eat up all the RAM it can:
>>
>> (XEN) [ 394.379760] d1v1 Over-allo
On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> diff --git a/arch/arm/include/uapi/asm/Kbuild
> b/arch/arm/include/uapi/asm/Kbuild
> index 46a76cd6acb6..607f702c2d62 100644
> --- a/arch/arm/include/uapi/asm/Kbuild
> +++ b/arch/arm/include/uapi/asm/Kbuild
> @@ -1,23 +1,6 @@
> #
On 09/01/17 11:52, Jan Beulich wrote:
On 09.01.17 at 12:36, wrote:
>> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
>> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
>> to eat up all the RAM it can:
>>
>> (XEN) [ 394.379760] d1v1 Over-allocatio
On Mon, Jan 09, 2017 at 12:33:02PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
> >
> > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> > index a53cdb8f068c..c48fee3d7b3b 100644
> > --- a/arch/arm/include/asm/types.h
> >
flight 68344 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68344/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail like 68305
test-amd64-i386-amd
On 09/01/17 11:36, Razvan Cojocaru wrote:
> Hello,
>
> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
> to eat up all the RAM it can:
>
> (XEN) [ 394.379760] d1v1 Over-allocation for domain 1: 524545 >
On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
>
> In fact, all headers under uapi directorie
On 01/09/2017 08:56 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
>> Sent: 06 January 2017 20:09
>> To: Paul Durrant
>> Cc: xen-de...@lists.xenproject.org; Andrew Cooper
>> ; Wei Liu ; Stefano
>> Stabellini
>> Subject: Re: [RFC] net
On Fri, Jan 06, 2017 at 10:43:59PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 6, 2017 at 10:00 PM, Luis R. Rodriguez wrote:
> > On Wed, Jan 04, 2017 at 11:47:14AM +0200, Andy Shevchenko wrote:
> >> On Tue, Jan 3, 2017 at 11:25 PM, Luis R. Rodriguez
> >> wrote:
> >> > On Thu, Dec 22, 2016 at 03:
Olaf Hering writes ("Re: [Xen-devel] [PATCH qemu-xen-traditional 0/2] Xen HVM
unplug changes"):
> On Thu, Nov 24, Olaf Hering wrote:
> > Backport from qemu-2.8:
> > Update unplug in Xen HVM guests to cover more cases.
> > The patches are used since years in the SUSE xen-tools package.
>
> Are the
Olaf Hering writes ("[PATCH qemu-xen-traditional 1/2] xen_platform: unplug also
SCSI disks"):
> From: Olaf Hering
>
> Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can
> be used by the emulated BIOS to boot from disk. If the HVM domU has also
> PV driver the disk may appear
>>> On 05.12.16 at 08:48, wrote:
> --- a/tools/xenstore/include/xenstore_lib.h
> +++ b/tools/xenstore/include/xenstore_lib.h
> @@ -44,6 +44,7 @@ struct xs_permissions
>
> /* Header of the node record in tdb. */
> struct xs_tdb_record_hdr {
> + uint64_t generation;
> uint32_t num_perm
Commit 9e49dcf67f ("xenstore: add per-node generation counter) changed
the TDB layout, which - in order to not break older xenstored running
on the same system - need to be accompanied by a version bump.
Signed-off-by: Jan Beulich
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -54,7 +5
This run is configured for baseline tests only.
flight 68343 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68343/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3613af913983148a3865e758c2c058912320e4c2
baseline v
c tree for those curious,
its the last patch [1]. This tree is based on linux-next tag next-20170109.
[0] https://lkml.kernel.org/r/20161222023811.21246-1-mcg...@kernel.org
[1]
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170109-linker-tables-v6
Luis R. Rodriguez (14):
When SORT(foo.*) is used the current sed replacements add
SORT(foo.literal foo.*), this breaks linking. Avoid adding
literals for SORT globs, if needed, these need to be added
manually.
Signed-off-by: Luis R. Rodriguez
---
arch/xtensa/kernel/Makefile | 8
1 file changed, 4 insertions(+)
Section ranges are on one of the types of custom sections
types used in Linux. This provides a series of helpers for
defining them and using them. Most importantly this also
enables us to avoid modifying the linker script when we
add a new section range.
It turns out a lot of custom sections are a
On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman wrote:
>> Do not read a pci device's msi message data to see if a pirq was
>> previously configured for the device's msi/msix, as the old pirq was
>> unmapped and may now be in use by anot
If you modify the target asm we currently do not force the
recompilation of the firmware files. The target asm is in
the firmware/Makefile, peg this file as a dependency to
require re-compilation of firmware targets when the asm
changes.
v3: introduced in this series
Signed-off-by: Luis R. Rodrig
Linux makes extensive use of custom ELF header sections,
documentation for these are well scatterred. Unify this
documentation in a central place and provide helpers to
build custom Linux sections.
This also generalizes sections code to enable avoiding
modifying the linker scripts when we want to
A linker table is a data structure that is stitched together from items
in multiple object files. Linux has historically implicitly used linker
tables for ages, however they were all built in an adhoc manner which
requires linker script modifications, per architecture. This adds a
general linker ta
This removes the custom vmlinux.lds.h hacks and uses
the generalized solution for .data entries.
There is much more potential for further fine tuning here
in the future though. For instance, linker tables enable
an extra postfix for order level annotations, this could
easily be used as the KBUILD_
The ending header guard is misplaced. This has no
functional change, this is just an eye-sore.
Signed-off-by: Luis R. Rodriguez
---
include/linux/jump_label.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index a05
Linux provides a rich array of features, enabling each feature
however increases the size of the kernel and there are many
features which users often want disabled. The traditional
solution to this problem is for each feature to have its own
Kconfig symbol, followed by a series of #ifdef statements
This ports built-in firmware to use linker tables,
this replaces the custom section solution with a
generic solution.
This also demos the use of the .rodata linker table.
Tested with 0 built-in firmware, 1 and 2 built-in
firmwares successfully.
v6: rename table macro as suggested by Andy Shevche
Move the __jump_table from the a custom section solution
to a generic solution, this avoiding extra vmlinux.lds.h
customizations.
This also demos the use of the .data linker table and of
the shared asm call push_section_tbl().
Built-in kernel functionality was tested with CONFIG_STATIC_KEYS_SELFT
kprobe makes use of two custom sections, each custom section
is folded into one of the standard Linux sections types as follows,
it currently relies on the linker script to fold the custom section
onto the respective Linux section:
type Linux-section custom section name begin
kprobe makes use of two sections, the one dealing with the actual
kprobes was recently ported using the standard section range API.
The blacklist functionality of kprobes is still using a custom
section and declaring its custom section using the linker script
as follows:
type Linux-section custom
Add a test drivers for linker tables.
v6: rename table macro as suggested by Andy Shevchenko
v5: added this commit for the first time in this series.
Signed-off-by: Luis R. Rodriguez
---
lib/Kconfig.debug| 6 +
lib/Makefile | 1 +
lib/test
This will be used later by the userspace linker table.
Signed-off-by: Luis R. Rodriguez
---
tools/include/linux/compiler.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h
index 556c991de212..6321265df00a 100644
--- a/tools/inc
This adds __used, to be used later in the userspace linker-tables
sandbox. If any userspace applicaiton wants to override they can
add their own definition and then use include_next.
This definition should probably suffice for most uses cases though.
Signed-off-by: Luis R. Rodriguez
---
tools/i
This v3 only modifies the tools sandbox to adjust for the linker tables
macro renames suggested by Andy Shevchenko. It applies after the kernel
changes, a public tree is available with both series applied [0] based on
linux-next tag next-20170109, if you pull from there please drop the last
patch
Start off with just __ref -- we enalbe you to override, if you do
that then you can define your own. The way you'd use this, if you
do override, is define your own __ref and then use include_next.
Signed-off-by: Luis R. Rodriguez
---
tools/include/linux/init.h | 9 +
1 file changed, 9 in
This will be used later by the linker-table userspace sandbox.
Signed-off-by: Luis R. Rodriguez
---
tools/include/linux/export.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tools/include/linux/export.h b/tools/include/linux/export.h
index d07e586b9ba0..cb7d6b490e0
This will be used later by the userspace linker-tables sandbox.
As a convenience, include bug.h on kernel.h -- this is not done
on upstream kernel.h, however most header files do include bug.h
eventually, if we were to only add the ones that need it we'd
need to copy a lot of headers to tools for t
>>> On 09.01.17 at 12:03, wrote:
> @@ -215,6 +218,39 @@ const uint32_t * __init lookup_deep_deps(uint32_t
> feature)
> return NULL;
> }
>
> +void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> + uint32_t subleaf, struct cpuid_leaf *res)
> +{
> +const struct vcpu *c
On 09/01/17 15:04, Jan Beulich wrote:
On 09.01.17 at 12:03, wrote:
>> @@ -215,6 +218,39 @@ const uint32_t * __init lookup_deep_deps(uint32_t
>> feature)
>> return NULL;
>> }
>>
>> +void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>> + uint32_t subleaf, struct cpu
Often all is needed is these small helpers, instead of compiler.h
or a full kprobes.h. This is important for asm helpers, in fact even
some asm/kprobes.h make use of these helpers... instead just keep a
generic asm file with helpers useful for asm code with the least amount
of clutter as possible.
flight 104082 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104082/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 09.01.17 at 12:03, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -51,6 +51,30 @@ static int gdbsx_guest_mem_io(domid_t domid, struct
> xen_domctl_gdbsx_memio *iop)
> static void update_domain_cpuid_info(struct domain *d,
> co
On Mon, Jan 09, 2017 at 07:39:32AM -0700, Jan Beulich wrote:
> Commit 9e49dcf67f ("xenstore: add per-node generation counter) changed
> the TDB layout, which - in order to not break older xenstored running
> on the same system - need to be accompanied by a version bump.
>
> Signed-off-by: Jan Beul
Simpler non-nested brace expansion.
Some entries in the MAINTAINER are not understood by the script, the
ones that contain {,}. This patch fixes it.
This will convert brace expansion style use in MAINTAINER into a regex
that get_maintainer.pl can use to match a path again a maintainer
section.
I
>>> On 09.01.17 at 12:03, wrote:
> @@ -67,6 +80,58 @@ static void __init sanitise_featureset(uint32_t *fs)
>(fs[FEATURESET_e1d] & ~CPUID_COMMON_1D_FEATURES));
> }
>
> +static void __init calculate_raw_policy(void)
> +{
> +struct cpuid_policy *p = &raw_policy;
> +
>>> On 09.01.17 at 12:03, wrote:
> ... rather than from the legacy path. Update the API to match guest_cpuid(),
> and remove its dependence on current.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@
On 1/9/17 9:22 AM, Anthony PERARD wrote:
> Simpler non-nested brace expansion.
>
> Some entries in the MAINTAINER are not understood by the script, the
> ones that contain {,}. This patch fixes it.
>
> This will convert brace expansion style use in MAINTAINER into a regex
> that get_maintainer.pl
Convert tabs into spaces; preserving indentation
No functional changes
Signed-off-by: Eric DeVolder
---
tools/libxc/xc_kexec.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/xc_kexec.c b/tools/libxc/xc_kexec.c
index 989e225192..59e2f076f4 10064
1 - 100 of 181 matches
Mail list logo
