flight 111083 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
110465
Regressions
>>> Marek Marczykowski-Górecki 06/28/17 3:09
>>> AM >>>
>It's bit 9 not 10 (which is ibs).
Indeed, but shouldn't it rather be removed? We don't expose it from the
hypervisor at all anymore:
XEN_CPUFEATURE(OSVW, 3*32+ 9) /* OS Visible Workaround */
(note the absence of any marker cha
>@@ -158,6 +162,38 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list
>*cpuid, const char* str)
>{"de", 0x0001, NA, CPUID_REG_EDX, 2, 1},
>{"vme", 0x0001, NA, CPUID_REG_EDX, 1, 1},
>{"fpu", 0x0001, NA, CPUID_REG_EDX, 0,
This run is configured for baseline tests only.
flight 71610 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71610/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-libvirt5 libvirt-buildfai
flight 111086 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111086/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
110441
test-amd64-a
This patch partially reverts 3df0e50 ("xen/blkfront: pseudo support for
multi hardware queues/rings"). The xen-blkfront queue/ring might hang due
to grants allocation failure in the situation when gnttab_free_head is
almost empty while many persistent grants are reserved for this queue/ring.
As pe
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
drivers/xen/events/events_base.c
between commit:
ef1c2cc88531 ("xen/events: Add support for effective affinity mask")
from the tip tree and commit:
c48f64ab4723 ("xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to nex
This run is configured for baseline tests only.
flight 71609 qemu-upstream-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71609/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-s
flight 111078 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111078/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 6 xen-install fail REGR. vs. 110550
Tests which did
flight 111084 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111084/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 4 host-install(4)broken REGR. vs. 111061
test-arm64-arm64-libvir
This adds handling more cpuid bits by name. Mostly based on cpu_map.xml from
libvirt.
There are also some differences - looks like different naming in Intel and AMD
documentation (and sometimes also Linux). For example "pni" vs "sse3". Is it ok
to add those alternative names too? There is already s
This is result of parsing cpu_map.xml from libvirt.
The most important part is handling leaf 0x0007, but while at it add
other bits too.
Signed-off-by: Marek Marczykowski-Górecki
---
docs/man/xl.cfg.pod.5.in | 20
tools/libxl/libxl_cpuid.c | 37 +
It's bit 9 not 10 (which is ibs).
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libxl/libxl_cpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 1cf7973..a4a69af 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/
i...@xenbits.xen.org writes ("[adhoc test] 12: regressions - FAIL"):
> [adhoc adhoc] <3testing.git (no branch) /dev/pts/29>
> harness 702ce3d: sg-run-job: Logfiles: Suppress links to 0-length file...
> 12: regressions - FAIL
>
> flight 12 xen-unstable adhoc [real]
> http://logs.test-la
flight 21 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/21/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 13 mig
On Tue, 27 Jun 2017, Peter Maydell wrote:
> So, there is exactly one caller of main_loop_wait() in the tree that
> passes it 'true' as an argument. That caller is in xen_init_display()
> in hw/dispaly/xenfb.c. The function was added in 2009 with the comment
> "FIXME/TODO: Kill this. Temporary neede
flight 111081 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
110515
test-amd64-
On Wed, 28 Jun 2017, at 04:29, Marek Marczykowski-Górecki wrote:
> /home/user/rpmbuild/BUILD/xen-4.8.1/stubdom/vtpmmgr/vtpm_cmd_handler.c:555:
> undefined reference to `tpmrsa_free'
Hi,
I think this was fixed for me with:
Olaf Hering's [Xen-devel] [PATCH] vtpmmgr: make inline functions static
htt
flight 111093 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111093/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat
fail REGR. vs. 110537
Tests whi
On Wed, 21 Jun 2017, Paul Durrant wrote:
> Paul Durrant (3):
> xen-disk: only advertize feature-persistent if grant copy is not
> available
> xen-disk: add support for multi-page shared rings
> xen-disk: use an IOThread per instance
>
> hw/block/trace-events | 7 ++
> hw/block/xen_dis
From: Paul Durrant
The blkif protocol has had provision for negotiation of multi-page shared
rings for some time now and many guest OS have support in their frontend
drivers.
This patch makes the necessary modifications to xen-disk support a shared
ring up to order 4 (i.e. 16 pages).
Signed-off
Rather than constructing a local structure instance on the stack, fill
the fields directly on the shared ring, just like other (Linux)
backends do. Build on the fact that all response structure flavors are
actually identical (aside from alignment and padding at the end).
This is XSA-216.
Reported
llini/qemu-dm.git tags/xen-20170627-tag
for you to fetch changes up to 3284fad7283596033cb810b4788fd1bb43312dbd:
xen-disk: add support for multi-page shared rings (2017-06-27 15:01:56 -0700)
Xen
From: Paul Durrant
If grant copy is available then it will always be used in preference to
persistent maps. In this case feature-persistent should not be advertized
to the frontend, otherwise it may needlessly copy data into persistently
granted buffers.
Signed-off-by: Paul Durrant
Signed-off-b
This run is configured for baseline tests only.
flight 71608 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71608/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 15 gu
flight 19 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/19/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 111075
Tests which
flight 111077 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111077/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt15 guest-saverestore fail in 111047 pass in 111077
test-armhf-armhf-xl
flight 05 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/05/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 157fb7bf29eea497b22025f53b5547e4748b6c2d
baseline version:
ovmf 980af1eb0b7ad7a55fc51
On 27/06/2017, 17:16, "Jan Beulich" wrote:
Lars Kurth 06/27/17 10:54 AM >>>
>>- Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
>>- Hardware > x86/AVX512/Multiply Accumulation Single precision
>>AVX512_4FMAPS* : ???
>
>For one I think mentioning enabling of individu
On Mon, 26 Jun 2017, Wei Liu wrote:
> Since ARM doesn't need do_nmi_op, move the hypercall handler from
> common/kernel.c to pv/callback.c. Drop the stubs in ARM. Delete the
> common and ARM nmi.h and adjust header inclusions in various files.
>
> Signed-off-by: Wei Liu
Acked-by: Stefano Stabell
>>> "Jan Beulich" 06/27/17 9:29 PM >>>
Boris Ostrovsky 06/22/17 8:56 PM >>>
>> +/* Can't ACCESS_ONCE() a bitfield. */
>> +pg.u.free.val = ACCESS_ONCE(head->u.free.val);
>
>Something like ACCESS_ONCE(head->u.free).val ought to work (or read_atomic(),
>due to the questi
>>> Boris Ostrovsky 06/22/17 8:56 PM >>>
> Add a debug Kconfig option that will make page allocator verify
> that pages that were supposed to be scrubbed are, in fact, clean.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
___
Xen-devel
>>> Boris Ostrovsky 06/22/17 8:56 PM >>>
> Changes in v5:
> * Fixed off-by-one error in setting first_dirty
> * Changed struct page_info.u.free to a union to permit use of ACCESS_ONCE in
> check_and_stop_scrub()
I don't see the need for this:
> +static void check_and_stop_scrub(struct page_inf
flight 16 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/16/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 111075
build-armhf
On 27/06/17 19:31, Jan Beulich wrote:
Wei Liu 06/26/17 6:29 PM >>>
>> Since ARM doesn't need do_nmi_op, move the hypercall handler from
>> common/kernel.c to pv/callback.c.
> There are two handlers you actually move, and while their neither large nor
> likely to change, I still somewhat disli
Hello Anthony,
See my response below.
Jason
On 6/27/2017 12:36 PM, Anthony PERARD wrote:
On Tue, Jun 27, 2017 at 10:19:26AM +0100, Wei Liu wrote:
CC Anthony and Stefano
On Mon, Jun 26, 2017 at 01:55:56PM -0400, Jason Dickens wrote:
I would like to inquire about q35 support in Xen? As far as
>>> Marek Marczykowski-Górecki 06/27/17 7:35
>>> PM >>>
>GCC 7 is too sensitive here.
>See https://bugs.debian.org/853710
The issue pointed out in that bug was fixed already without disabling the
generally useful warning. That fix has been backported to the 4.8 branch
already.
Jan
___
>>> Andrew Cooper 06/27/17 7:48 PM >>>
>Coverity warns that pirq_dpci unconditionally dereferences a NULL pointer.
>This warning appears to be triggered by pirq_dpci() which is a hidden ternary
>expression. In reality, it appears that both callers pass a non-NULL pirq
>parameter, so the code is o
This run is configured for baseline tests only.
flight 71606 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71606/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 16 guest-sto
>>> Andrew Cooper 06/27/17 7:48 PM >>>
>Introduced by c/s fba00494268 "x86/pt: enable binding of GSIs to a PVH Dom0"
>
>Spotted by Coverity.
>
>Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
And I'm sorry for not having noticed while reviewing the original patch.
Jan
>>> Wei Liu 06/26/17 6:46 PM >>>
>@@ -148,6 +150,108 @@ void init_int80_direct_trap(struct vcpu *v)
>tb->flags = TBF_EXCEPTION | (TI_GET_IF(ti) ? TBF_INTERRUPT : 0);
>}
>
>+struct softirq_trap {
>+struct domain *domain; /* domain to inject trap */
>+struct vcpu *vcpu; /* vcp
>>> Wei Liu 06/26/17 6:29 PM >>>
>Since ARM doesn't need do_nmi_op, move the hypercall handler from
>common/kernel.c to pv/callback.c.
There are two handlers you actually move, and while their neither large nor
likely to change, I still somewhat dislike the code duplication you introduce.
But I g
Hi,
I'm having troubles with building Xen with GCC 7 (Fedora 26). Some of
the problems are fixed by "Compilation fixes for GCC 7" patch series
sent a moment ago, but then I've stumbled on link failure of vtpmmgr
stubdomain, related to some functions of tpm_emulator. I've already tried
with -fkeep-
This run is configured for baseline tests only.
flight 71607 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71607/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-libvirt5 libvirt-buildfai
On 27/06/17 19:21, Jan Beulich wrote:
Wei Liu 06/26/17 6:29 PM >>>
>> Rename it to pv_raise_interrupt.
> Is "interrupt" really a suitable term here? These are all exceptions being
> raised, not (external) interrupts.
This function is really NMIs and MCEs only, and it only gets used for
the f
>>> Wei Liu 06/26/17 6:29 PM >>>
>--- a/xen/arch/x86/traps.c
>+++ b/xen/arch/x86/traps.c
>@@ -1934,21 +1934,29 @@ void __init init_idt_traps(void)
>this_cpu(compat_gdt_table) = boot_cpu_compat_gdt_table;
>}
>
>+void __init pv_trap_init(void)
>+{
>+/* The 32-on-64 hypercall vector is onl
>>> Wei Liu 06/26/17 6:29 PM >>>
>Rename it to pv_raise_interrupt.
Is "interrupt" really a suitable term here? These are all exceptions being
raised, not (external) interrupts.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.
>>> Andrew Cooper 06/27/17 8:06 PM >>>
>On 26/06/17 17:28, Wei Liu wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1934,21 +1934,29 @@ void __init init_idt_traps(void)
>> this_cpu(compat_gdt_table) = boot_cpu_compat_gdt_table;
>> }
>>
>> +void __init pv_trap_init(
On 26/06/17 17:28, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 26/06/17 17:28, Wei Liu wrote:
> @@ -148,6 +150,108 @@ void init_int80_direct_trap(struct vcpu *v)
> tb->flags = TBF_EXCEPTION | (TI_GET_IF(ti) ? TBF_INTERRUPT : 0);
> }
>
> +struct softirq_trap {
> +struct domain *domain; /* domain to inject trap */
> +struct vcpu *vcpu;
On 26/06/17 17:28, Wei Liu wrote:
> Make register_guest_nmi_callback return int and make
> unregister_guest_nmi_callback void. Adjust the callers where
> necessary.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-d
On 26/06/17 17:28, Wei Liu wrote:
> Since ARM doesn't need do_nmi_op, move the hypercall handler from
> common/kernel.c to pv/callback.c. Drop the stubs in ARM. Delete the
> common and ARM nmi.h and adjust header inclusions in various files.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
On 26/06/17 17:28, Wei Liu wrote:
> Move these helper functions along side their users. Now all users of
> these functions are within the same file, make them static.
>
> Take the chance to change v to curr and remove some unneeded
> parentheses.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Coo
On 26/06/17 17:28, Wei Liu wrote:
> Factor out pv_trap_init and call it at the beginning of trap_init. We
> then need to tune the code to generate stub handlers in entry.S. Take
> the chance to tune init_irq_data so that 0x80 and 0x82 can be used in
> !CONFIG_PV case.
"used for regular interrupts
On 26/06/17 17:28, Wei Liu wrote:
> Rename it to pv_raise_interrupt. Simplify the code by using the vcpu
> structure already at hand in the caller.
double space.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-d
>>> Boris Ostrovsky 06/22/17 8:56 PM >>>
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1019,15 +1019,85 @@ static int reserve_offlined_page(struct page_info
> *head)
> return count;
> }
>
> -static void scrub_free_pages(unsigned int node)
> +static nodemask_t node_
>>> Boris Ostrovsky 06/22/17 8:55 PM >>>
> @@ -862,10 +879,19 @@ static struct page_info *alloc_heap_pages(
> if ( d != NULL )
> d->last_alloc_node = node;
>
> +need_scrub = !!first_dirty_pg && !(memflags & MEMF_no_scrub);
No need for !! here. But I wonder whether that part of
>>> Boris Ostrovsky 06/22/17 8:56 PM >>>
> This will make code a bit more readable, especially with changes that
> will be introduced in subsequent patches.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-deve
On 27/06/17 09:48, Wei Liu wrote:
> On Tue, Jun 27, 2017 at 12:13:19AM -0600, Jan Beulich wrote:
> Wei Liu 06/26/17 6:29 PM >>>
>>> --- a/xen/arch/x86/pv/Makefile
>>> +++ b/xen/arch/x86/pv/Makefile
>>> @@ -1,6 +1,7 @@
>> >obj-y += hypercall.o
>> >obj-y += traps.o
>> >
>>> +obj-y += callback
Introduced by c/s fba00494268 "x86/pt: enable binding of GSIs to a PVH Dom0"
Spotted by Coverity.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/drivers/passthrough/io.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/drivers/passthrough/io.c b/xen/
Coverity warns that pirq_dpci unconditionally dereferences a NULL pointer.
This warning appears to be triggered by pirq_dpci() which is a hidden ternary
expression. In reality, it appears that both callers pass a non-NULL pirq
parameter, so the code is ok in practice.
Rearange the logic to fail-s
On Tue, Jun 27, 2017 at 3:48 AM, Razvan Cojocaru
wrote:
> Hello,
>
>> - Security > Alternative 2pm : Supported – I think we should split this
>> out – it is currently implicitly covered under "Virtual Machine
>> Introspection"
>
> I agree that altp2m deserves its own space. While we're interested
On Tue, Jun 27, 2017 at 8:25 AM, Razvan Cojocaru
wrote:
> On 06/27/2017 02:45 PM, Jan Beulich wrote:
> Razvan Cojocaru 06/27/17 1:38 PM >>>
>>> On 06/27/2017 02:26 PM, Jan Beulich wrote:
>>> Razvan Cojocaru 06/27/17 10:32 AM >>>
> On 06/27/2017 09:21 AM, Jan Beulich wrote:
>
GCC-7 have -Wimplicit-fallthrough enabled with -Wextra. Add appropriate
comment which both mute the warning and improve readibility.
Signed-off-by: Marek Marczykowski-Górecki
---
stubdom/Makefile| 1 +
stubdom/vtpm-implicit-fallthrough.patch | 10 ++
2 files chan
GCC 7 is too sensitive here.
See https://bugs.debian.org/853710
Signed-off-by: Marek Marczykowski-Górecki
---
Config.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/Config.mk b/Config.mk
index 1ddcd58..7af5af9 100644
--- a/Config.mk
+++ b/Config.mk
@@ -216,6 +216,7 @@ $(call
cc-option-ad
Some compilation fixes for GCC 7, done in Fedora 26 environment.
This isn't complete yet - some compilation issues are still there (more on it
in separate thread), but those patches do solve some problems.
Additionally Xen 4.6 - 4.8 (haven't checked others) require those patches to be
backported:
GCC 7 warns (and thanks to -Werror, fails) about potential string
truncation by snprintf in get_next_battery_file. Since the code already
check if string is no longer than 4 chars, tell gcc about it.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/xenpmd/xenpmd.c | 8
1 file changed
This patch set is part of a set of patchs that together allow containment
of unrecoverable AER errors from PCIe devices assigned to guests in
passthrough mode. The containment is achieved by killing the guest and
hiding the device upon receiving the fatal AER error.
The Xen patch related to this p
docs: Document the new commands.
Add documentation for the newly added commands "pci-assignable-hide",
"pci-assignable-unhide", and "pci-assignable-list-hidden".
Signed-off-by: Venu Busireddy
---
docs/man/xl.pod.1.in | 24
1 file changed, 24 insertions(+)
diff --git a/
libxl: Add wrappers for new commands and add AER error handler
Add wrappers for the newly introduced commands "pci-assignable-hide",
"pci-assignable-unhide", and "pci-assignable-list-hidden".
Implement the callback function to handle unrecoverable AER errors.
Signed-off-by: Venu Busireddy
---
tools/python/xc: Update pyxc_methods with new commands
Add pyxc_unhide_device() and pyxc_hide_device(), and update pyxc_methods.
Signed-off-by: Venu Busireddy
---
tools/python/xen/lowlevel/xc/xc.c | 84 +++
1 file changed, 84 insertions(+)
diff --git a/tools
xl: Add commands for hiding and unhiding pcie passthrough devices
Introduce three subcommands: 'xl pci-assignable-hide ' to hide a
device, 'xl pci-assignable-unhide ' to unhide a previously hidden
device, and 'xl pci-assignable-list-hidden' to list the hidden devices.
Changed create_domain() to r
xen: Add support for hiding and unhiding pcie passthrough devices
Add support for hiding and unhiding (by introducing two new hypercall
subops) pci devices that trigger AER fatal errors while assigned to
guests in passthrough mode. Hiding of the device is done by assigning
it to dom_xen dummy doma
This patch set is part of a set of patchs that together allow containment
of unrecoverable AER errors from PCIe devices assigned to guests in
passthrough mode. The containment is achieved by killing the guest and
hiding the device upon receiving the fatal AER error.
The overall approach is:
1. Ch
libxc: Add wrappers for new commands
Add wrappers for the newly introduced commands "pci-assignable-hide",
"pci-assignable-unhide", and "pci-assignable-list-hidden".
Signed-off-by: Venu Busireddy
---
tools/libxc/include/xenctrl.h | 4
tools/libxc/xc_domain.c | 38 +++
>>> Boris Ostrovsky 06/22/17 8:55 PM >>>
> I kept node_need_scrub[] as a global array and not a "per-node". I think
> splitting
> it should be part of making heap_lock a per-node lock, together with
> increasing
> scrub concurrency by having more than one CPU scrub a node.
Agreed - I hadn't mea
On Tue, Jun 27, 2017 at 10:19:26AM +0100, Wei Liu wrote:
> CC Anthony and Stefano
>
> On Mon, Jun 26, 2017 at 01:55:56PM -0400, Jason Dickens wrote:
> > I would like to inquire about q35 support in Xen? As far as I have been able
> > to tell, this has not been done? In the Xen version that I've be
flight 111072 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111072/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-vhd 10 debian-di-install fail in 111045 pass in 111072
test-armhf-armhf-xl
>>> Lars Kurth 06/27/17 10:54 AM >>>
>- Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
>- Hardware > x86/AVX512/Multiply Accumulation Single precision AVX512_4FMAPS*
>: ???
For one I think mentioning enabling of individual instructions (rather than
larger
sets) isn't rea
On Mon, Jun 26, 2017 at 12:12:18PM -0700, Stefano Stabellini wrote:
> On Mon, 26 Jun 2017, Jan Beulich wrote:
> > >>> Stefano Stabellini 06/23/17 8:43 PM >>>
> > >On Fri, 23 Jun 2017, Jan Beulich wrote:
> > >> >>> On 22.06.17 at 20:52, wrote:
> > >> > I am happy to write the code and/or the commi
On 27/06/17 09:53, Lars Kurth wrote:
Hi all, (I think I CCed all stake-holders)
Hi Lars,
to finish off the release documentation for 4.9, I need to add an extra
column
to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –
because I was travelling, this dropped of my radar. There
On Tue, 2017-06-27 at 21:05 +0530, Praveen Kumar wrote:
> Hi Dario and Jan,
>
> Sorry, I missed this update.
>
No problem.
> On Tue, Jun 20, 2017 at 7:24 PM, Dario Faggioli
> wrote:
> > In practise, the idea is ending up with something that is basically
> > identical to what was in Linux, befor
flight 111071 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 111025
test-amd64-amd64-xl-
On 6/27/17 4:53 AM, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> Cc: Doug Goldstein
> ---
> .travis.yml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 9121fcca40..f93dd6868e 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -71,6 +71,7 @@ addons:
On Tue, 2017-06-27 at 13:04 +0200, Lars Kurth wrote:
> > On 06/27/2017 12:33 PM, George Dunlap wrote:
> > > > == On A / B: I think we should add ==
> > > > - Resource Management > Null Scheduler : tech preview or
> > > > experimental
> > >
> > > I think that the interface is probably in a final fo
Hi Dario and Jan,
Sorry, I missed this update.
On Tue, Jun 20, 2017 at 7:24 PM, Dario Faggioli wrote:
>
> On Tue, 2017-06-20 at 01:26 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > >
> > > > > On 19.06.17 at 19:13, wrote:
> > > And here we are again. (I.e., in the cited Linux's commit
On Tue, Jun 27, 2017 at 11:04:15AM +, Lars Kurth wrote:
> Alright: as we seem to have consensus, I will add
>
> PV Protocols and Drivers* > default (net, block, console, keyboard, mouse,
> USB, framebuffer) : supported
>
>
> And I am going to backdate this up to 4.5 (and put ? before), as th
Add support to check if SME has been enabled and if memory encryption
should be activated (checking of command line option based on the
configuration of the default state). If memory encryption is to be
activated, then the encryption mask is set and the kernel is encrypted
"in place."
Signed-off-
Create a new function attribute, __nostackp, that can used to turn off
stack protection on a per function basis.
Signed-off-by: Tom Lendacky
---
include/linux/compiler-gcc.h |2 ++
include/linux/compiler.h |4
2 files changed, 6 insertions(+)
diff --git a/include/linux/compiler
Currently, native_make_p4d() is only defined when CONFIG_PGTABLE_LEVELS
is greater than 4. Create a macro that will allow for defining and using
native_make_p4d() when CONFIG_PGTABLES_LEVELS is not greater than 4.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/pgtable_types.h |5 +
Add the support to encrypt the kernel in-place. This is done by creating
new page mappings for the kernel - a decrypted write-protected mapping
and an encrypted mapping. The kernel is encrypted by copying it through
a temporary buffer.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_enc
Add a cmdline_find_option() function to look for cmdline options that
take arguments. The argument is returned in a supplied buffer and the
argument length (regardless of whether it fits in the supplied buffer)
is returned, with -1 indicating not found.
Signed-off-by: Tom Lendacky
---
arch/x86/i
Xen does not currently support SME for PV guests. Clear the SME CPU
capability in order to avoid any ambiguity.
Reviewed-by: Borislav Petkov
Reviewed-by: Juergen Gross
Signed-off-by: Tom Lendacky
---
arch/x86/xen/enlighten_pv.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xe
When accessing memory using /dev/mem (or /dev/kmem) use the proper
encryption attributes when mapping the memory.
To insure the proper attributes are applied when reading or writing
/dev/mem, update the xlate_dev_mem_ptr() function to use memremap()
which will essentially perform the same steps of
Update the KVM support to work with SME. The VMCB has a number of fields
where physical addresses are used and these addresses must contain the
memory encryption mask in order to properly access the encrypted memory.
Also, use the memory encryption mask when creating and using the nested
page table
Provide support so that kexec can be used to boot a kernel when SME is
enabled.
Support is needed to allocate pages for kexec without encryption. This
is needed in order to be able to reboot in the kernel in the same manner
as originally booted.
Additionally, when shutting down all of the CPUs w
Since video memory needs to be accessed decrypted, be sure that the
memory encryption mask is not set for the video ranges.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/vga.h | 14 +-
arch/x86/mm/pageattr.c |2 ++
drivers/gp
Add support to check if memory encryption is active in the kernel and that
it has been enabled on the AP. If memory encryption is active in the kernel
but has not been enabled on the AP, then set the memory encryption bit (bit
23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow th
The IOMMU is programmed with physical addresses for the various tables
and buffers that are used to communicate between the device and the
driver. When the driver allocates this memory it is encrypted. In order
for the IOMMU to access the memory as encrypted the encryption mask needs
to be included
Move the setting of the cpuinfo_x86.microcode field from amd_init() to
early_amd_init() so that it is available earlier in the boot process. This
avoids having to read MSR_AMD64_PATCH_LEVEL directly during early boot.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/
1 - 100 of 240 matches
Mail list logo
