On Thu, Feb 18, 2016 at 5:40 PM, Jan Beulich wrote:
> >>> On 18.02.16 at 09:13, wrote:
> > After a git-bisect test, the commit
> > 724b55f48a6c9fca00ddeeca5a130657680caf0b is found the first one that
> > introduces this issue.
> > And that also suggests that setting 'mwait-idle=false' works arou
On 19/02/2016 04:25, Doug Goldstein wrote:
> Allow Xenoprof to be fully disabled when toggling the option off.
>
> Signed-off-by: Doug Goldstein
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-dev
On 02/16/2016 07:11 PM, Andrew Cooper wrote:
On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 9d43f7b..b5995b9 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#in
Protection keys define a new 4-bit protection key field(PKEY) in bits 62:59 of
leaf entries of the page tables.
PKRU register defines 32 bits, there are 16 domains and 2 attribute bits per
domain in pkru, for each i (0 ≤ i ≤ 15), PKRU[2i] is the access-disable bit for
protection key i (ADi); PKRU[
The XSAVE feature set can operate on PKRU state only if the feature set is
enabled (CR4.OSXSAVE = 1) and has been configured to manage PKRU state
(XCR0[9] = 1). And XCR0.PKRU is disabled on PV mode without PKU feature
enabled.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
Reviewed-by: K
This patch adds pkeys support for cpuid handing.
Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of CR4.PKE.
X86_FEATURE_OSXSAVE depends on guest X86_FEATURE_XSAVE, but cpu_has_xsave
function reflects hypervisor X86_FE
Changes in v11:
*Move pkru_ad/pkru_wd variable initialization position.
*Undo v10 changes.
Changes in v10:
*Move PFEC_page_present check.
Changes in v9:
*Rename _write_cr4 to raw_write_cr4.
*Clear X86_FEATURE_OSPKE and X86_FEATURE_OSXSAVE when the condition is not
satisfied.
Changes in v8:
*Add
On 18/02/16 19:13, Andrew Cooper wrote:
> On 18/02/16 18:52, David Vrabel wrote:
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -394,6 +394,21 @@ struct arch_domain
>>
>> /* Emulated devices enabled bitmap. */
>> uint32_t emulation_flags;
>> +
>> +
On 18/02/16 18:52, David Vrabel wrote:
> Add a parameter to allow the toolstack to set the x87 FIP width in case
> the hypervisor's heuristics do the wrong thing.
I think this would be better as a HVM param since: a) it only needs to
be changed for HVM guests; b) it would allow the guest agent or
On Thu, Feb 11, 2016 at 5:13 PM, Boris Ostrovsky
wrote:
> Commit a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on
> paravirt") added a paravirt test in microcode_init(), primarily to avoid
> making mc_bp_resume()->load_ucode_ap()->check_loader_disabled_ap() calls
> On 32-bit kerne
Hello,
Is there a way to get the UUID of a currently running PV domain, from
within that domain?
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, 2016-02-18 at 15:44 -0700, Jim Fehlig wrote:
> Ian Campbell wrote:
> > Signed-off-by: Ian Campbell
> > Cc: Jim Fehlig
> > ---
> > docs/misc/xl-disk-configuration.txt | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/docs/misc/xl-disk-configuration.txt b/
> Is there a way to get the UUID of a currently running PV domain, from
> within that domain?
Found it, in case it helps someone else:
http://old-list-archives.xenproject.org/xen-devel/2006-05/msg01127.html
Thanks,
Razvan
___
Xen-devel mailing list
Xe
On Fri, Feb 19, 2016 at 12:06:33PM +0200, Andy Shevchenko wrote:
> Sorry for being too late, but this commit breaks 32-bit kernel on
> Intel Medfield. Reverting the only commit from today's linux-next
> helps.
You mean this commit?!
fbae4ba8c4a3 ("x86, microcode: Reload microcode on resume")
Thi
On Fri, 2016-02-19 at 12:10 +0200, Razvan Cojocaru wrote:
> Hello,
>
> Is there a way to get the UUID of a currently running PV domain, from
> within that domain?
The type associated with the UUID in the xen public headers is
"xen_domain_handle_t" which is presumably why grepping didn't find it f
On Fri, 2016-02-19 at 10:14 +, Ian Campbell wrote:
> On Thu, 2016-02-18 at 15:44 -0700, Jim Fehlig wrote:
> > Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell
> > > Cc: Jim Fehlig
> > > ---
> > > docs/misc/xl-disk-configuration.txt | 18 ++
> > > 1 file changed, 18 inser
Signed-off-by: Roger Pau Monné
Reported by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
tools/libxc/xc_dom_x86.c | 2 +-
xen/include/public/xen.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index ac4dae5
On Fri, Feb 19, 2016 at 12:18 PM, Borislav Petkov wrote:
> On Fri, Feb 19, 2016 at 12:06:33PM +0200, Andy Shevchenko wrote:
>> Sorry for being too late, but this commit breaks 32-bit kernel on
>> Intel Medfield. Reverting the only commit from today's linux-next
>> helps.
>
> You mean this commit?!
Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.
Signed-off-by: Chunyan Liu
Acked-by: Ian Jackson
---
tools/libxl/libxl_internal.h | 4 +++
tools/libxl/libxl_utils.c| 74
2 f
For some device type, device removal operation needs to be
handled specially, like usbctrl, it needs to remove all usb
devices under it first, then remove usbctrl. Extend
DEFINE_DEVICE_REMOVE to support generic and custom way
For those need to be handled specially, call
DEFINE_DEVICE_REMOVE_CUSTOM,
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Reviewed-by: Wei Liu
Acked-by: Ian Jackson
---
tools/libxl/libxl.c | 5 ++---
tools/libxl/libxl_internal.h | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c451b6
Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.
One could specify usb controllers and usb devices in config file
like t
On Thu, Feb 18, 2016 at 10:10:09PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Ian Campbell
> CC: Ian Jackson
> CC: Wei Liu
> CC: Doug Goldstein
> ---
> tools/firmware/hvmloader/xenbus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.
Changes to V13:
* move DEFINE_DEVICE_REMOVE refactoring work into separate patch (3/6)
* adjust order of removimg xenstore and unassign usb devi
Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usbctrl-attach test_vm version=1 ports=8
#xl usb-list test_vm
will show the usb controllers and port usage unde
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Simon Cao
Signed-off-by: George Dunlap
Signed-off-by: Chunyan Liu
---
changes:
Address Olaf's comme
>>> On 2/17/2016 at 12:56 AM, in message <20160216165608.ga21...@gmail.com>,
>>> Olaf
Hering wrote:
> On Tue, Jan 19, Chunyan Liu wrote:
>
> > #xl usbctrl-attach test_vm version=1 ports=8
>
> > #xl usbdev-attach test_vm hostbus=1 hostaddr=2
>
> I think this does not handle the -N kn
On 02/19/2016 12:20 PM, Ian Campbell wrote:
> On Fri, 2016-02-19 at 12:10 +0200, Razvan Cojocaru wrote:
>> Hello,
>>
>> Is there a way to get the UUID of a currently running PV domain, from
>> within that domain?
>
> The type associated with the UUID in the xen public headers is
> "xen_domain_hand
On Fri, Feb 19, 2016 at 12:33:46PM +0200, Andy Shevchenko wrote:
> No, the commit 84aba677f009 as of today's linux-next on which I commented.
You commented under the "> A subsequent commit, fbae4ba8c4a3" which confused me
as to which commit is the culprit.
> commit 84aba677f009e20185aea322563389a
On 19/02/16 10:40, Wei Liu wrote:
> On Thu, Feb 18, 2016 at 10:10:09PM +, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Ian Campbell
>> CC: Ian Jackson
>> CC: Wei Liu
>> CC: Doug Goldstein
>> ---
>> tools/firmware/hvmloader/xenbus.c | 2 +-
>> 1 fi
On Fri, Feb 19, 2016 at 12:46 PM, Borislav Petkov wrote:
> On Fri, Feb 19, 2016 at 12:33:46PM +0200, Andy Shevchenko wrote:
>> No, the commit 84aba677f009 as of today's linux-next on which I commented.
>
> You commented under the "> A subsequent commit, fbae4ba8c4a3" which confused
> me
> as to w
graft 51 ^
thanks
On Thu, 2016-02-18 at 18:15 +, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] Current LibXL Status"):
> > There really is a show-stopper, which I have stated before.
> >
> > Languages such as OCaml use -ENOMEM as a hint to run the garbage
> > collector some more
On Fri, Feb 19, 2016 at 10:50:29AM +, Andrew Cooper wrote:
> On 19/02/16 10:40, Wei Liu wrote:
> > On Thu, Feb 18, 2016 at 10:10:09PM +, Andrew Cooper wrote:
> >> Signed-off-by: Andrew Cooper
> >> ---
> >> CC: Jan Beulich
> >> CC: Ian Campbell
> >> CC: Ian Jackson
> >> CC: Wei Liu
> >>
On Fri, Feb 19, Chun Yan Liu wrote:
>
>
> >>> On 2/17/2016 at 12:56 AM, in message <20160216165608.ga21...@gmail.com>,
> >>> Olaf
> Hering wrote:
> > On Tue, Jan 19, Chunyan Liu wrote:
> >
> > > #xl usbctrl-attach test_vm version=1 ports=8
> >
> > > #xl usbdev-attach test_vm hostbus=1
On Fri, 2016-02-19 at 10:40 +, Wei Liu wrote:
> On Thu, Feb 18, 2016 at 10:10:09PM +, Andrew Cooper wrote:
> > Signed-off-by: Andrew Cooper
> > ---
> > CC: Jan Beulich
> > CC: Ian Campbell
> > CC: Ian Jackson
> > CC: Wei Liu
> > CC: Doug Goldstein
> > ---
> > tools/firmware/hvmloader
On Fri, 2016-02-19 at 12:44 +0200, Razvan Cojocaru wrote:
> On 02/19/2016 12:20 PM, Ian Campbell wrote:
> > On Fri, 2016-02-19 at 12:10 +0200, Razvan Cojocaru wrote:
> > > Hello,
> > >
> > > Is there a way to get the UUID of a currently running PV domain, from
> > > within that domain?
> >
> > Th
On 19/02/16 10:28, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
> Reported by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Processing commands for x...@bugs.xenproject.org:
> graft 51 ^
Graft `<22214.2619.86697.724...@mariner.uk.xensource.com>' onto #51
> thanks
Finished processing.
Modified/created Bugs:
- 51: http://bugs.xenproject.org/xen/bug/51
---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporti
On Fri, Feb 19, 2016 at 12:50 PM, Andy Shevchenko
wrote:
> On Fri, Feb 19, 2016 at 12:46 PM, Borislav Petkov wrote:
>> On Fri, Feb 19, 2016 at 12:33:46PM +0200, Andy Shevchenko wrote:
>>> commit 84aba677f009e20185aea322563389ad56e0ef7e
>>> Author: Boris Ostrovsky
>>> Date: Tue Feb 16 09:43:19
On Fri, 2016-02-19 at 10:50 +, Andrew Cooper wrote:
> On 19/02/16 10:40, Wei Liu wrote:
> > On Thu, Feb 18, 2016 at 10:10:09PM +, Andrew Cooper wrote:
> > > Signed-off-by: Andrew Cooper
> > > ---
> > > CC: Jan Beulich
> > > CC: Ian Campbell
> > > CC: Ian Jackson
> > > CC: Wei Liu
> > >
On 19/02/16 11:00, Ian Campbell wrote:
> On Fri, 2016-02-19 at 10:50 +, Andrew Cooper wrote:
>> On 19/02/16 10:40, Wei Liu wrote:
>>> On Thu, Feb 18, 2016 at 10:10:09PM +, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Ian Campbell
CC:
On Fri, Feb 19, 2016 at 01:00:35PM +0200, Andy Shevchenko wrote:
> That what I see last with earlycon enabled + `debug` in cmdline:
That doesn't help. Can you dump RIP, etc registers as to where the
machine freezes?
Let me confirm this: booting with "dis_ucode_ldr" works?
Also, please send .conf
On Fri, 2016-02-19 at 11:09 +, Andrew Cooper wrote:
> On 19/02/16 11:00, Ian Campbell wrote:
> > On Fri, 2016-02-19 at 10:50 +, Andrew Cooper wrote:
> > > On 19/02/16 10:40, Wei Liu wrote:
> > > > On Thu, Feb 18, 2016 at 10:10:09PM +, Andrew Cooper wrote:
> > > > > Signed-off-by: Andrew
On Fri, Feb 19, 2016 at 1:10 PM, Borislav Petkov wrote:
> On Fri, Feb 19, 2016 at 01:00:35PM +0200, Andy Shevchenko wrote:
>> That what I see last with earlycon enabled + `debug` in cmdline:
>
> That doesn't help.
Heh, rebuilt on clean repository -> everything works. Looks like false
alarm and pr
On Fri, Feb 19, 2016 at 01:21:10PM +0200, Andy Shevchenko wrote:
> Heh, rebuilt on clean repository -> everything works. Looks like false
> alarm and practical proof to do clean build first.
Always, like *really* *always*, do
$ make mrproper
or even
$ git clean -dqfx
before testing kernels. I
>>> On 18.02.16 at 22:12, wrote:
> On Thu, Feb 18, 2016 at 09:45:30AM -0700, Jan Beulich wrote:
>> >>> On 18.02.16 at 17:39, wrote:
>> > Jan Beulich writes ("Re: [PATCH v3 5/5] mkelf32: Close those file
> descriptors
>> > in the error paths."):
>> >> On 12.02.16 at 04:08, wrote:
>> >> > While
Konrad Rzeszutek Wilk writes ("Re: [PATCH v3 5/5] mkelf32: Close those file
descriptors in the error paths."):
>
>
> If I turned them in:
>
> if (..blah..)
> {
> close(infd);
> return -1;
> }
>
> would that satisfy you?
I would strongly resist tha
Wei has been picking this up for quite a while now.
Signed-off-by: Ian Campbell
Cc: Wei Liu
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 28eb61b..ef30060 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12013,7 +12013,6 @@ F: arch/arm64/x
>>> On 19.02.16 at 09:30, wrote:
> On Thu, Feb 18, 2016 at 5:40 PM, Jan Beulich wrote:
>> (copy to xen-devel)
But then please don't cross-post (I'm therefore moving xen-users
to BC).
> The issue still exists with microcode updated.
> And on this machine, nothing 'ACPI Error' like the Debian bug
On Fri, Feb 19, 2016 at 11:44:51AM +, Ian Campbell wrote:
> Wei has been picking this up for quite a while now.
>
> Signed-off-by: Ian Campbell
> Cc: Wei Liu
Acked-by: Wei Liu
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2
Hi everyone,
due to the recently discovered glibc security vulnerability we need to reboot
all our VMs: this will affect the blog, bugs, etherpad, lists, mail, wiki and
xenbits. Each service should only be unavailable for 5 minutes.
If you notice any issues after the reboot please reply to this
On Fri, Feb 19, Olaf Hering wrote:
> Not sure how to handle it, perhaps exit when xl -N is called?
Also the interface is 'xl -N' is not clearly defined. What is it
supposed to do with the newly introduced ctrl types? Should it display
the json just for the dev, just for the ctrl+dev or the entire
The current check is a super long winded way of asking if this
is on lguest. The flags is used for legacy features, this is
likely inspired by the ACPI IA-PC boot architecture flags, where
as for RTC it annotates No CMOS real-time clock present. I don't
expect we will be implementing more legacy fe
I originally set out to rename paravirt_enabled() to paravirt_legacy()
but we instead decided to remove paravirt_enabled() completely. Although
I have some linker table work which will help make this cleaner, instead
of waiting for that to go in, just remove the known cases that should
be safe for
This lets us remove its use of paravirt_enabled(). The
other subarchs are not needed here given that on 32-bit
there is a switch already that negates access to this
code on X86_SUBARCH_INTEL_MID, and X86_SUBARCH_CE4100.
Both lguest and Xen had paravirt_enabled so that
excludes them.
Signed-off-by:
Since we are removing paravirt_enabled() replace it with a
logical equivalent.
Signed-off-by: Luis R. Rodriguez
---
drivers/pnp/pnpbios/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c
index facd43b8516c..96dc1f
The use of subarch should have no current effect on Xen
PV guests, as such this should have no current functional
effects.
Signed-off-by: Luis R. Rodriguez
---
arch/x86/xen/enlighten.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d
There is already a check for apm_info.bios == 0, the
apm_info.bios is set from the boot_params.apm_bios_info.
Both Xen and lguest, which are also the only ones that set
paravirt_enabled to true) do never set the apm_bios_info,
the paravirt_enabled() check is simply not needed.
Signed-off-by: Luis
Although hardware_subarch has been in place since the x86 boot
protocol 2.07 it hasn't been used much. Enumerate current possible
values to avoid misuses and help with semantics later at boot
time should this be used further.
Cc: Andy Shevchenko
Signed-off-by: Luis R. Rodriguez
---
arch/x86/inc
Use the harware subarch instead now that they are set. If we
want to test removing this work around on Xen we can do so
separatley as another independent change, for now we just want
to remove paravirt_enabled().
Signed-off-by: Luis R. Rodriguez
---
arch/x86/kernel/cpu/intel.c | 4 +++-
1 file c
Be explicit and make use of X86_SUBARCH_LGUEST directly.
Signed-off-by: Luis R. Rodriguez
---
tools/lguest/lguest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c
index 80159e6811c2..ff0aa580c6e1 100644
--- a/tools/lguest/lgu
There is already a check for boot_params.tboot_addr prior
to paravirt_enabled() and both Xen and lguest never set this.
This check is not needed.
Signed-off-by: Luis R. Rodriguez
---
arch/x86/kernel/tboot.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/x86/kernel/tboot.c b/arch/x
On 19/02/16 14:08, Luis R. Rodriguez wrote:
> Although hardware_subarch has been in place since the x86 boot
> protocol 2.07 it hasn't been used much. Enumerate current possible
> values to avoid misuses and help with semantics later at boot
> time should this be used further.
>
> Cc: Andy Shevche
On 19/02/16 14:08, Luis R. Rodriguez wrote:
> The current check is a super long winded way of asking if this
> is on lguest. The flags is used for legacy features, this is
What about Xen pv-domU? I wouldn't expect those to have PV_SUPPORTED_RTC
set.
Juergen
> likely inspired by the ACPI IA-PC b
On 19/02/16 13:08, Luis R. Rodriguez wrote:
> The current check is a super long winded way of asking if this
> is on lguest. The flags is used for legacy features, this is
> likely inspired by the ACPI IA-PC boot architecture flags, where
> as for RTC it annotates No CMOS real-time clock present. I
On 19/02/16 13:08, Luis R. Rodriguez wrote:
> I originally set out to rename paravirt_enabled() to paravirt_legacy()
> but we instead decided to remove paravirt_enabled() completely. Although
> I have some linker table work which will help make this cleaner, instead
> of waiting for that to go in,
On 19/02/16 13:08, Luis R. Rodriguez wrote:
> Although hardware_subarch has been in place since the x86 boot
> protocol 2.07 it hasn't been used much. Enumerate current possible
> values to avoid misuses and help with semantics later at boot
> time should this be used further.
>
> Cc: Andy Shevche
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 is my v2 of the original linker table work [0], now with
six proof of concepts ports of existing code using custom section
with custom linker script modifications:
* DEFINE_LINKTABLE_TEXT(char, kprobes);
* DEFINE_LINKTABLE_DATA(struct jump_entry, __jump_table);
* DEFINE_LINKTABLE_DATA(s
This removes the custom vmlinux.lds.h hacks and uses
the generalized solution for .data (SECTION_DATA)
entries.
This is much more potential for further fine tuning here
though in the future. For instance, linker tables enable
an extra postfix for order level annotations, this could
easily be used
Linux makes extensive use of custom ELF header sections,
documentation for these are well scatterred. Unify this
documentation in a central place.
Signed-off-by: Luis R. Rodriguez
---
Documentation/DocBook/Makefile | 3 +-
Documentation/DocBook/sections.tmpl | 99
includ
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 (SECTION_RO)
linker tables.
Tested with 0 built-in firmware, 1 and 2 built-in
firmwares successfully.
Signed-off-by: Luis R. Rodriguez
---
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 (SECTION_DATA)
linker tables and of push_section_tbl().
Signed-off-by: Luis R. Rodriguez
---
arch/arm/include/asm/jump_label.h
kprobe makes use of two custom sections:
type name beginend
init.data _kprobe_blacklist __start_kprobe_blacklist__stop_kprobe_blacklist
text .kprobes.text __kprobes_text_start__kprobes_text_end
Port these to the linker table generic
With a generic linker tables solution in place we
need a general asm solution for declaring entries
with asm. The first easy target is to cover the C
asm declarations, guard the header file for now
and define a first generic entry push_section_tbl()
to be used later for custom linker table annotati
On Thu, 18 Feb 2016, Corneliu ZUZU wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cd4da04..768ad32 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -356,6 +356,7 @@ M:Tamas K Lengyel
> S: Supported
> F: xen/common/vm_event.c
> F: xen/common/mem_access.c
> +F: xen/com
On 02/19/2016 03:49 PM, Stefano Stabellini wrote:
> On Thu, 18 Feb 2016, Corneliu ZUZU wrote:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index cd4da04..768ad32 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -356,6 +356,7 @@ M: Tamas K Lengyel
>> S: Supported
>> F: xen/common/vm
>>> On 18.02.16 at 19:52, wrote:
> ---
> xen/arch/x86/domctl.c | 14 ++
What about ARM?
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1092,6 +1092,25 @@ struct xen_domctl_psr_cat_op {
> typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_
On Thu, Feb 18, 2016 at 08:57:02PM -0600, Doug Goldstein wrote:
> bcc/ld86/as86 are only necessary when we build rombios and not always so
> failing the build when they aren't available should not happen if the
> user isn't building rombios.
That is quite the long sentence. Perhaps trim it down to
On Thu, Feb 18, 2016 at 08:57:03PM -0600, Doug Goldstein wrote:
> Reported-by: Jonathan Creekmore
> Signed-off-by: Doug Goldstein
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> CC: Ian Jackson
> CC: Stefano Stabellini
> CC: Ian Campbell
> CC: Wei Liu
>
> change since v1:
> - don't screw up the
>>> On 18.02.16 at 19:52, wrote:
> The x86 architecture allows either: a) the 64-bit FIP/FDP registers to be
> restored (clearing FCS and FDS); or b) the 32-bit FIP/FDP and FCS/FDS
> registers to be restored (clearing the upper 32-bits).
>
> Add a per-domain field to indicate which of these optio
>>> On 18.02.16 at 19:52, wrote:
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -148,6 +148,30 @@ static void dump_guest_os_id(const struct domain *d)
> goi->fields.service_pack, goi->fields.build_number);
> }
>
> +static void set_guest_os_id(struct dom
>>> On 19.02.16 at 11:05, wrote:
> On 18/02/16 18:52, David Vrabel wrote:
>> Add a parameter to allow the toolstack to set the x87 FIP width in case
>> the hypervisor's heuristics do the wrong thing.
>
> I think this would be better as a HVM param since: a) it only needs to
> be changed for HVM g
Using the linker table removes the need for the #ifdef'ery
and clutter on head32.c and head64.c, if this is linked in
and the subarch matches it will run.
Cc: Andy Shevchenko
Signed-off-by: Luis R. Rodriguez
---
arch/x86/include/asm/setup.h| 6 --
arch/x86/kernel/head32.c
This also annotates this is only used for PC and
lguest hardware subarchitectures.
v2: add X86_SUBARCH_XEN as well, as noted by Konrad,
now tested by 0-day bot.
Signed-off-by: Luis R. Rodriguez
---
arch/x86/kernel/head32.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff
On 19/02/16 14:08, Jan Beulich wrote:
On 18.02.16 at 19:52, wrote:
>> The x86 architecture allows either: a) the 64-bit FIP/FDP registers to be
>> restored (clearing FCS and FDS); or b) the 32-bit FIP/FDP and FCS/FDS
>> registers to be restored (clearing the upper 32-bits).
>>
>> Add a per-do
On Thu, Feb 18, 2016 at 12:13:36PM +, Wei Liu wrote:
> On Thu, Feb 18, 2016 at 10:43:15AM +0800, Wen Congyang wrote:
> > Before this patch:
> > 1. suspend
> > a. PVHVM and PV: we use the same way to suspend the guest (send the suspend
> >request to the guest). If the guest doesn't support e
The boot/bitops.h has guards against including the
regular bitops (include/asm-generic/bitops.h), it only
implements what we need at early boot. We'll be making
use of BIT() later so add it.
Users of boot/boot.h must include it prior to asm/setup.h
otherwise the guard protection devised against th
Any failure on the x86 init path can be catastrophic.
A simple shift of a call from one place to another can
easily break things. Likewise adding a new call to
one path without considering all x86 requirements
can make certain x86 run time environments crash.
We currently account for these requirem
Using the linker table removes the need for the #ifdef'ery
and clutter on head32.c.
Signed-off-by: Luis R. Rodriguez
---
arch/x86/include/asm/setup.h | 6 --
arch/x86/kernel/head32.c | 3 ---
arch/x86/platform/ce4100/ce4100.c | 4 +++-
3 files changed, 3 insertions(+), 10 delet
x-next.git/log/?h=20160219-linker-table-v2
[4]
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160219-linker-table-v2
Luis R. Rodriguez (6):
x86/boot: add BIT() to boot/bitops.h
x86/init: use linker tables to simplify x86 init and annotate
dependencies
x86/init:
On Fri, Feb 19, 2016 at 05:45:59AM -0800, Luis R. Rodriguez wrote:
> kprobe makes use of two custom sections:
>
> type name beginend
> init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist
> text .kprobes.text __kprobes_te
This lets us annotate its requirements specifically for
PC and lguest subarchitectures. While at it since head.c
just has ebda data rename it. Since we're using linker tables
and both x86 32-bit and 64-bit have them we don't need
to declare a call for this separately. This lets us
also keep this de
>>> On 18.02.16 at 20:35, wrote:
> ---
> MAINTAINERS | 1 +
> xen/arch/arm/hvm.c | 8 +++
> xen/arch/x86/hvm/event.c| 116
> ++--
> xen/arch/x86/hvm/hvm.c | 1 +
> xen/arch/x86/monitor.c | 14 --
On 2/19/16 8:00 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 18, 2016 at 08:57:02PM -0600, Doug Goldstein wrote:
>> bcc/ld86/as86 are only necessary when we build rombios and not always so
>> failing the build when they aren't available should not happen if the
>> user isn't building rombios.
>
And what it is usually used for.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/include/public/version.h | 4
1 file changed, 4 insertions(+)
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index adca602..b97fc68 100644
--- a/xen/include/public/version.h
+++ b/xen/in
On 02/19/2016 04:32 PM, Konrad Rzeszutek Wilk wrote:
> And what it is usually used for.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> xen/include/public/version.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/xen/include/public/version.h b/xen/include/public/version.h
> index
>>> On 19.02.16 at 15:16, wrote:
> On 19/02/16 14:08, Jan Beulich wrote:
> On 18.02.16 at 19:52, wrote:
>>> @@ -261,28 +261,8 @@ void xsave(struct vcpu *v, uint64_t mask)
>>> "=m" (*ptr), \
>>> "a" (lmask), "d" (hmask), "D" (ptr))
>>>
>>>
On Fri, Feb 19, 2016 at 01:40:33PM +, David Vrabel wrote:
> On 19/02/16 13:08, Luis R. Rodriguez wrote:
> > Although hardware_subarch has been in place since the x86 boot
> > protocol 2.07 it hasn't been used much. Enumerate current possible
> > values to avoid misuses and help with semantics l
On Fri, Feb 19, 2016 at 09:15:38AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 18, 2016 at 12:13:36PM +, Wei Liu wrote:
> > On Thu, Feb 18, 2016 at 10:43:15AM +0800, Wen Congyang wrote:
> > > Before this patch:
> > > 1. suspend
> > > a. PVHVM and PV: we use the same way to suspend the gue
1 - 100 of 224 matches
Mail list logo
