On Wed, Jan 24, 2018 at 06:03:28PM +, George Dunlap wrote:
> On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne wrote:
> > Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
> > hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent
> > vCPU migration and should im
>>> On 24.01.18 at 18:06, wrote:
> On Wed, Jan 24, 2018 at 09:40:40AM -0700, Jan Beulich wrote:
>> >>> On 24.01.18 at 16:48, wrote:
>> > The build with clang is currently broken because clang requires asm
>> > macros to be declared inside the same inline asm declaration where
>> > they are used.
On Thu, Jan 25, 2018 at 02:39:36AM -0700, Jan Beulich wrote:
> >>> On 24.01.18 at 18:06, wrote:
> > On Wed, Jan 24, 2018 at 09:40:40AM -0700, Jan Beulich wrote:
> >> >>> On 24.01.18 at 16:48, wrote:
> >> > The build with clang is currently broken because clang requires asm
> >> > macros to be dec
Add a function to get the address of the RSDP table. Per default use a
__weak annotated function being a nop.
Cc: # 4.11
Signed-off-by: Juergen Gross
---
drivers/acpi/osl.c | 10 +-
include/linux/acpi.h | 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/ac
The Xen PVH boot protocol passes vital information to the kernel via
a start_info block. One of the data transferred is the physical address
of the RSDP table.
Unfortunately PVH support in the kernel didn't use that passed address
for RSDP, but relied on the legacy mechanism searching for the RSDP
Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
the address of the RSDP table given to the kernel via Xen start info.
This makes the kernel boot again in PVH mode after on recent Xen the
RSDP was moved to higher addresses. So up to that change it was pure
luck that the legacy me
>>> On 24.01.18 at 17:52, wrote:
> On Wed, Jan 24, 2018 at 09:23:37AM -0700, Jan Beulich wrote:
>> >>> On 24.01.18 at 16:48, wrote:
>> > When indirect_thunk_asm.h is instantiated directly into assembly files
>> > CONFIG_INDIRECT_THUNK might not be defined, and thus using .if against
>> > it is wr
On Wed, Jan 24, 2018 at 04:52:17PM +, Roger Pau Monné wrote:
> On Wed, Jan 24, 2018 at 09:23:37AM -0700, Jan Beulich wrote:
> > >>> On 24.01.18 at 16:48, wrote:
> > > When indirect_thunk_asm.h is instantiated directly into assembly files
> > > CONFIG_INDIRECT_THUNK might not be defined, and th
On Wed, Jan 24, 2018 at 09:46:06AM -0800, Stefano Stabellini wrote:
> On Wed, 24 Jan 2018, Roger Pau Monné wrote:
> > On Tue, Jan 23, 2018 at 04:47:51PM -0800, Stefano Stabellini wrote:
> > > On Tue, 23 Jan 2018, Jan Beulich wrote:
> > > > >>> On 23.01.18 at 01:41, wrote:
> > > > > On 23/01/2018 0
Xen doesn't crash at all.
With this file, it works, Xen boots :
```
[global]
default=xen
[xen]
options=loglvl=all com1=115200,8n1 console=com1,vga
kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash
earlyprintk=xen
ramdisk=initrd.img
```
With this file, I have just added "dom0_me
On Wed, Jan 24, 2018 at 9:59 PM, Håkon Alstadheim
wrote:
> I'm trying, and failing, to launch a vm with bios = 'ovmf' under xen 4.10.
>
> The domain launches OK as long as I do not pass any pci devices through,
> but with pci devices passed through,
Anthony,
Does OVMF support PCI pass-through ye
(With the attached file)
Xen doesn't crash at all.
With this file, it works, Xen boots :
```
[global]
default=xen
[xen]
options=loglvl=all com1=115200,8n1 console=com1,vga
kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash
earlyprintk=xen
ramdisk=initrd.img
```
With this file,
On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
> Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
> the address of the RSDP table given to the kernel via Xen start info.
>
> This makes the kernel boot again in PVH mode after on recent Xen the
> RSDP was moved to h
On 01/24/2018 01:06 PM, Juergen Gross wrote:
> On 24/01/18 11:54, Roger Pau Monné wrote:
>> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
>>> On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
>>> wrote:
On 01/18/2018 05:33 AM, Wei Liu wrote:
> On Thu, Jan 18, 2018 at 11:31
>>> On 25.01.18 at 11:25, wrote:
>> Xen doesn't crash at all.
Did you read the above? it is being confirmed by ...
> With this file, it works, Xen boots :
>
> ```
> [global]
> default=xen
>
> [xen]
> options=loglvl=all com1=115200,8n1 console=com1,vga
> kernel=vmlinuz root=/dev/md2 ro rootdel
>>> On 24.01.18 at 19:16, wrote:
> For a release build, bloat-o-meter reports:
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111)
> function old new delta
> x86_emulate 126458 121347 -5111
>
> or in other
On 25/01/18 11:37, Greg KH wrote:
> On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
>> Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
>> the address of the RSDP table given to the kernel via Xen start info.
>>
>> This makes the kernel boot again in PVH mode after
On 25/01/18 11:38, Hans van Kranenburg wrote:
> On 01/24/2018 01:06 PM, Juergen Gross wrote:
>> On 24/01/18 11:54, Roger Pau Monné wrote:
>>> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
wrote:
> On 01/18/2018 05:33 A
>>> On 24.01.18 at 21:48, wrote:
> From: Wei Liu [wei.l...@citrix.com]
> Sent: 24 January 2018 20:26
>
> AIUI the purpose of having the .if directive is to make GET_STACK_END
> work with any general purpose registers. The code as-is would produce
> the wrong result for r8. Fix it.
>
> Signed-off
On 24/01/18 10:22, Anil Madhavapeddy wrote:
Looks good to me. The difficulties are all ‘medium’ though. Perhaps
break up the “new execution targets” into medium/hard for the various
backends? For example, Xen/ARM is probably easier than bare metal ARM,
and I imagine HyperV is quite complex d
>>> On 24.01.18 at 23:31, wrote:
> I've recently discovered that if you attempt to use introspection to
> capture CR3 changes with the new KPTI enabled kernels, the guest dies
> shortly after the start of introspection with failed VM entry due to
> invalid guest state.
>
> I believe the invalid s
Hi,
On 24/01/18 22:43, Stefano Stabellini wrote:
On Wed, 24 Jan 2018, Julien Grall wrote:
Hi Stefano,
On 24 January 2018 at 22:14, Stefano Stabellini wrote:
On Thu, 18 Jan 2018, Julien Grall wrote:
(+ Security team)
Hi Stefano,
On 17/01/18 21:47, Stefano Stabellini wrote:
On Wed, 17 Jan
On Thu, Jan 25, 2018 at 11:49:35AM +0100, Juergen Gross wrote:
> On 25/01/18 11:37, Greg KH wrote:
> > On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
> >> Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
> >> the address of the RSDP table given to the kernel via Xe
On 25/01/18 10:49, Jan Beulich wrote:
On 24.01.18 at 19:16, wrote:
>> For a release build, bloat-o-meter reports:
>>
>> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111)
>> function old new delta
>> x86_emulate
On 25/01/18 11:40, Jan Beulich wrote:
On 25.01.18 at 11:25, wrote:
>>> Xen doesn't crash at all.
>
> Did you read the above? it is being confirmed by ...
>
>> With this file, it works, Xen boots :
>>
>> ```
>> [global]
>> default=xen
>>
>> [xen]
>> options=loglvl=all com1=115200,8n1 consol
# About the kernel crash
Did you read the above?
I just wanted to say that I have solved the kernel panic crash that I
had before, when you explained "Xen doesn't crash at all. It's the Dom0
kernel which panics".
Just for information the crash happens if I put the "console=com1" to
the ke
Guillaume, can you try to get symbol+offset for the values on the stack
looking like kernel code addresses (e.g. everything starting with
"82")?
For sure. Just, can you explain me how I can do this, please ?
Guillaume
___
Xen-devel mailing l
>>> On 25.01.18 at 12:16, wrote:
> On 25/01/18 11:40, Jan Beulich wrote:
>> This tells us (together with the page fault error code) that the
>> Dom0 kernel tried to provide memory as kernel stack which
>> can't be written. This may be a Dom0 kernel stack overflow,
>
> Really? Why do you think thi
On Thu, Jan 25, 2018 at 02:51:34AM +, osstest service owner wrote:
> flight 118296 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/118296/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-
Hi Stefano,
On 24/01/18 23:14, Stefano Stabellini wrote:
On Fri, 19 Jan 2018, Julien Grall wrote:
At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0,
r0).
This is rather unintuitive and will result to execute the trap
undefined. Instead introduce trap helpers for reset and
On Thu, Jan 25, 2018 at 10:28:14AM +, George Dunlap wrote:
> On Wed, Jan 24, 2018 at 9:59 PM, Håkon Alstadheim
> wrote:
> > I'm trying, and failing, to launch a vm with bios = 'ovmf' under xen 4.10.
> >
> > The domain launches OK as long as I do not pass any pci devices through,
> > but with p
Hi Stefano,
On 24/01/18 23:54, Stefano Stabellini wrote:
On Fri, 19 Jan 2018, Julien Grall wrote:
Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.
This patch
>>> On 25.01.18 at 12:09, wrote:
> On 25/01/18 10:49, Jan Beulich wrote:
> On 24.01.18 at 19:16, wrote:
>>> For a release build, bloat-o-meter reports:
>>>
>>> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111)
>>> function old new delta
>>
On 25/01/18 11:24, Wei Liu wrote:
> On Thu, Jan 25, 2018 at 02:51:34AM +, osstest service owner wrote:
>> flight 118296 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/118296/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tes
>>> On 06.12.17 at 17:19, wrote:
> Instead of giving, to subsequent code, the appearance of there not
> having been any "info" data provided, adjust the conditional guarding
> SR-IOV handling.
>
> Signed-off-by: Jan Beulich
Anyone caring to take a look? Otherwise I'll commit this without
any ac
Hi Stefano,
On 25/01/18 01:02, Stefano Stabellini wrote:
On Fri, 19 Jan 2018, Julien Grall wrote:
In order to avoid aliasing attackes agains the branch predictor, let's
invalidate the BTB on guest exist. This is made complicated by the fact
that we cannot take a branch invalidating the BTB.
Th
On Wed, Dec 06, 2017 at 09:19:16AM -0700, Jan Beulich wrote:
> Instead of giving, to subsequent code, the appearance of there not
> having been any "info" data provided, adjust the conditional guarding
> SR-IOV handling.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
> --- a/xen/d
On 25/01/18 12:00, Greg KH wrote:
> On Thu, Jan 25, 2018 at 11:49:35AM +0100, Juergen Gross wrote:
>> On 25/01/18 11:37, Greg KH wrote:
>>> On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
the address of the
Hi,
On 25/01/18 11:24, Wei Liu wrote:
On Thu, Jan 25, 2018 at 02:51:34AM +, osstest service owner wrote:
flight 118296 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118296/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which coul
On 24/01/18 22:10, Martin Kelly wrote:
Hi,
Hello,
Does anyone know if GPU passthrough is supported on ARM? (e.g. for a GPU
integrated into an ARM SoC). I checked documentation and the code, but I
couldn't tell for sure.
If so, what are the hardware requirements for it? If not, is it feas
On 25/01/18 12:20, msd+xen-de...@msd.im wrote:
>> Guillaume, can you try to get symbol+offset for the values on the stack
>> looking like kernel code addresses (e.g. everything starting with
>> "82")?
>
> For sure. Just, can you explain me how I can do this, please ?
You'll need a decompr
On 01/25/2018 02:15 AM, Andrew Cooper wrote:
> On 24/01/2018 22:31, Bitweasil . wrote:
>> I've recently discovered that if you attempt to use introspection to
>> capture CR3 changes with the new KPTI enabled kernels, the guest dies
>> shortly after the start of introspection with failed VM entry du
>>> On 24.01.18 at 14:12, wrote:
> As per the spec currently available here:
>
> https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
>
> MSR_ARCH_CAPABILITIES will only come into existence on new hardware, but is
> implemented as
On 01/25/2018 02:25 PM, Razvan Cojocaru wrote:
> On 01/25/2018 02:15 AM, Andrew Cooper wrote:
>> On 24/01/2018 22:31, Bitweasil . wrote:
>>> I've recently discovered that if you attempt to use introspection to
>>> capture CR3 changes with the new KPTI enabled kernels, the guest dies
>>> shortly a
On Thu, Jan 25, 2018 at 01:06:26PM +0100, Juergen Gross wrote:
> On 25/01/18 12:00, Greg KH wrote:
> > On Thu, Jan 25, 2018 at 11:49:35AM +0100, Juergen Gross wrote:
> >> On 25/01/18 11:37, Greg KH wrote:
> >>> On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
> Add acpi_arch_get_
flight 118326 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118326/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 24.01.18 at 14:12, wrote:
> We need to be able to either set or clear IBRS in Xen context, as well as
> restore appropriate guest values in guest context. See the documentation in
> asm-x86/spec_ctrl_asm.h for details.
>
> With the contemporary microcode, writes to %cr3 are slower when SP
Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
XSM handles.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Wei Liu
Cc: Ian Jackson
Cc: Roger Pau Monne
Cc: Daniel De Graaf
---
tools/flask/policy/modules/dom0.te | 2 +-
xen/xsm/flask/hooks.c
>>> On 24.01.18 at 14:12, wrote:
> --- a/xen/include/asm-x86/spec_ctrl_asm.h
> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
> @@ -74,6 +74,43 @@
> * - SPEC_CTRL_EXIT_TO_GUEST
> */
>
> +.macro DO_OVERWRITE_RSB
> +/*
> + * Requires nothing
> + * Clobbers %rax, %rcx
> + *
> + * Requires 256 bytes
On 25/01/18 13:14, Wei Liu wrote:
> Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
> XSM handles.
>
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenpro
flight 118304 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118304/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which are failing
>>> On 24.01.18 at 14:12, wrote:
> --- a/xen/include/asm-x86/spec_ctrl_asm.h
> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
> @@ -20,6 +20,11 @@
> #ifndef __X86_SPEC_CTRL_ASM_H__
> #define __X86_SPEC_CTRL_ASM_H__
>
> +/* Encoding of the bottom bits in cpuinfo.bti_ist_info */
> +#define BTI_IST_IB
flight 118302 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118302/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken
test-xtf-amd64-amd64-3 49 x
Hi Manish,
On 16/01/18 15:42, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
Add a config option to enable VGIC Errata Code in Xen. Platforms which do not
have this errta can compile out this feature.
s/errta/errata/
Signed-off-by: Manish Jaggi
---
xen/arch/arm/Kconfig | 9 +++
On Thu, Jan 25, 2018 at 01:14:24PM +, Wei Liu wrote:
> Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
> XSM handles.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Thanks!
___
Xen-devel mailing list
Xen-devel@lis
>>> On 24.01.18 at 14:12, wrote:
> See the logic and comments in init_speculation_mitigations() for further
> details.
>
> There are two controls for RSB overwriting, because in principle there are
> cases where it might be safe to forego rsb_native (Off the top of my head,
> SMEP active, no 32bi
On Thu, Jan 25, 2018 at 9:14 AM, Roger Pau Monné wrote:
> On Wed, Jan 24, 2018 at 06:03:28PM +, George Dunlap wrote:
>> On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne
>> wrote:
>> > Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
>> > hotplug also pin the vCPUs to the pCP
On 25/01/18 13:08, Jan Beulich wrote:
On 24.01.18 at 14:12, wrote:
>> We need to be able to either set or clear IBRS in Xen context, as well as
>> restore appropriate guest values in guest context. See the documentation in
>> asm-x86/spec_ctrl_asm.h for details.
>>
>> With the contemporary m
On Wed, Jan 24, 2018 at 07:04:35PM +0100, Mirela Simonovic wrote:
> Hi Oleksandr, Edgar,
>
>
> Thanks, you're right.
>
>
> On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote:
> >On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:
> >>Hi Mirela,
> >>
> >>Just some remarks regardin
On 25/01/18 13:19, Jan Beulich wrote:
On 24.01.18 at 14:12, wrote:
>> --- a/xen/include/asm-x86/spec_ctrl_asm.h
>> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
>> @@ -74,6 +74,43 @@
>> * - SPEC_CTRL_EXIT_TO_GUEST
>> */
>>
>> +.macro DO_OVERWRITE_RSB
>> +/*
>> + * Requires nothing
>> + * C
On Tue, Jan 16, 2018 at 08:56:24AM +0100, Christoph Hellwig wrote:
> All other discussions related to the dma mapping interfaces are on the
> iommu list, so let's make it the official list for swiotlb and the
> second list for xen-swiotlb.
>
> Signed-off-by: Christoph Hellwig
I am so behind emai
Add a function to get the address of the RSDP table. Per default use a
__weak annotated function being a nop.
Cc: # 4.11
Signed-off-by: Juergen Gross
---
drivers/acpi/osl.c | 10 +-
include/linux/acpi.h | 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/ac
The Xen PVH boot protocol passes vital information to the kernel via
a start_info block. One of the data transferred is the physical address
of the RSDP table.
Unfortunately PVH support in the kernel didn't use that passed address
for RSDP, but relied on the legacy mechanism searching for the RSDP
>>> On 25.01.18 at 15:12, wrote:
> On 25/01/18 13:08, Jan Beulich wrote:
>> It may also be worthwhile again to pull up the zeroing of %edx,
>> using %dl instead of $0 in the movb (and maybe then also
>> similarly in DO_SPEC_CTRL_EXIT_TO_XEN, but there I'm less
>> certain it couldn't have a negativ
Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
the address of the RSDP table given to the kernel via Xen start info.
This makes the kernel boot again in PVH mode after on recent Xen the
RSDP was moved to higher addresses. So up to that change it was pure
luck that the legacy me
>>> On 25.01.18 at 15:17, wrote:
> On 25/01/18 13:19, Jan Beulich wrote:
>> I think we want to have the same, to please AMD. I'd
>> suggest to use alternative patching though (except again on the
>> IST paths), but then again maybe in a follow-up patch.
>
> I trust the later patches are suitable
On 25/01/18 14:40, Jan Beulich wrote:
On 25.01.18 at 15:17, wrote:
>> On 25/01/18 13:19, Jan Beulich wrote:
>>> I think we want to have the same, to please AMD. I'd
>>> suggest to use alternative patching though (except again on the
>>> IST paths), but then again maybe in a follow-up patch.
On Wed, Jan 24, 2018 at 02:31:20PM +, David Woodhouse wrote:
> On Wed, 2018-01-24 at 13:49 +, Andrew Cooper wrote:
> > On 24/01/18 13:34, Woodhouse, David wrote:
> > > I am loath to suggest *more* tweakables, but given the IBPB cost is
> > > there any merit in having a mode which does it on
On 25/01/18 14:36, Jan Beulich wrote:
On 25.01.18 at 15:12, wrote:
>> On 25/01/18 13:08, Jan Beulich wrote:
>>> It may also be worthwhile again to pull up the zeroing of %edx,
>>> using %dl instead of $0 in the movb (and maybe then also
>>> similarly in DO_SPEC_CTRL_EXIT_TO_XEN, but there I'm
>>> On 25.01.18 at 15:44, wrote:
> On 25/01/18 14:40, Jan Beulich wrote:
> On 25.01.18 at 15:17, wrote:
>>> On 25/01/18 13:19, Jan Beulich wrote:
I think we want to have the same, to please AMD. I'd
suggest to use alternative patching though (except again on the
IST paths), bu
On Wed, Jan 24, 2018 at 10:01:21AM +, Roger Pau Monne wrote:
> It will contain the generic implementation of sysctl_cov_op, which
> will be shared between all the coverage implementations.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Konrad Rzeszutek Wilk
> ---
> Cc: Andrew Cooper
> Cc
On 01/25/2018 02:47 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 24, 2018 at 10:01:21AM +, Roger Pau Monne wrote:
>> It will contain the generic implementation of sysctl_cov_op, which
>> will be shared between all the coverage implementations.
>>
>> Signed-off-by: Roger Pau Monné
>> Reviewed
On Wed, Jan 24, 2018 at 03:49:16PM +, Andrew Cooper wrote:
> The use of __LINE__ in a printk() is problematic for livepatching, as it
> causes unnecessary binary differences.
>
> Furthermore, diagnostic information around calls is inconsistent and
> occasionally unhelpful. (e.g. diagnosing lo
This seems to be copy/paste error.This patch simply
replace string xgene_storm with xilink_zymp for xilink
platform.
Signed-off-by: Amit Singh Tomar
---
xen/arch/arm/platforms/xilinx-zynqmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp
On 25/01/18 13:43, Jan Beulich wrote:
On 24.01.18 at 14:12, wrote:
>> --- a/xen/include/asm-x86/spec_ctrl_asm.h
>> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
>> @@ -20,6 +20,11 @@
>> #ifndef __X86_SPEC_CTRL_ASM_H__
>> #define __X86_SPEC_CTRL_ASM_H__
>>
>> +/* Encoding of the bottom bits in
On 01/25/2018 12:31 AM, Bitweasil . wrote:
> I've recently discovered that if you attempt to use introspection to
> capture CR3 changes with the new KPTI enabled kernels, the guest dies
> shortly after the start of introspection with failed VM entry due to
> invalid guest state.
>
> I believe the
>>> On 25.01.18 at 15:46, wrote:
> On 25/01/18 14:36, Jan Beulich wrote:
> On 25.01.18 at 15:12, wrote:
>>> On 25/01/18 13:08, Jan Beulich wrote:
It may also be worthwhile again to pull up the zeroing of %edx,
using %dl instead of $0 in the movb (and maybe then also
similarly i
Roger Pau Monné writes ("Re: [PATCH] xen: fix xsm build"):
> On Thu, Jan 25, 2018 at 01:14:24PM +, Wei Liu wrote:
> > Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
> > XSM handles.
> >
> > Signed-off-by: Wei Liu
>
> Reviewed-by: Roger Pau Monné
Acked-by: Ian Jackso
On 25/01/18 15:08, Jan Beulich wrote:
On 25.01.18 at 15:46, wrote:
>> On 25/01/18 14:36, Jan Beulich wrote:
>> On 25.01.18 at 15:12, wrote:
On 25/01/18 13:08, Jan Beulich wrote:
> It may also be worthwhile again to pull up the zeroing of %edx,
> using %dl instead of $0 in th
>>> On 25.01.18 at 16:04, wrote:
> On 25/01/18 13:43, Jan Beulich wrote:
> On 24.01.18 at 14:12, wrote:
>>> @@ -256,6 +261,69 @@
>>> DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_SET, \
>>> DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_CLEAR
>>>
>>> +/* TOD
On 25/01/18 15:14, Jan Beulich wrote:
On 25.01.18 at 16:04, wrote:
>> On 25/01/18 13:43, Jan Beulich wrote:
>> On 24.01.18 at 14:12, wrote:
@@ -256,6 +261,69 @@
DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_SET, \
DO_SPEC_CTRL_EXIT_TO_GUEST,
flight 118327 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118327/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 118326
Tests which
George Dunlap writes ("Re: [PATCH v3 3/7] coverage: introduce generic file"):
> I'm pretty sure the copyright starts from the time the work is created,
> not the time it gets checked into a public tree. Most of this would
> have been written last year.
>
> Since we're being pedantic. ;-)
`(maint
On Thu, Jan 25, 2018 at 02:03:35PM +, George Dunlap wrote:
> On Thu, Jan 25, 2018 at 9:14 AM, Roger Pau Monné wrote:
> > On Wed, Jan 24, 2018 at 06:03:28PM +, George Dunlap wrote:
> >> On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne
> >> wrote:
> >> > Since VCPUOP_{up/down} already iden
On 01/25/2018 09:36 AM, Juergen Gross wrote:
Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
the address of the RSDP table given to the kernel via Xen start info.
This makes the kernel boot again in PVH mode after on recent Xen the
RSDP was moved to higher addresses. So up t
>>> On 24.01.18 at 14:12, wrote:
> @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu
> *next)
> }
>
> ctxt_switch_levelling(next);
> +
> +if ( opt_ibpb && !is_idle_domain(nextd) )
Is the idle domain check here really useful?
> +{
> +
I have installed `linux-image-amd64-dbg` and `binutils`.
I can now execute `addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 `.
I have generated a file "commands.txt" with all the addresses after
"Guest stack trace from rsp=82003cb0:" in my log file
"dom0_crash_with_dom0_memory.txt".
I
On 25/01/18 15:57, Jan Beulich wrote:
On 24.01.18 at 14:12, wrote:
>> @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu
>> *next)
>> }
>>
>> ctxt_switch_levelling(next);
>> +
>> +if ( opt_ibpb && !is_idle_domain(nextd) )
> Is the idle domai
>>> On 25.01.18 at 16:19, wrote:
> On 25/01/18 15:14, Jan Beulich wrote:
> On 25.01.18 at 16:04, wrote:
>>> On 25/01/18 13:43, Jan Beulich wrote:
>>> On 24.01.18 at 14:12, wrote:
> @@ -256,6 +261,69 @@
> DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_SET, \
>
Hi Manish,
On 16/01/18 15:42, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
In order to start handling guest access to GICv3 system registers,
let's add a hook that will get called when we trap a system register
access.
This handling code is kept independent of other traps.
Set CONFIG_VG
CC'ing Dario with a working email address this time...
On 25/01/18 16:09, Andrew Cooper wrote:
> On 25/01/18 15:57, Jan Beulich wrote:
> On 24.01.18 at 14:12, wrote:
>>> @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu
>>> *next)
>>> }
>>>
>>> ctx
>>> On 25.01.18 at 17:09, wrote:
> On 25/01/18 15:57, Jan Beulich wrote:
> On 24.01.18 at 14:12, wrote:
>>> @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu
>>> *next)
>>> }
>>>
>>> ctxt_switch_levelling(next);
>>> +
>>> +if ( opt_ibpb &&
flight 118299 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 broken in 118267
test-amd64-i386-xl-qemuu-debianh
Hi Manish,
On 16/01/18 15:42, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.
This commit (and likely the followings) is coming from Linux, right? If
it matc
On 25/01/18 16:31, Jan Beulich wrote:
On 25.01.18 at 17:09, wrote:
>> On 25/01/18 15:57, Jan Beulich wrote:
>> On 24.01.18 at 14:12, wrote:
@@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu
*next)
}
ctxt_switch_levelli
Hi,
On 16/01/18 15:43, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
gicv3_ich_read/write_lr functions are static in gic-v3.c
This patch creates wrapper functions which can be used from outside the file.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3.c| 10 ++
x
We need to be able to either set or clear IBRS in Xen context, as well as
restore appropriate guest values in guest context. See the documentation in
asm-x86/spec_ctrl_asm.h for details.
With the contemporary microcode, writes to %cr3 are slower when SPEC_CTRL.IBRS
is set. Therefore, the positio
ret instructions are speculated directly to values recorded in the Return
Stack Buffer/Return Address Stack, as there is no uncertainty in well-formed
code. Guests can take advantage of this in two ways:
1) If they can find a path in Xen which executes more ret instructions than
call instr
Hi Manish,
On 16/01/18 15:43, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
In order to be able to trap Group-1 GICv3 system registers, we need to
set ICH_HCR_EL2.TALL1 before entering the guest. This is controlled by
the command line parameter group1_trap.
I was expecting a patch to e
On 01/23/2018 09:56 AM, Jan Beulich wrote:
> As XSAs 246 and 247 have shown, not doing so is rather dangerous.
>
> Signed-off-by: Jan Beulich
> Acked-by: Andrew Cooper
> Acked-by: Kevin Tian
Thanks,
Reviewed-by: George Dunlap
___
Xen-devel mailing
1 - 100 of 143 matches
Mail list logo
