On 05/31/2018 09:25 AM, Dan Carpenter wrote:
"sndif_format" needs to be signed for the error handling to work.
Fixes: 1cee559351a7 ("ALSA: xen-front: Implement ALSA virtual sound driver")
Signed-off-by: Dan Carpenter
diff --git a/sound/xen/xen_snd_front_alsa.c b/sound/xen/xen_snd_front_alsa.c
On 05/31/2018 09:25 AM, Dan Carpenter wrote:
We want the loop to exit when "to" is set to zero, but in the current
code it's set to -1. Also I tweaked the indenting so it doesn't look
like we're passing "--to" to xenbus_read_unsigned().
Fixes: cc3196ae197c ("ALSA: xen-front: Introduce Xen para-
We want the loop to exit when "to" is set to zero, but in the current
code it's set to -1. Also I tweaked the indenting so it doesn't look
like we're passing "--to" to xenbus_read_unsigned().
Fixes: cc3196ae197c ("ALSA: xen-front: Introduce Xen para-virtualized sound
frontend driver")
Signed-off
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 allocating buffers suitable for DMA
xen/gntdev: Allo
flight 123379 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123379/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail
REGR. vs. 123323
t
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 provid
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 allocat
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: Oleksa
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 pc
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 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:
>> --- a/tools
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 initial
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 sp
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 saver
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 sav
> -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;
> konrad.w...@oracle.co
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 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 a
+
+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 mailing
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
platf
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 "arch/arm/configs/arm32_defconfig"
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 ev
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 f
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
> ---
> driver
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 c
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 AR
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 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) )
+{
+
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 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:
+/**
+ * gnttab_
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
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
test-amd64-i386-i386
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
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 b
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
test-amd64-amd64-xl-q
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 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 Andrushc
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 (0)
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
>> + */
>> +int gnttab_dma_free_pages(
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
Hi Stefano,
Sure. I will look into those documents. Thanks a lot.
Chaitanya
On Wed, May 30, 2018 at 9:18 AM, 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 di
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 pa
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]
https://cloud
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 v
/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 the
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
T
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
https://lists.xenproject.o
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 sho
>>> 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
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 d92336541782f9d51b6a6
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
tes
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 encoding
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 --gi
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
---
xen/arch/x86/cpu/ipt
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. A
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 +
x
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 avail
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).
Signed-off
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 10
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: V
>>> On 30.05.18 at 12:28, wrote:
> 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
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 s
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 thoug
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 b/sound/
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 x
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 ha
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 +++-
>>> 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 t
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
arm_smccc_1_1_smc(
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 38c7e1eefbb9..68d
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 val
>>> 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 pr
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
pv_doma
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 fc58
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 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
test-amd64-
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 when
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 handling
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") break
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 Spec
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 ups
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
While the involved code (in pv_domain_initialise()) sits behind an
!is_idle_domain() check already, we need to add one here.
Signed-off-by: Jan Beulich
---
The further backport to 4.8 and older is going to look quite a bit
different; a one-liner looks to suffice there.
--- a/xen/arch/x86/domain.
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 an
>>> 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
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
> 'GFP_KERNEL|__
On Ma, 2018-05-22 at 07:44 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 22.05.18 at 15:35, wrote:
> > On Ma, 2018-05-22 at 03:49 -0600, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 18.05.18 at 20:30, wrote:
> > > > On 05/18/2018 06:30 PM, Jan Beulich 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 any user, whether or
> > driver and fs, they should make a dec
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 t
>>> 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 pci_setup(void)
/* Create a list of device BARs in descend
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
---
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 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
>>> 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 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 re
1 - 100 of 101 matches
Mail list logo
