Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
updates a host MSR load list entry with the current hardware value of
MSR_DEBUGCTL.
On VMExit, hardware automatically resets MSR_DEBUGCTL to 0. Later, when the
guest writes to MSR_DEBUGCTL, the current value in hardware
On 05/30/2018 06:54 PM, Boris Ostrovsky wrote:
On 05/30/2018 04:29 AM, Oleksandr Andrushchenko wrote:
On 05/29/2018 11:03 PM, Boris Ostrovsky wrote:
On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote:
On 05/29/2018 09:04 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr
flight 123350 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123350/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 6 xen-install fail REGR. vs. 122969
Hi,
Can you please avoid CC everyone on each patch? You can use
scripts/get_maintainers.pl on each patch to see who is required to be CCed.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
/commits/Joao-Martins/x86-xen-Combine-PV-features-to-be-disabled-in-xen_nopv/20180530-031040
base: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
config: x86_64-randconfig-s4-05301434 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save
On 05/30/2018 06:20 PM, Boris Ostrovsky wrote:
On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote:
On 05/29/2018 10:10 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
+/**
+ * gnttab_dma_free_pages - free DMAable pages
+ * @args: arguments to the function
+
On 5/30/2018 2:24 AM, Jan Beulich wrote:
On 30.05.18 at 01:33, wrote:
Would this be better suited ?
Almost.
The purpose of the validate function is to fix an inherent race
condition which occurs with a vmexit.
After a vmexit, rereading the instruction for emulation is inherently
racy, and a
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pygrub
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
On 05/30/2018 04:29 AM, Oleksandr Andrushchenko wrote:
> On 05/29/2018 11:03 PM, Boris Ostrovsky wrote:
>> On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote:
>>> On 05/29/2018 09:04 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
@@ -463,11 +457,6 @@
This run is configured for baseline tests only.
flight 74762 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74762/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 65e984cd8ad8ee0999f8b360372db647f031c806
baseline
I am not sure what the problem is. I would compared your partition table
with a standard Linux distro UEFI image [1] to see if there are any
important differences. Checkout the UEFI spec [2] section 13.3.1 onward
to read the details of the partitions and filesystem requirements.
[1]
Hi,
On 05/30/2018 05:18 PM, Stefano Stabellini wrote:
I am not sure what the problem is. I would compared your partition table
with a standard Linux distro UEFI image [1] to see if there are any
important differences. Checkout the UEFI spec [2] section 13.3.1 onward
to read the details of the
On 24/05/18 16:12, Jan Beulich wrote:
On 22.05.18 at 13:20, wrote:
>> The main purpose of this change is to allow us to set a specific MSR value,
>> without needing to know whether there is already a load/save list slot for
>> it.
>> Previously, callers wanting this property needed to call
flight 74761 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74761/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
74735
Manish, I'll take another look at the variable names. I might not have enough
time :).
>>
>>
>> On 05/23/2018 10:48 PM, Manish Jaggi wrote:
>>> Hi Sameer,
>>>
>>> General Comment, please use appropriate variable names for XXX_domain
>>> structures in code which is xen specific.
>> I thought that
On Tue, 29 May 2018, Jan Beulich wrote:
> >>> On 23.05.18 at 02:25, wrote:
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -26,6 +26,9 @@ config ARCH_DEFCONFIG
> > default "arch/arm/configs/arm32_defconfig" if ARM_32
> > default "arch/arm/configs/arm64_defconfig" if
On Tue, 29 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 23/05/18 01:25, Stefano Stabellini wrote:
> > Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
> > RCAR3 and MPSOC. They enable the required options for their hardware
> > platform.
> >
> > They are introduced
On 5/25/2018 1:10 AM, Jan Beulich wrote:
On 24.05.18 at 22:26, wrote:
>> On 05/24/2018 01:57 AM, Jan Beulich wrote:
>> On 24.05.18 at 02:46, wrote:
--- /dev/null
+++ b/xen/include/xen/linux_compat.h
>>> I continue to dislike the idea of having a header with these contents in
On 5/17/2018 9:50 AM, Jan Beulich wrote:
On 07.05.18 at 23:07, wrote:
+void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec)
+{
+struct vlapic *vlapic = vcpu_vlapic(v);
+
+/* Fallback to use non-AVIC if vcpu is not enabled with AVIC. */
+if ( !svm_avic_vcpu_enabled(v) )
+{
On Wed, 30 May 2018, Julien Grall wrote:
> On 05/29/2018 11:34 PM, Stefano Stabellini wrote:
> > On Tue, 29 May 2018, Julien Grall wrote:
> > > On 25/05/18 21:51, Stefano Stabellini wrote:
> > > > On Thu, 24 May 2018, Julien Grall wrote:
> > > > > On 23/05/18 23:34, Stefano Stabellini wrote:
> > >
On 05/30/2018 01:49 PM, Oleksandr Andrushchenko wrote:
> On 05/30/2018 06:20 PM, Boris Ostrovsky wrote:
>> On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote:
>>> On 05/29/2018 10:10 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
+/**
+ *
On Tue, 29 May 2018, Jan Beulich wrote:
> >>> On 23.05.18 at 02:25, wrote:
> > UART drivers are now selectable by the user. To mark the change, remove
> > the HAS_ prefix.
>
> I'm not sure we need to go this far at this point - for MEM_ACCESS this
> looks reasonable, but here it looks more like
On Fri, May 25, 2018 at 06:33:24PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
>
On 05/30/2018 01:46 PM, Oleksandr Andrushchenko wrote:
> On 05/30/2018 06:54 PM, Boris Ostrovsky wrote:
>>
>>
>> BTW, I also think you can further simplify
>> xenmem_reservation_va_mapping_* routines by bailing out right away if
>> xen_feature(XENFEAT_auto_translated_physmap). In fact, you might
On Fri, May 25, 2018 at 06:33:29PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> 1. Create a dma-buf from grant references provided by the foreign
>domain. By default dma-buf is backed by system memory pages, but
>by providing GNTDEV_DMA_FLAG_XXX flags it can
On Wed, May 30, 2018 at 2:24 PM, Stefano Stabellini
wrote:
> On Tue, 29 May 2018, Jan Beulich wrote:
>> >>> On 23.05.18 at 02:25, wrote:
>> > --- a/xen/arch/arm/Kconfig
>> > +++ b/xen/arch/arm/Kconfig
>> > @@ -26,6 +26,9 @@ config ARCH_DEFCONFIG
>> > default
On 30/05/2018 22:39, Stefano Stabellini wrote:
On Tue, 29 May 2018, Julien Grall wrote:
Hi Stefano,
On 23/05/18 01:25, Stefano Stabellini wrote:
Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
RCAR3 and MPSOC. They enable the required options for their hardware
flight 123367 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123367/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122357
test-armhf-armhf-libvirt 14
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: Wednesday, May 30, 2018 11:15 PM
> To: Kang, Luwei ; xen-de...@lists.xen.org
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com;
> ian.jack...@eu.citrix.com; jbeul...@suse.com;
>
+
+static int arm_smmu_iommu_domain_init(struct domain *d)
>>> Where is iommu_domain initialized?
>>> The function does not use a iommu_domain * variable
Please check iommu.c 2 levels up.
Thanks,
Sameer
>>>
>>
>
>
> ___
> Xen-devel
On 30/05/2018 19:30, Natarajan, Janakarajan wrote:
> On 5/30/2018 2:24 AM, Jan Beulich wrote:
> On 30.05.18 at 01:33, wrote:
Would this be better suited ?
>>> Almost.
>>>
>>> The purpose of the validate function is to fix an inherent race
>>> condition which occurs with a vmexit.
>>>
>>>
On 05/31/2018 04:31 AM, Sameer Goel wrote:
+
+static int arm_smmu_iommu_domain_init(struct domain *d)
Where is iommu_domain initialized?
The function does not use a iommu_domain * variable
Please check iommu.c 2 levels up.
In this function do you see iommu_domain getting allocated or
flight 123381 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123381/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 121368
test-amd64-i386-xl-qemuu-win7-amd64 17
On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
Oleksandr Andrushchenko (8):
xen/grant-table: Make set/clear page private code shared
xen/balloon: Move common memory reservation routines to a module
xen/grant-table: Allow
On Wed, May 30, 2018 at 9:44 AM, Julien Grall wrote:
> Hi,
>
> On 05/30/2018 05:18 PM, Stefano Stabellini wrote:
>
>> I am not sure what the problem is. I would compared your partition table
>> with a standard Linux distro UEFI image [1] to see if there are any
>> important differences. Checkout
On Wed, 30 May 2018 02:13:30 -0600
"Jan Beulich" wrote:
On 30.05.18 at 06:32, wrote:
>>> On Wed, 30 May 2018 03:56:07 +1000
>>>Alexey G wrote:
>>>
On Tue, 29 May 2018 08:23:51 -0600
"Jan Beulich" wrote:
On 12.03.18 at 19:33, wrote:
>> ---
On 05/31/2018 02:10 AM, Dongwon Kim wrote:
On Fri, May 25, 2018 at 06:33:29PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by
On 05/31/2018 01:16 AM, Sameer Goel wrote:
Manish, I'll take another look at the variable names. I might not have enough
time :).
On 05/23/2018 10:48 PM, Manish Jaggi wrote:
Hi Sameer,
General Comment, please use appropriate variable names for XXX_domain
structures in code which is xen
On 05/31/2018 12:34 AM, Dongwon Kim wrote:
On Fri, May 25, 2018 at 06:33:24PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by:
On Wed, 30 May 2018 02:12:37 -0600
"Jan Beulich" wrote:
On 29.05.18 at 20:47, wrote:
>> On Wed, 30 May 2018 03:56:07 +1000
>> Alexey G wrote:
>>>On Tue, 29 May 2018 08:23:51 -0600
>>>"Jan Beulich" wrote:
>>> On 12.03.18 at 19:33, wrote:
> @@ -172,10 +173,14 @@ void
flight 123370 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123370/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123188
test-armhf-armhf-libvirt-xsm 14
On 05/30/2018 01:34 AM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
+/*
+ * Create a dma-buf [1] from grant references @refs of count @count provided
+ * by the foreign domain @domid with flags @flags.
+ *
+ * By default dma-buf is backed by system memory
On 05/25/2018 06:33 PM, Oleksandr Andrushchenko wrote:
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 3431fe210624..eaf63a2c7ae6 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -152,6 +152,16 @@ config XEN_GNTDEV
help
Allows userspace processes to
>>> On 30.05.18 at 01:33, wrote:
>> Would this be better suited ?
>
> Almost.
>
> The purpose of the validate function is to fix an inherent race
> condition which occurs with a vmexit.
>
> After a vmexit, rereading the instruction for emulation is inherently
> racy, and a malicious VM could
>>> On 29.05.18 at 20:08, wrote:
> On 29/05/18 11:33, Jan Beulich wrote:
> On 28.05.18 at 16:27, wrote:
>>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
>>> updates a host MSR load list entry with the current hardware value of
>>> MSR_DEBUGCTL. This is wrong.
>>
On 05/29/2018 10:10 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting
On 05/30/2018 12:52 AM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
struct unmap_notify {
@@ -96,10 +104,28 @@ struct grant_map {
struct gnttab_unmap_grant_ref *kunmap_ops;
struct page **pages;
unsigned long pages_vm_start;
+
flight 123345 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123345/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm broken
On 05/25/2018 06:33 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the module.
Signed-off-by: Oleksandr Andrushchenko
From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of
Michal Hocko
Sent: Monday, May 28, 2018 9:38 PM
> > In my opinion, originally there shouldn't be such many wrong
> > combinations of these bottom 3 bits. For any user, whether or
> > driver and fs, they should make a
Hi Stefano,
On 05/29/2018 10:30 PM, Stefano Stabellini wrote:
On Fri, 25 May 2018, Julien Grall wrote:
Hi Stefano,
On 05/23/2018 10:34 PM, Stefano Stabellini wrote:
On Tue, 22 May 2018, Julien Grall wrote:
Some errata will rely on the SMCCC version which is detected by
psci_init().
This is
>>> On 30.05.18 at 06:32, wrote:
>> On Wed, 30 May 2018 03:56:07 +1000
>>Alexey G wrote:
>>
>>>On Tue, 29 May 2018 08:23:51 -0600
>>>"Jan Beulich" wrote:
>>>
>>> On 12.03.18 at 19:33, wrote:
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
Hi Julien,
Thanks for the feedback.
On Tue, May 29, 2018 at 3:19 PM, Julien Grall wrote:
> Hi,
>
>
> On 15/05/18 12:44, Mirela Simonovic wrote:
>
>> Linux/dom0 accesses OSLSR register when saving CPU context during the
>> suspend procedure. Xen traps access to this register, but has no
On Wed, May 30, 2018 at 11:33:22AM +0200, Juergen Gross wrote:
> On 30/05/18 10:33, Greg KH wrote:
> > On Tue, May 29, 2018 at 03:11:36PM +0200, Juergen Gross wrote:
> >> Commit 944e0fc51a89c9827b98813d65dc083274777c7f ("x86/amd: don't set
> >> X86_BUG_SYSRET_SS_ATTRS when running under Xen")
flight 123347 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123347/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-install fail REGR. vs.
123144
On Wed, May 30, 2018 at 11:48 AM, Mirela Simonovic <
mirela.simono...@aggios.com> wrote:
> Hi Julien,
>
> Thanks for the feedback.
>
> On Tue, May 29, 2018 at 3:19 PM, Julien Grall
> wrote:
>
>> Hi,
>>
>>
>> On 15/05/18 12:44, Mirela Simonovic wrote:
>>
>>> Linux/dom0 accesses OSLSR register
>>> On 30.05.18 at 11:04, wrote:
> Sorry for the misunderstanding, I wanted to clarify if the 59:56 bits
> are fully ok to be used or if not then where should I use 4 bits to
> store the mem access info?
I thought I had sufficiently explained this - you have two options:
1) Make sure (via some
On Tue, May 29, 2018 at 03:11:36PM +0200, Juergen Gross wrote:
> Commit 944e0fc51a89c9827b98813d65dc083274777c7f ("x86/amd: don't set
> X86_BUG_SYSRET_SS_ATTRS when running under Xen") breaks Xen pv-domains
> on AMD processors, as a prerequisite patch from upstream wasn't added
> to 4.9.
What is
On Wed, May 30, 2018 at 09:02:13AM +, Huaisheng HS1 Ye wrote:
>
> I don't quite understand that. I think those, mostly drivers, need to
> get the correct zone they want. ZONE_DMA32 is an example, if drivers can be
> satisfied with a low mem zone, why they mark the gfp flags as
>
On Wed 30-05-18 09:02:13, Huaisheng HS1 Ye wrote:
> From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of
> Michal Hocko
> Sent: Monday, May 28, 2018 9:38 PM
> > > In my opinion, originally there shouldn't be such many wrong
> > > combinations of these bottom 3 bits. For
On 30/05/18 10:33, Greg KH wrote:
> On Tue, May 29, 2018 at 03:11:36PM +0200, Juergen Gross wrote:
>> Commit 944e0fc51a89c9827b98813d65dc083274777c7f ("x86/amd: don't set
>> X86_BUG_SYSRET_SS_ATTRS when running under Xen") breaks Xen pv-domains
>> on AMD processors, as a prerequisite patch from
From: Roger Pau Monne
The default DEBUG_DIR=/usr/lib/debug can not be used for rpm builds
because that directory is "owned" by rpm-packaging itself to store the
autogenerated ${pkg}-debuginfo.rpm data. Thats why I set it to /boot.
This worked fine until recently, only /boot/xen-syms was affected
flight 123402 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123402/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 06f542f8f2e446c01bd0edab51e9450af7f6e05b
baseline version:
xen
On Wed, 2018-05-30 at 11:46 +0200, Greg KH wrote:
> On Wed, May 30, 2018 at 11:33:22AM +0200, Juergen Gross wrote:
> >
> > On 30/05/18 10:33, Greg KH wrote:
> > >
> > > On Tue, May 29, 2018 at 03:11:36PM +0200, Juergen Gross wrote:
> > > >
> > > > Commit 944e0fc51a89c9827b98813d65dc083274777c7f
On 30/05/18 08:32, Jan Beulich wrote:
On 29.05.18 at 20:08, wrote:
>> On 29/05/18 11:33, Jan Beulich wrote:
>> On 28.05.18 at 16:27, wrote:
Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
updates a host MSR load list entry with the current hardware
On 05/29/2018 11:03 PM, Boris Ostrovsky wrote:
On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote:
On 05/29/2018 09:04 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
@@ -463,11 +457,6 @@ static enum bp_state
increase_reservation(unsigned long nr_pages)
>>> On 30.05.18 at 07:54, wrote:
> flight 123343 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/123343/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-rumprun-amd64 7 xen-boot
Hi,
On 05/29/2018 10:35 PM, Stefano Stabellini wrote:
On Sat, 26 May 2018, Andrew Cooper wrote:
On 25/05/2018 21:51, Stefano Stabellini wrote:
On Wed, 23 May 2018, Julien Grall wrote:
Hi,
On 05/23/2018 10:57 PM, Stefano Stabellini wrote:
On Tue, 22 May 2018, Julien Grall wrote:
As for
On 30/05/18 09:55, Jan Beulich wrote:
> While the involved code (in pv_domain_initialise()) sits behind an
> !is_idle_domain() check already, we need to add one here.
I'm afraid that I struggled to understand what you meant here. AFACIT,
you mean that the backport over the introduction of
There is no need to set the same capabilities for each cpu
individually. This can easily be done for all cpus when starting the
kernel.
Upstream commit: 0808e80cb760de2733c0527d2090ed2205a1eef8 ("xen: set
cpu capabilities from xen_start_kernel()")
Signed-off-by: Juergen Gross
Reviewed-by: Boris
Revert commit 944e0fc51a89c9827b98813d65dc083274777c7f ("x86/amd: don't
set X86_BUG_SYSRET_SS_ATTRS when running under Xen") as it is lacking
a prerequisite patch and is making things worse.
Signed-off-by: Juergen Gross
---
arch/x86/kernel/cpu/amd.c | 5 ++---
arch/x86/xen/enlighten.c | 4 +++-
When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
on AMD cpus.
This bug/feature bit is kind of special as it will be used very early
when switching threads. Setting the bit and clearing it a little bit
later leaves a critical window where things can go wrong. This time
window
On Mi, 2018-05-30 at 03:52 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 30.05.18 at 11:04, wrote:
> > Sorry for the misunderstanding, I wanted to clarify if the 59:56
> > bits
> > are fully ok to be used or if not then where should I use 4 bits to
> > store the mem access info?
> I
On Wed, 30 May 2018 13:14:58 +0200,
Oleksandr Andrushchenko wrote:
>
> On 05/30/2018 01:36 PM, Dan Carpenter wrote:
> > kfree() doesn't accept error pointers so I've set "str" to NULL on these
> > paths.
> >
> > Fixes: fd3b36045c2c ("ALSA: xen-front: Read sound driver configuration from
> > Xen
flight 123349 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123349/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-install fail REGR.
vs. 122997
>>> On 30.05.18 at 12:04, wrote:
> On 30/05/18 09:55, Jan Beulich wrote:
>> While the involved code (in pv_domain_initialise()) sits behind an
>> !is_idle_domain() check already, we need to add one here.
>
> I'm afraid that I struggled to understand what you meant here. AFACIT,
> you mean that
Above commit is a wrong backport, as it is based on a missing
prerequisite patch. Correct that by reverting said commit, include the
missing patch, and do the backport correctly.
Juergen Gross (3):
x86/amd: revert commit 944e0fc51a89c9827b98813d65dc083274777c7f
xen: set cpu capabilities from
>>> On 30.05.18 at 13:20, wrote:
> On Mi, 2018-05-30 at 03:52 -0600, Jan Beulich wrote:
>> >
>> > >
>> > > >
>> > > > On 30.05.18 at 11:04, wrote:
>> > Sorry for the misunderstanding, I wanted to clarify if the 59:56
>> > bits
>> > are fully ok to be used or if not then where should I use 4 bits
kfree() doesn't accept error pointers so I've set "str" to NULL on these
paths.
Fixes: fd3b36045c2c ("ALSA: xen-front: Read sound driver configuration from Xen
store")
Signed-off-by: Dan Carpenter
diff --git a/sound/xen/xen_snd_front_cfg.c b/sound/xen/xen_snd_front_cfg.c
index
Hi Stefano,
On 05/29/2018 11:34 PM, Stefano Stabellini wrote:
On Tue, 29 May 2018, Julien Grall wrote:
On 25/05/18 21:51, Stefano Stabellini wrote:
On Thu, 24 May 2018, Julien Grall wrote:
On 23/05/18 23:34, Stefano Stabellini wrote:
On Tue, 22 May 2018, Julien Grall
On 05/30/2018 01:36 PM, Dan Carpenter wrote:
kfree() doesn't accept error pointers so I've set "str" to NULL on these
paths.
Fixes: fd3b36045c2c ("ALSA: xen-front: Read sound driver configuration from Xen
store")
Signed-off-by: Dan Carpenter
diff --git a/sound/xen/xen_snd_front_cfg.c
Load/Restore Intel Processor Trace Register in context switch.
MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS.
When Intel Processor Trace is supported in guest, we need
to load/restore MSRs only when this feature is enabled
in guest.
Signed-off-by: Luwei Kang
---
Using EPT to translate PT output addresses introduces the possibility of
taking events on PT output reads and writes. Event possibilities include
EPT violations, EPT misconfigurations, PML log-full VM exits, and APIC
access VM exits.
EPT violations:
a. Intel PT buffer is a MMIO address in guest.
This patch add a new flag to enable Intel Processor Trace
in HVM guest by add parameter 'ipt = guest' in XEN
command line. Intel Processor Trace is disabled
in default.
Signed-off-by: Luwei Kang
---
docs/misc/xen-command-line.markdown | 10 +
xen/arch/x86/cpu/Makefile | 1 +
This patch configure VMCS to make Intel Processor Trace
output address can be treat as guest physical address and
translated by EPT when ipt option is in guest mode.
Intel Processor Trace will be disabled in guest and the VMCS
configuration will be clear when part of the required
features is
Add Intel Processor Trace MSRs read/write emulation.
If Intel Processor Trace is not supported in guest,
access not supported MSRs or access reserved bits,
a #GP will be injected to guest.
Signed-off-by: Luwei Kang
---
xen/arch/x86/cpu/ipt.c | 108
Disable Intel Processor Trace VMX operation(IA32_VMX_MISC[bit 14] is 0)
in L1 guest. As mentioned in SDM, on these type of processors, execution
of the VMXON instruction will clears IA32_RTIT_CTL.TraceEn and any
attempt to write IA32_RTIT_CTL causes a general-protection xception (#GP).
Add Intel Processor Trace MSRs and bit definitions.
Signed-off-by: Luwei Kang
---
xen/include/asm-x86/msr-index.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index 8fbccc8..7c02653
Any attempt to modify IA32_RTIT_CTL while TraceEn is set will
result in a #GP unless the same write also clears TraceEn.
Writes to IA32_RTIT_CTL that do not modify any bits will not
cause a #GP, even if TraceEn remains set.
MSR write that attempts to change bits marked reserved, or
utilize
Intel Processor Trace will be disabled in guest
when ipt_mode is off (IPT_MODE_OFF).
Signed-off-by: Luwei Kang
---
tools/libxc/xc_cpuid_x86.c | 12 ++--
xen/arch/x86/cpuid.c| 22 ++
xen/arch/x86/domctl.c
Hi All,
Here is a patch-series which adding Processor Trace enabling in XEN guest. You
can get It's software developer manuals from:
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
In Chapter 4 INTEL PROCESSOR TRACE:
Introduce a new function to check if a specific capability
of Intel Processor Trace is exists.
Signed-off-by: Luwei Kang
---
xen/arch/x86/cpu/ipt.c| 63 +++
xen/include/asm-x86/ipt.h | 19 ++
2 files changed, 82 insertions(+)
diff
flight 123356 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123356/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 65e984cd8ad8ee0999f8b360372db647f031c806
baseline version:
ovmf
On 30/05/18 12:29, Jan Beulich wrote:
On 30.05.18 at 13:20, wrote:
>> On Mi, 2018-05-30 at 03:52 -0600, Jan Beulich wrote:
>> On 30.05.18 at 11:04, wrote:
Sorry for the misunderstanding, I wanted to clarify if the 59:56
bits
are fully ok to be used or if not then where
94 matches
Mail list logo
