Marc-André Lureau writes:
> This is mostly for readability of the code. Let's make it clear which
> callers can create an implicit monitor when the chardev is muxed.
>
> This will also enforce a safer behaviour, as we don't really support
> creating monitor anywhere/anytime at the moment.
>
> The
On Fri 24-08-18 07:03:28, Juergen Gross wrote:
> On 23/08/18 21:09, Michal Hocko wrote:
> > On Thu 23-08-18 10:06:53, Boris Ostrovsky wrote:
> >> On 08/23/2018 09:51 AM, Michal Hocko wrote:
> >>> On Thu 23-08-18 22:44:07, Tetsuo Handa wrote:
> On 2018/08/23 21:07, Michal Hocko wrote:
> > d
On 24/08/18 00:33, Stefano Stabellini wrote:
Hi all,
Hi,
This patch series introduces one kconfig option for each remaing
platform under platforms/. Each kconfig option enables the required
drivers in Xen.
Cheers,
Stefano
Changes in v2:
- remove all platform options except for thunderx
Hi,
On 24/08/18 00:33, Stefano Stabellini wrote:
Add a kconfig option for Cavium ThunderX platforms. >
Signed-off-by: Stefano Stabellini
CC: mja...@caviumnetworks.com
CC: zi@cavium.com
---
Changes in v2:
- remove HAS_SMMU
---
xen/arch/arm/platforms/Kconfig | 13 +
xen/arch/a
Hi,
On 24/08/18 00:33, Stefano Stabellini wrote:
Add a Kconfig option to select no specific platform support.
That's not entirely true. After this series applied, there are still
some obj-y present in the Makefile.
Cheers,
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/platforms/K
Hi,
On 24/08/18 00:33, Stefano Stabellini wrote:
Add a kconfig option for Renesas Rcar2 platforms.
Signed-off-by: Stefano Stabellini
Reviewed-by: Andrii Anisov
CC: iurii.konovale...@globallogic.com
---
xen/arch/arm/platforms/Kconfig | 11 +++
xen/arch/arm/platforms/Makefile | 2 +
CC Ian
On Fri, Aug 24, 2018 at 12:32:57PM +1000, Steven Haigh wrote:
> Commit:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=3a2b8525b883baa87fe89b3da58f5c09fa599b99
>
> I've also run across this building the staging-4.9 branch on RHEL7.
>
> Build errors with:
> gcc -m64 -DBUILD_ID -fno
Cc Anthony
On Fri, Aug 24, 2018 at 12:56:49PM +1000, Steven Haigh wrote:
> Hi all,
>
> When trying to build both xen and qemu-xen from the staging-4.9 branches,
> I'm running into issues compiling.
>
> Errors start with:
>
> BUILDSTDERR: sse.c: In function 'simd_test':
> BUILDSTDERR: sse.c:319:
On Wed, Aug 22, 2018 at 04:52:27PM -0600, Jim Fehlig wrote:
> On 08/21/2018 05:14 AM, Jan Beulich wrote:
> > > > > On 21.08.18 at 03:11, wrote:
> > > flight 126201 xen-4.9-testing real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/126201/
> > >
> > > Regressions :-(
> > >
> > > T
Hi,
On 24/08/18 00:56, Stefano Stabellini wrote:
On Thu, 23 Aug 2018, Julien Grall wrote:
Hi Stefano,
2018 01:01 AM, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp_eemi: a function resposible for implementing access
s/resposible/responsible/
On Fri, Aug 24, 2018 at 12:58:43AM +, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-xl-shadow
> testid guest-start
>
> Tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Tree: linuxfirmware git://xenbits.x
On Wed, 2018-08-15 at 14:17 +0100, Andrew Cooper wrote:
> Hello,
>
> Now that the embargo on XSA-273 is up, we can start publicly
> discussing
> the remaining work do, because there is plenty to do. In no
> particular
> order...
>
>
> [...]
>
> 5) Core-aware scheduling. At the moment, Xen will
flight 126411 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126411/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 126322
test-amd64-i386-xl-qemuu-win7-amd64
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 24 August 2018 10:13
> To: osstest service owner
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Paul
> Durrant
> Subject: Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-
> xl-shadow
>
> On Fri, A
On Fri, Aug 24, 2018 at 10:30:26AM +0100, Paul Durrant wrote:
> > > For bisection revision-tuple graph see:
> > >http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-
> > 3.18/test-amd64-amd64-xl-shadow.guest-start.html
> > > Revision IDs in each graph node refer, respectively, to t
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 24 August 2018 10:35
> To: Paul Durrant
> Cc: Wei Liu ; osstest service owner ad...@xenproject.org>; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-
> xl-s
Hi again,
I debugged the kernel codes and found out the root cause.
The sharing is not done for some pages causing error -E2BIG which is due to
reference count being more than one. This prevents hypervor to nominate the
page. As much as I know about this issue, the page that I want to nominate
and
On Fri, Aug 24, 2018 at 10:35:52AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 24 August 2018 10:35
> > To: Paul Durrant
> > Cc: Wei Liu ; osstest service owner > ad...@xenproject.org>; xen-devel@lists.xenproject.org
> > Subje
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl
testid guest-start
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
Tr
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 24 August 2018 10:38
> To: Paul Durrant
> Cc: Wei Liu ; osstest service owner ad...@xenproject.org>; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-
> xl-s
On 8/24/18 8:07 AM, sepanta s wrote:
> I debugged the kernel codes and found out the root cause.
> The sharing is not done for some pages causing error -E2BIG which is due
> to reference count being more than one. This prevents hypervor to
> nominate the page. As much as I know about this issue, th
On Fri, Aug 24, 2018 at 10:44:09AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 24 August 2018 10:38
> > To: Paul Durrant
> > Cc: Wei Liu ; osstest service owner > ad...@xenproject.org>; xen-devel@lists.xenproject.org
> > Subje
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 24 August 2018 10:50
> To: Paul Durrant
> Cc: Wei Liu ; osstest service owner ad...@xenproject.org>; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-
> xl-s
The hvmloader binary generated when using LLVM LD doesn't work
properly and seems to get stuck while trying to generate and load the
ACPI tables. This is caused by the layout of the binary when linked
with LLVM LD.
LLVM LD has a different default linker script that GNU LD, and the
resulting hvmloa
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 24 August 2018 10:52
> To: Wei Liu
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; osstest
> service owner
> Subject: Re: [Xen-devel] [linux-3.18 bisection] complete
flight 126429 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
On Wed, Aug 22, 2018 at 10:45:28AM +0100, Wei Liu wrote:
> On Wed, Aug 22, 2018 at 09:51:57AM +0200, Roger Pau Monne wrote:
> > Introduce a new dom0-iommu=map-inclusive generic option that
> > supersedes iommu_inclusive_mapping. The previous behavior is preserved
> > and the option should only be e
On Fri, Aug 24, 2018 at 10:25:49AM +, osstest service owner wrote:
> flight 126429 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/126429/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-libv
On Wed, Aug 22, 2018 at 10:45:34AM +0100, Wei Liu wrote:
> On Wed, Aug 22, 2018 at 09:51:58AM +0200, Roger Pau Monne wrote:
> > Returns all the memory types applicable to a page.
> >
> > This function is unimplemented for ARM.
> >
> > Signed-off-by: Roger Pau Monné
> > Reviewed-by: Jan Beulich
flight 75115 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75115/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-jessie-netboot-pvgrub 19 guest-start/debian.repeat fail
REGR. vs. 75078
tes
Signed-off-by: Wei Liu
---
tools/firmware/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index ed1a1318f6..cf304fc578 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -15,7 +15,7 @@ SUBDIRS-$(CONF
Two more worries for this patch.
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> *
> * @amn: our notifier
> */
> -static void amdgpu_mn_read_lock(struct amdgpu_mn *amn)
> +st
On 07/30/2018, 10:18 AM, Xiao Liang wrote:
> On 07/29/2018 11:30 PM, David Miller wrote:
>> From: Xiao Liang
>> Date: Fri, 27 Jul 2018 17:56:08 +0800
>>
>>> @@ -1330,6 +1331,11 @@ static struct net_device
>>> *xennet_create_dev(struct xenbus_device *dev)
>>> netif_carrier_off(netdev);
>>>
On 24/08/18 13:12, Jiri Slaby wrote:
> On 07/30/2018, 10:18 AM, Xiao Liang wrote:
>> On 07/29/2018 11:30 PM, David Miller wrote:
>>> From: Xiao Liang
>>> Date: Fri, 27 Jul 2018 17:56:08 +0800
>>>
@@ -1330,6 +1331,11 @@ static struct net_device
*xennet_create_dev(struct xenbus_device *dev
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
> Two more worries for this patch.
>
>
>
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> > *
> > * @amn: our notifier
> >
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
[...]
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -177,16 +177,19 @@ static void hmm_release(struct mmu_notifier *mn,
> > struct mm_struct *mm)
> > up_write(&hmm->mirrors_sem);
> > }
> >
> > -static void hmm_invalidate_range_start(struct mmu
Am 24.08.2018 um 13:32 schrieb Michal Hocko:
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
Two more worries for this patch.
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
*
* @a
On Fri 24-08-18 13:43:16, Christian König wrote:
> Am 24.08.2018 um 13:32 schrieb Michal Hocko:
> > On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
> > > Two more worries for this patch.
> > >
> > >
> > >
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
Am 24.08.2018 um 13:32 schrieb Michal Hocko:
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
Two more worries for this patch.
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/a
On Fri 24-08-18 13:57:52, Christian König wrote:
> Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
> > > That won't work like this there might be multiple
> > > invalidate_range_start()/invalidate_range_end() pairs open at the same
> > > time
Versions of linux privcmd prior to commit dc9eab6fd94d ("return -ENOTTY
for unimplemented IOCTLs") will return -EINVAL rather than the conventional
-ENOTTY for unimplemented codes. This breaks the error path in
libxenforeignmemory resource mapping, which only translates ENOTTY into
EOPNOTSUPP to in
Am 24.08.2018 um 14:03 schrieb Michal Hocko:
On Fri 24-08-18 13:57:52, Christian König wrote:
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
That won't work like this there might be multiple
invalidate_range_start()/invalidate_range_end() p
On Fri 24-08-18 14:18:44, Christian König wrote:
> Am 24.08.2018 um 14:03 schrieb Michal Hocko:
> > On Fri 24-08-18 13:57:52, Christian König wrote:
> > > Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > > > On Fri 24-08-18 13:43:16, Christian König wrote:
> > [...]
> > > > > That won't work like t
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
On Fri 24-08-18 14:18:44, Christian König wrote:
Am 24.08.2018 um 14:03 schrieb Michal Hocko:
On Fri 24-08-18 13:57:52, Christian König wrote:
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
Tha
On Fri 24-08-18 14:52:26, Christian König wrote:
> Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
> > Thiking about it some more, I can imagine that a notifier callback which
> > performs an allocation might trigger a memory reclaim and that in turn
> > might trigger a notifier to be invoked an
On 2018/08/24 20:36, Michal Hocko wrote:
>> That is, this API seems to be currently used by only out-of-tree users. Since
>> we can't check that nobody has memory allocation dependency, I think that
>> hmm_invalidate_range_start() should return -EAGAIN if blockable == false for
>> now.
>
> The co
flight 126526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126526/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 126482
version targeted for testi
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
Thiking about it some more, I can imagine that a notifier callback which
performs an allocation might trigger a memory reclaim and that in turn
might
On Fri 24-08-18 15:10:08, Christian König wrote:
> Am 24.08.2018 um 15:01 schrieb Michal Hocko:
> > On Fri 24-08-18 14:52:26, Christian König wrote:
> > > Am 24.08.2018 um 14:33 schrieb Michal Hocko:
> > [...]
> > > > Thiking about it some more, I can imagine that a notifier callback which
> > > >
On Fri, Aug 24, 2018 at 01:16:26PM +0100, Paul Durrant wrote:
> Versions of linux privcmd prior to commit dc9eab6fd94d ("return -ENOTTY
> for unimplemented IOCTLs") will return -EINVAL rather than the conventional
> -ENOTTY for unimplemented codes. This breaks the error path in
> libxenforeignmemor
Am 24.08.2018 um 15:24 schrieb Michal Hocko:
On Fri 24-08-18 15:10:08, Christian König wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
Thiking about it some more, I can imagine that a noti
On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
> On 2018/08/24 20:36, Michal Hocko wrote:
> >> That is, this API seems to be currently used by only out-of-tree users.
> >> Since
> >> we can't check that nobody has memory allocation dependency, I think that
> >> hmm_invalidate_range_start() should r
On Fri 24-08-18 15:28:33, Christian König wrote:
> Am 24.08.2018 um 15:24 schrieb Michal Hocko:
> > On Fri 24-08-18 15:10:08, Christian König wrote:
> > > Am 24.08.2018 um 15:01 schrieb Michal Hocko:
> > > > On Fri 24-08-18 14:52:26, Christian König wrote:
> > > > > Am 24.08.2018 um 14:33 schrieb M
Am 24.08.2018 um 15:40 schrieb Michal Hocko:
On Fri 24-08-18 15:28:33, Christian König wrote:
Am 24.08.2018 um 15:24 schrieb Michal Hocko:
On Fri 24-08-18 15:10:08, Christian König wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2
On 17/08/18 17:59, Roger Pau Monné wrote:
> On Mon, Aug 13, 2018 at 04:01:09PM +0200, Juergen Gross wrote:
>> Persistent grants are used in the Xen's blkfront/blkback drivers to
>> avoid mapping/unmapping of I/O buffers in the backend for each I/O.
>>
>> While this speeds up processing quite a bit
On 13/08/18 09:37, Juergen Gross wrote:
> This series removes some no longer needed stuff from paravirt
> infrastructure and puts large quantities of paravirt ops under a new
> config option PARAVIRT_XXL which is selected by XEN_PV only.
>
> A pvops kernel without XEN_PV being configured is about
On Fri 24-08-18 15:44:03, Christian König wrote:
> Am 24.08.2018 um 15:40 schrieb Michal Hocko:
> > On Fri 24-08-18 15:28:33, Christian König wrote:
> > > Am 24.08.2018 um 15:24 schrieb Michal Hocko:
> > > > On Fri 24-08-18 15:10:08, Christian König wrote:
> > > > > Am 24.08.2018 um 15:01 schrieb M
On 08/08/18 17:13, Boris Ostrovsky wrote:
> x86 maintainers, this needs you ack too even though it has "xen" tag in
> the subject, thanks.
Ping?
Juergen
>
>
> On 08/08/2018 02:19 AM, Juergen Gross wrote:
>> All functions in arch/x86/xen/irq.c and arch/x86/xen/xen-asm*.S are
>> specific to PV
On Fri, 24 Aug 2018, Juergen Gross wrote:
> On 08/08/18 17:13, Boris Ostrovsky wrote:
> > x86 maintainers, this needs you ack too even though it has "xen" tag in
> > the subject, thanks.
>
> Ping?
I thought I sent one already, but here you go:
Acked-by: Thomas Gleixner
___
On Fri, Aug 24, 2018 at 11:54:04AM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Mon, 13 Aug 2018, Juergen Gross wrote:
> paravirt_patch_call() and paravirt_patch_jmp() are used in paravirt.c
> only. Convert them to static.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
___
Xen-devel mailing list
Xen-devel@list
On Mon, 13 Aug 2018, Juergen Gross wrote:
> The clobbers parameter from paravirt_patch_default() et al isn't used
> any longer. Remove it.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
___
Xen-devel mailing list
Xen-devel@lists.xenpr
On Mon, 13 Aug 2018, Juergen Gross wrote:
> There is no need any longer to store the clobbers in struct
> paravirt_patch_site. Remove clobbers from the struct and from the
> related macros.
>
> While at it fix some lines longer than 80 characters.
>
> Signed-off-by: Juergen Gross
Reviewed-by:
Hi
On Fri, Aug 24, 2018 at 9:37 AM Markus Armbruster wrote:
>
> Marc-André Lureau writes:
>
> > This is mostly for readability of the code. Let's make it clear which
> > callers can create an implicit monitor when the chardev is muxed.
> >
> > This will also enforce a safer behaviour, as we don't
The original version of the patch emulated the current instruction
(which, as a side-effect, emulated the page-walk as well), however we
need finer-grained control. We want to emulate the page-walk, but still
get an EPT violation event if the current instruction would trigger one.
This patch perfor
On Mon, Aug 13, 2018 at 09:37:37AM +0200, Juergen Gross wrote:
> Some of the paravirt ops defined in pv_irq_ops are for Xen PV guests
> only. Define them only if CONFIG_PARAVIRT_XXL is set.
> diff --git a/arch/x86/include/asm/paravirt_types.h
> b/arch/x86/include/asm/paravirt_types.h
> index e652e
On Mon, Aug 13, 2018 at 09:37:38AM +0200, Juergen Gross wrote:
> struct pv_mmu_ops {
> + /* TLB operations */
> + void (*flush_tlb_user)(void);
> + void (*flush_tlb_kernel)(void);
> + void (*flush_tlb_one_user)(unsigned long addr);
> + void (*flush_tlb_others)(const struct cpum
On 24/08/18 16:10, Peter Zijlstra wrote:
> On Mon, Aug 13, 2018 at 09:37:37AM +0200, Juergen Gross wrote:
>> Some of the paravirt ops defined in pv_irq_ops are for Xen PV guests
>> only. Define them only if CONFIG_PARAVIRT_XXL is set.
>> diff --git a/arch/x86/include/asm/paravirt_types.h
>> b/arch
On 24/08/18 16:12, Peter Zijlstra wrote:
> On Mon, Aug 13, 2018 at 09:37:38AM +0200, Juergen Gross wrote:
>> struct pv_mmu_ops {
>> +/* TLB operations */
>> +void (*flush_tlb_user)(void);
>> +void (*flush_tlb_kernel)(void);
>> +void (*flush_tlb_one_user)(unsigned long addr);
>> +
On 08/24/2018 07:26 AM, Juergen Gross wrote:
> On 24/08/18 13:12, Jiri Slaby wrote:
>> On 07/30/2018, 10:18 AM, Xiao Liang wrote:
>>> On 07/29/2018 11:30 PM, David Miller wrote:
From: Xiao Liang
Date: Fri, 27 Jul 2018 17:56:08 +0800
> @@ -1330,6 +1331,11 @@ static struct net_dev
On Fri, Aug 24, 2018 at 07:54:19PM +0900, Tetsuo Handa wrote:
> Two more worries for this patch.
[...]
>
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -177,16 +177,19 @@ static void hmm_release(struct mmu_notifier *mn,
> > struct mm_struct *mm)
> > up_write(&hmm->mirrors_sem);
> > }
> >
flight 126412 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898
test-amd64-i386-xl-
On Fri, Aug 24, 2018 at 03:52:55PM +0200, Juergen Gross wrote:
> Ping?
Looking good; although I messed it up a little bit by adding a new
paravirt function.
Thanks for doing this!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.
This run is configured for baseline tests only.
flight 75113 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75113/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75111
test
On 2018/08/24 22:32, Michal Hocko wrote:
> On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
>> I worry that (currently
>> out-of-tree) users of this API are involving work / recursion.
>
> I do not give a slightest about out-of-tree modules. They will have to
> accomodate to the new API. I have no pr
On Fri, Aug 24, 2018 at 02:33:41PM +0200, Michal Hocko wrote:
> On Fri 24-08-18 14:18:44, Christian König wrote:
> > Am 24.08.2018 um 14:03 schrieb Michal Hocko:
> > > On Fri 24-08-18 13:57:52, Christian König wrote:
> > > > Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > > > > On Fri 24-08-18 13:
On Fri, Aug 24, 2018 at 11:52:25PM +0900, Tetsuo Handa wrote:
> On 2018/08/24 22:32, Michal Hocko wrote:
> > On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
> >> I worry that (currently
> >> out-of-tree) users of this API are involving work / recursion.
> >
> > I do not give a slightest about out-of
Wei Liu writes ("Re: [Xen-devel] Backport request -
3a2b8525b883baa87fe89b3da58f5c09fa599b99 to staging-4.9"):
> On Fri, Aug 24, 2018 at 12:32:57PM +1000, Steven Haigh wrote:
> > Commit:
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=3a2b8525b883baa87fe89b3da58f5c09fa599b99
> >
> > I've
Wei Liu writes ("[PATCH] tools: building IPXE should be determined by
CONFIG_IPXE"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Paul Durrant writes ("[PATCH] xenforeignmemory: work around bug in older
privcmd"):
> Versions of linux privcmd prior to commit dc9eab6fd94d ("return -ENOTTY
> for unimplemented IOCTLs") will return -EINVAL rather than the conventional
> -ENOTTY for unimplemented codes. This breaks the error path
Building rombios with clang XXX fails with:
tcgbios.c:1519:34: error: taking address of packed member 'u' of class or
structure 'pushad_regs_t' may result in an unaligned pointer value
[-Werror,-Waddress-of-packed-member]
®s->u.r32.edx);
Previously it is disabled because the embedded ipxe can't be built
with clang. Now that ipxe is split out we can use --with-system-ipxe
to work around the issue.
Signed-off-by: Wei Liu
---
automation/scripts/build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/automation
On Fri, Aug 24, 2018 at 04:22:15PM +0100, Wei Liu wrote:
> Building rombios with clang XXX fails with:
>
> tcgbios.c:1519:34: error: taking address of packed member 'u' of class or
> structure 'pushad_regs_t' may result in an unaligned pointer value
> [-Werror,-Waddress-of-packed-member]
>
On Fri, Aug 24, 2018 at 04:22:47PM +0100, Wei Liu wrote:
> Previously it is disabled because the embedded ipxe can't be built
> with clang. Now that ipxe is split out we can use --with-system-ipxe
> to work around the issue.
>
> Signed-off-by: Wei Liu
> ---
> +# iPXE cannot be built with clan
On Fri, Aug 24, 2018 at 10:30:37AM -0500, Doug Goldstein wrote:
> On Fri, Aug 24, 2018 at 04:22:15PM +0100, Wei Liu wrote:
> > Building rombios with clang XXX fails with:
Oops, I have meant to replace XXX with the right version number.
Will fix that while committing.
> >
> > tcgbios.c:1519:34:
On Fri, Aug 24, 2018 at 04:32:15PM +0100, Wei Liu wrote:
> On Fri, Aug 24, 2018 at 10:30:37AM -0500, Doug Goldstein wrote:
> > On Fri, Aug 24, 2018 at 04:22:15PM +0100, Wei Liu wrote:
> > > Building rombios with clang XXX fails with:
>
> Oops, I have meant to replace XXX with the right version num
On Fri, Aug 24, 2018 at 10:32:24AM -0500, Doug Goldstein wrote:
> On Fri, Aug 24, 2018 at 04:22:47PM +0100, Wei Liu wrote:
> > Previously it is disabled because the embedded ipxe can't be built
> > with clang. Now that ipxe is split out we can use --with-system-ipxe
> > to work around the issue.
>
This run is configured for baseline tests only.
flight 75114 seabios real [real]
http://osstest.xensource.com/osstest/logs/75114/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 10 windows-installfail
On Wed, Aug 22, 2018 at 06:23:01PM +0200, Valentin Vidic wrote:
> On Wed, Aug 22, 2018 at 05:51:54PM +0200, Roger Pau Monné wrote:
> > Can you add some debug prints to check if xen_blkif_disconnect is
> > indeed returning EBUSY (or some error) and that's preventing the
> > device from closing corre
On Mon, Aug 20, 2018 at 07:04:09AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > This helps to take advantage of dead code elimination. Turn
> > hvm_enabled into proper bool while at it.
> >
> > Providing an empty hvm_funcs resolves a lot of undefined references to
> > it in th
On Sun, Aug 19, 2018 at 07:27:22PM +0300, Razvan Cojocaru wrote:
> On 8/17/18 6:12 PM, Wei Liu wrote:
> > Going through the code, nested EPT, EPT, and ALTP2M depend on HVM code. Put
> > these components under CONFIG_HVM. This further requires putting one
> > of the vm event under CONFIG_HVM.
> >
>
On Tue, Aug 21, 2018 at 10:37:24AM +0200, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:45PM +0100, Wei Liu wrote:
> > They reference hvm_inject_event which is HVM code (not compiled). They
> > aren't used by code outside HVM code anyway.
>
> Can you put all the functions inside of an #if
On Tue, Aug 21, 2018 at 05:41:49AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > Nested HVM is not enabled when !CONFIG_HVM.
>
> All callers of the function sit under hvm/, so once again I don't see
> why the function needs to remain available with an empty body.
Yes the whole
On Fri 24-08-18 23:52:25, Tetsuo Handa wrote:
> On 2018/08/24 22:32, Michal Hocko wrote:
> > On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
> >> I worry that (currently
> >> out-of-tree) users of this API are involving work / recursion.
> >
> > I do not give a slightest about out-of-tree modules. T
On Fri 24-08-18 11:12:40, Jerome Glisse wrote:
[...]
> I am fine with Michal patch, i already said so couple month ago first time
> this discussion did pop up, Michal you can add:
>
> Reviewed-by: Jérôme Glisse
So I guess the below is the patch you were talking about?
From f7ac75277d526dccd011f
On Fri, Aug 24, 2018 at 06:22:32PM +0200, Valentin Vidic wrote:
> Managed to reproduce this and xen_blkif_disconnect is always returning 0
> like you expected. So this is some other issue, and from what I can tell
> blkdev_put of the underlying drbd device gets called some time after
> xenbus_swit
flight 126440 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125183
test-amd64-amd64-xl
Hi all,
This patch series contains fixup and improvement for the SMCCC subsystem.
Patch #1 - #2 are candidates for backporting.
Cheers,
Julien Grall (3):
xen/arm: cpufeature: Add helper to check constant caps
xen/arm: smccc: Add wrapper to automatically select the calling
convention
x
Signed-off-by: Julien Grall
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 8
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 3cf5ecf0f3..941eec921b
From: Marc Zyngier
If someone has the silly idea to write something along those lines:
extern u64 foo(void);
void bar(struct arm_smccc_res *res)
{
arm_smccc_1_1_smc(0xbad, foo(), res);
}
they are in for a surprise, as this gets compiled as:
1 - 100 of 153 matches
Mail list logo
