When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%.
Modify external providers of
flight 128038 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128038/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 127928
Tests which
Hi Boris,
On 09/18/2018 03:08 AM, Boris Ostrovsky wrote:
> On 9/16/18 9:20 PM, Dongli Zhang wrote:
>> Hi Boris,
>>
>> On 09/17/2018 04:17 AM, Boris Ostrovsky wrote:
>>>
>>> On 9/14/18 3:34 AM, Dongli Zhang wrote:
>>>
+
+struct mtwatch_info {
+/*
+ * The mtwatch_domain
flight 128030 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128030/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a364928195e911c2650fcae6bd34cfd501df1f57
baseline version:
ovmf
flight 128029 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128029/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 127928
Tests which
This run is configured for baseline tests only.
flight 75280 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75280/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On Mon, 2018-09-17 at 09:32 +0200, David Hildenbrand wrote:
> Am 03.09.18 um 02:36 schrieb Rashmica:
> > Hi David,
> >
> >
> > On 21/08/18 20:44, David Hildenbrand wrote:
> >
> > > There seem to be some problems as result of 30467e0b3be ("mm,
> > > hotplug:
> > > fix concurrent memory hot-add
flight 128005 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128005/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 128002
flight 128025 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128025/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 127928
Tests which
Workaround for compiler rejection of SSE-using always_inlines defined before
SSE is disabled.
Compiling with _FORTIFY_SOURCE or higher levels of optimization enabled
will always_inline several library fns (memset, memcpy, ...)
(with gcc 8.2.0 and glibc 2.28).
In fuzz and x86_emulator test, the
On Mon, Sep 24, 2018 at 5:06 AM Jan Beulich wrote:
>
> >>> On 21.09.18 at 21:25, wrote:
> >
> > Adds necessary (previously missing) #include to x86-emulate.h
>
> Why "necessary (previously missing)"? I can't seem to be able to
> spot anything in that header that would depend on stdio.h.
When
Hi all,
This patch series improves the kconfig and Makefile of the platforms
under platforms/. Most patches have been removed compared to previous
versions of the series.
Cheers,
Stefano
The following changes since commit b28cd21c36288a01ae61ed4f557802abc8ee03e4:
x86/build: Use new .nops
Add a Kconfig option to select no specific platform support.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- need to add ifneq ($(CONFIG_NO_PLAT),y) around subdir-y += platforms
otherwise compilation fails when no platforms are selected:
make -f /local/repos/xen-upstream/xen/Rules.mk
Compile platform code that doesn't have its own specific kconfig option
only if ALL32_PLAT or ALL64_PLAT depending on the architecture. The
benefit is that choosing one of the platforms available as a menu
option allows the user not to build other unnecessary platform code.
Signed-off-by: Stefano
Hi,
On 09/21/2018 05:20 PM, Dario Faggioli wrote:
[Adding Julien as well.
Julien, this seems related to the RCU issue we fought on ARM when using
Credit2, although this is null, but it's being even more weird...]
On Fri, 2018-09-21 at 16:14 +0200, Milan Boberic wrote:
Hey,
yes, I can see
flight 128015 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128015/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 60eb6c6d2e01e8d44d29740b006df1fc7e74ab21
baseline version:
ovmf
flight 128019 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 127928
Tests which
flight 128002 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128002/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
Anyone?
On Sun, Sep 23, 2018 at 8:34 PM Mr Oxide wrote:
> Hi, I am wondering about the compatibility of the Quadro P4000 with xen.
> Especially the version of xen being used in Qubes os currently. I've tried
> googling this with no luck at all.
>
___
On Mon, Sep 24, 2018 at 05:18:29PM +0100, Wei Liu wrote:
> Sometimes it is handy to create a container and play as root with its
> setup manually.
>
> Signed-off-by: Wei Liu
> ---
> automation/scripts/containerize | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git
Signed-off-by: Wei Liu
---
After applying all my patches for CONFIG_HVM series, I got this from a
shim build:
$ nm xen-shim-syms | grep -i hvm
82d080260550 T hvm_domain_use_pirq
82d080369520 D hvm_max_cpuid_policy
82d08036b95c D hvm_max_msr_policy
82d08036b950 D hvm_max_vcpu_msrs
On 9/24/18 3:49 AM, Wei Liu wrote:
d54ecf31b2 placed the build dependency in a wrong file. This patch
adds the dependency to the right file. Add a runtime dependency in
libvirt.pm.
Thanks for fixing my fix :-).
Regards,
Jim
Signed-off-by: Wei Liu
---
Cc: Jim Fehlig
---
On 21/09/18 16:54, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
Thanks,
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 128013 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128013/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 127928
On Tue, 2018-09-18 at 06:58 -0600, Jan Beulich wrote:
> > > > On 13.09.18 at 17:02, wrote:
> >
> > --- a/xen/arch/x86/domain_page.c
> > +++ b/xen/arch/x86/domain_page.c
> > @@ -331,10 +331,9 @@ void *__map_domain_pages_global(const struct
> > page_info *pg, unsigned int nr)
> > {
> > mfn_t
From: "Jan Beulich"
Date: Mon, 24 Sep 2018 01:43:50 -0600
On 11.09.18 at 12:16, wrote:
>> On Tue, Sep 11, 2018 at 02:12:07AM -0600, Jan Beulich wrote:
>>> >>> On 28.08.18 at 16:54, wrote:
>>> > First and foremost the fix for XSA-270. On top of that further changes
>>> > which looked
On Mon, Sep 24, 2018 at 04:58:23PM +0100, George Dunlap wrote:
> On 09/21/2018 04:54 PM, Wei Liu wrote:
> > Going through the code, HAP, EPT, PoD 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 Mon, 2018-09-17 at 15:41 +0100, Andrew Cooper wrote:
> On 13/09/18 16:02, Petre Pircalabu wrote:
> > In high throughput introspection scenarios where lots of monitor
> > vm_events are generated, the ring buffer can fill up before the
> > monitor
> > application gets a chance to handle all the
On 09/24/2018 04:45 PM, Razvan Cojocaru wrote:
> On 9/24/18 6:25 PM, George Dunlap wrote:
>> On 09/23/2018 06:04 PM, Razvan Cojocaru wrote:
>>> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
>>> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
>>> a system with virt
Sometimes it is handy to create a container and play as root with its
setup manually.
Signed-off-by: Wei Liu
---
automation/scripts/containerize | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index
On 09/21/2018 04:54 PM, Wei Liu wrote:
> Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
> Put these components under CONFIG_HVM. This further requires putting
> one of the vm event under CONFIG_HVM.
>
> Altp2m requires a bit more attention because its code is embedded in
>
On 9/24/18 6:25 PM, George Dunlap wrote:
> On 09/23/2018 06:04 PM, Razvan Cojocaru wrote:
>> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
>> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
>> a system with virt exceptions, which would trigger the ASSERT()),
>>
On 09/21/2018 04:54 PM, Wei Liu wrote:
> Populate-on-demand is HVM only.
>
> Provide a bunch of stubs for common p2m code and guard one invocation
> of guest_physmap_mark_populate_on_demand with is_hvm_domain.
>
> Put relevant fields in p2m_domain and code which touches those fields
> under
On 09/21/2018 04:54 PM, Wei Liu wrote:
> These functions are only useful for nested hvm, which isn't enabled
> when CONFIG_HVM is false.
>
> Enclose relevant code and fields in CONFIG_HVM.
>
> Signed-off-by: Wei Liu
> Acked-by: Jan Beulich
Reviewed-by: George Dunlap
On 09/23/2018 06:04 PM, Razvan Cojocaru wrote:
> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
> a system with virt exceptions, which would trigger the ASSERT()),
> and move the VMX-isms
On Fri, Sep 21, 2018 at 9:55 AM Wei Liu wrote:
>
> Populate-on-demand is HVM only.
>
> Provide a bunch of stubs for common p2m code and guard one invocation
> of guest_physmap_mark_populate_on_demand with is_hvm_domain.
>
> Put relevant fields in p2m_domain and code which touches those fields
>
On Sun, Sep 23, 2018 at 11:05 AM Razvan Cojocaru
wrote:
>
> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
> a system with virt exceptions, which would trigger the ASSERT()),
> and move the VMX-isms
On 09/24/2018 11:57 AM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v2 2/6] test/depriv: Add a tool to check
> process-level depriv"):
>> Add a tool to check whether the various process-level deprivileging
>> operations have actually taken place on the process.
> ...
>> +# Example input:
On 09/24/2018 11:48 AM, Ian Jackson wrote:
>> +if (rc < 0) {
>> +char *msg = GCSPRINTF("libxl: Setting rlimit %d to %lld failed
>> with error %d\n",
>> + rlimits[i].resource,
>
> If you cared very much about the error handling, you could
On 9/23/18 1:38 PM, Nicolai Stange wrote:
> arch/x86/include/asm/xen/events.h references xen_hvm_domain() from the
> inlined xen_support_evtchn_rebind().
>
> xen_hvm_domain() gets #defined in include/xen/xen.h and
> arch/x86/include/asm/xen/events.h doesn't include that.
>
> On current Linus'
On Mon, Sep 24, 2018 at 08:08:52AM -0600, Jan Beulich wrote:
> >>> On 24.09.18 at 15:46, wrote:
> > @@ -987,6 +974,20 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> > highmem_start &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
> > #endif
> >
> > +/*
> > + * Iterate
On 09/24/2018 12:21 PM, Ian Jackson wrote:
> Apropos of our conversation on IRC, I looked at the checker script in
> detail.
>
>> #!/bin/bash
>>
>> domain="$1"
>
> Just noticed this, but: OMG no `set -e'.
> You probably want `set -o pipefail' too.
`set -e` never made any sense to me -- that's
On 9/20/18 10:39 AM, Jens Axboe wrote:
> On 9/20/18 12:29 AM, Christoph Hellwig wrote:
>> On Sat, Sep 15, 2018 at 08:47:13AM -0600, Jens Axboe wrote:
> this series moves various helpers related to merging based on physical
> addresses from the public headers into block/, moves the Xen
On 09/24/2018 11:40 AM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v2 4/6] tools/dm_restrict: Unshare mount and
> IPC namespaces on Linux"):
>> QEMU running under Xen doesn't need mount or IPC functionality.
>> Create and enter separate namespaces for each of these before
>> executing
>>> On 24.09.18 at 15:00, wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -58,6 +58,7 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
> CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
> CFLAGS-$(CONFIG_DEBUG_INFO) += -g
> CFLAGS += '-D__OBJECT_FILE__="$@"'
>
>>> On 24.09.18 at 15:00, wrote:
> For at least "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609", the
> typecast of buf triggers a Variable Length Array warning.
>
> Alter the asm expression to avoid the typecast, which necessitates the
> introduction of a memory clobber as the compiler can
>>> On 21.09.18 at 17:54, wrote:
> Populate-on-demand is HVM only.
>
> Provide a bunch of stubs for common p2m code and guard one invocation
> of guest_physmap_mark_populate_on_demand with is_hvm_domain.
>
> Put relevant fields in p2m_domain and code which touches those fields
> under
>>> On 24.09.18 at 15:46, wrote:
> @@ -987,6 +974,20 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> highmem_start &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
> #endif
>
> +/*
> + * Iterate backwards over all superpage-aligned RAM regions.
> + *
> + * We require
>>> On 24.09.18 at 15:39, wrote:
> On Mon, Sep 24, 2018 at 05:19:12AM -0600, Jan Beulich wrote:
>> >>> On 24.09.18 at 12:38, wrote:
>> > --- a/xen/arch/x86/setup.c
>> > +++ b/xen/arch/x86/setup.c
>> > @@ -944,12 +944,13 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> >
>> > /*
BOOTSTRAP_DIRECTMAP_END is gone. The comment in question should refer
to BOOSTRAP_MAP_BASE and BOOTSTRAP_MAP_LIMIT instead.
Move the entire comment block to where it belongs -- immediately
before the loop which does the things said in the comment.
Remove two trailing spaces while at it.
On 09/24/2018 02:04 PM, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU
> sandboxing"):
>> From qemu-depriv.md:
>>
>> `elevateprivileges` is currently required to allow `-runas` to work.
>> Removing this requirement would mean making sure that
flight 128006 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128006/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd e3c2d3a906b1063421584e83d3d3968849b04690
baseline version:
freebsd
On 09/12/2018 10:03 AM, Andre Przywara wrote:
Hi,
On 11/09/2018 17:48, Amit Singh Tomar wrote:
This patch adds image size and flags to XEN image header. It uses
those fields according to the updated Linux kernel image definition.
With this patch bootloader can now place XEN image anywhere
On Mon, Sep 24, 2018 at 05:19:12AM -0600, Jan Beulich wrote:
> >>> On 24.09.18 at 12:38, wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -944,12 +944,13 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >
> > /*
> > * Iterate backwards over all
On 09/24/2018 02:00 PM, Andrew Cooper wrote:
Variable length arrays result in excess stack utilisation, with a risk
of stack overflow if the length is too large. It also results in fairly
poor asm generation, because of requiring a divide as part of the space
calcuation.
Xen no longer has
Hi Roger,
On 09/12/2018 11:29 AM, Roger Pau Monné wrote:
On Wed, Sep 12, 2018 at 10:48:42AM +0100, Julien Grall wrote:
Hi,
On 09/12/2018 10:16 AM, Roger Pau Monné wrote:
On Wed, Sep 12, 2018 at 11:13:50AM +0200, Roger Pau Monné wrote:
Adding Julien how did the work to support XEN_PAGE_SIZE
Hi Andrew,
On 09/24/2018 02:00 PM, Andrew Cooper wrote:
The reg[] array can have a maximum size of 8 in practice, so use the worst
case calculation rather than making it variable length.
Signed-off-by: Andrew Cooper
Reviewed-by: Julien Grall
Cheers,
---
CC: Stefano Stabellini
CC:
On 24/09/18 14:20, Wei Liu wrote:
> On Mon, Sep 24, 2018 at 02:00:01PM +0100, Andrew Cooper wrote:
>> For at least "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609", the
>> typecast of buf triggers a Variable Length Array warning.
>>
>> Alter the asm expression to avoid the typecast, which
On Mon, Sep 24, 2018 at 02:00:03PM +0100, Andrew Cooper wrote:
> Variable length arrays result in excess stack utilisation, with a risk
> of stack overflow if the length is too large. It also results in fairly
> poor asm generation, because of requiring a divide as part of the space
> calcuation.
On Mon, Sep 24, 2018 at 02:00:01PM +0100, Andrew Cooper wrote:
> For at least "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609", the
> typecast of buf triggers a Variable Length Array warning.
>
> Alter the asm expression to avoid the typecast, which necessitates the
> introduction of a
On Mon, Sep 24, 2018 at 02:00:00PM +0100, Andrew Cooper wrote:
> Callers of p2m_pod_zero_check() pass a count of up to POD_SWEEP_STRIDE.
> Move the definition of POD_SWEEP_STRIDE and give the arrays a fixed
> bound.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
On Mon, Sep 24, 2018 at 01:59:59PM +0100, Andrew Cooper wrote:
> There is no need to duplicate the contents of the skip block.
>
> While cleaning up this function, change 4 ints to be unsigned.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Hi,
On 09/13/2018 04:01 PM, Petre Pircalabu wrote:
Create a single mapping for multiple domain pages.
Signed-off-by: Petre Pircalabu
---
tools/libxc/xc_vm_event.c | 2 +-
xen/arch/x86/domain_page.c| 22 ++
xen/include/xen/domain_page.h | 9 +
3 files
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 24 September 2018 14:00
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ; Paul Durrant
>
> Subject: [PATCH 3/5] x86/hvm: Adjust hvmemul_rep_stos() to compile with -
> Wvla
>
> For at
On 09/24/2018 11:23 AM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v2 1/6] docs/qemu-deprivilege: Revise and
> update with status and future plans"):
>> +## Xen library / file-descriptor restrictions
>> +
>> +'''Description''': Close and restrict Xen-related file descriptors.
>>
George Dunlap writes ("Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU
sandboxing"):
> From qemu-depriv.md:
>
> `elevateprivileges` is currently required to allow `-runas` to work.
> Removing this requirement would mean making sure that the uid change
> happened before the seccomp2 call,
Callers of p2m_pod_zero_check() pass a count of up to POD_SWEEP_STRIDE.
Move the definition of POD_SWEEP_STRIDE and give the arrays a fixed
bound.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: George Dunlap
---
xen/arch/x86/mm/p2m-pod.c | 12 +++-
1 file changed, 7
Variable length arrays, while convenient in some cases, are problematic with
small stacks, and can turn logical bugs into stack overflows. Furthermore,
the code generation behind them is very poor.
Xen has two uses of VLAs which can be fixed easily, and one case where the VLA
logic triggers on a
Variable length arrays result in excess stack utilisation, with a risk
of stack overflow if the length is too large. It also results in fairly
poor asm generation, because of requiring a divide as part of the space
calcuation.
Xen no longer has any variable length arrays, so take the opportunity
There is no need to duplicate the contents of the skip block.
While cleaning up this function, change 4 ints to be unsigned.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: George Dunlap
---
xen/arch/x86/mm/p2m-pod.c | 14 +++---
1 file changed, 3 insertions(+), 11
The reg[] array can have a maximum size of 8 in practice, so use the worst
case calculation rather than making it variable length.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
Only compile tested.
---
xen/arch/arm/domain_build.c | 4 +++-
1 file changed, 3
For at least "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609", the
typecast of buf triggers a Variable Length Array warning.
Alter the asm expression to avoid the typecast, which necessitates the
introduction of a memory clobber as the compiler can no longer identify
the total quantity of
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 6a92b11169a65b3f8cc512c75a252cbd0d096ba0 upstream.
For unprivileged Xen PV guests this is normal memory and ioremap will
not be able to properly map it.
While at it,
> -Original Message-
> From: Andrew Cooper
> Sent: 24 September 2018 13:25
> To: Paul Durrant ; 'Jan Beulich'
>
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Roger Pau Monne ;
> Wei Liu ; Xen-devel
> Subject: Re: [PATCH 1/2] x86/SVM-IOMMU: Don't opencode memcpy() in
>
>>> On 24.09.18 at 14:18, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 24 September 2018 13:16
>>
>> All writes to the ring occur strictly before the update of the tail
>> pointer
>
> ...unless the compiler decides to re-order. There's no barrier.
But there is (an implied)
On 24/09/18 13:18, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 24 September 2018 13:16
>> To: Paul Durrant
>> Cc: Brian Woods ; Suravee Suthikulpanit
>> ; Andrew Cooper
>> ; Roger Pau Monne ; Wei
>> Liu ; Xen-devel
>> Subject: RE:
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 6a92b11169a65b3f8cc512c75a252cbd0d096ba0 upstream.
For unprivileged Xen PV guests this is normal memory and ioremap will
not be able to properly map it.
While at it,
On 24/09/18 13:09, Paul Durrant wrote:
>>
@@ -35,12 +34,9 @@ static int queue_iommu_command(struct amd_iommu
>> *iommu,
u32 cmd[])
IOMMU_CMD_BUFFER_HEAD_OFFSET));
if ( head != tail )
{
-cmd_buffer = (u32
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 September 2018 13:16
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; Xen-devel
> Subject: RE: [PATCH 1/2] x86/SVM-IOMMU: Don't opencode memcpy()
>>> On 24.09.18 at 12:55, wrote:
> It is MASK_EXTR() in disguise, but less flexible.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>>> On 24.09.18 at 14:09, wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 24 September 2018 13:06
>> To: Paul Durrant ; Xen-devel > de...@lists.xen.org>
>> Cc: Jan Beulich ; Wei Liu ; Roger
>> Pau Monne ; Suravee Suthikulpanit
>> ; Brian Woods
>> Subject: Re: [PATCH 1/2]
>>> On 24.09.18 at 12:55, wrote:
> In practice, this allows the compiler to replace the loop with a pair of
> movs.
I'm surprised the compiler doesn't recognize this opportunity anyway.
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> -Original Message-
> From: Andrew Cooper
> Sent: 24 September 2018 13:06
> To: Paul Durrant ; Xen-devel de...@lists.xen.org>
> Cc: Jan Beulich ; Wei Liu ; Roger
> Pau Monne ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: Re: [PATCH 1/2] x86/SVM-IOMMU: Don't opencode memcpy() in
>
>>> On 24.09.18 at 13:59, wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 24 September 2018 11:55
>>
>> @@ -35,12 +34,9 @@ static int queue_iommu_command(struct amd_iommu *iommu,
>> u32 cmd[])
>>IOMMU_CMD_BUFFER_HEAD_OFFSET));
>>
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 24 September 2018 11:56
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ; Roger Pau Monne
> ; Paul Durrant ; Suravee
> Suthikulpanit ; Brian Woods
>
> Subject: [PATCH 2/2] x86/SVM-IOMMU:
>>> On 21.09.18 at 21:25, wrote:
> Compiling with _FORTIFY_SOURCE or higher levels of optimization enabled
> will always_inline several library fns (memset, memcpy, ...)
> (with gcc 8.2.0 and glibc 2.28).
>
> In fuzz and x86_emulator test, the compiler is instructed not
> to generate SSE
On 24/09/18 12:59, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 24 September 2018 11:55
>> To: Xen-devel
>> Cc: Andrew Cooper ; Jan Beulich
>> ; Wei Liu ; Roger Pau Monne
>> ; Paul Durrant ; Suravee
>> Suthikulpanit ; Brian
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 24 September 2018 11:55
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ; Roger Pau Monne
> ; Paul Durrant ; Suravee
> Suthikulpanit ; Brian Woods
>
> Subject: [PATCH 1/2] x86/SVM-IOMMU:
Apropos of our conversation on IRC, I looked at the checker script in
detail.
> #!/bin/bash
>
> domain="$1"
Just noticed this, but: OMG no `set -e'.
You probably want `set -o pipefail' too.
> dmpid=$(xenstore-read /local/domain/$domid/image/device-model-pid 2>/dev/null)
> if [[ -z "$dmpid" ]]
>>> On 24.09.18 at 12:38, wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -944,12 +944,13 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>
> /*
> * Iterate backwards over all superpage-aligned RAM regions.
> - *
> - * We require superpage
On 09/24/2018 11:49 AM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU
> sandboxing"):
>> QEMU has a `sandbox` feature, wherein it will use seccomp2 to restrict
>> what system calls it is able to make.
> ...
>> +flexarray_append(dm_args,
>>
On Fri, Sep 21, 2018 at 06:04:24PM +0100, George Dunlap wrote:
> diff --git a/tools/tests/depriv/depriv-process-checker.sh
> b/tools/tests/depriv/depriv-process-checker.sh
> --- /dev/null
> +++ b/tools/tests/depriv/depriv-process-checker.sh
[...]
> +# Example input:
> +# Uid: 11931193
flight 127997 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127997/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 127966
test-armhf-armhf-libvirt 14
George Dunlap writes ("[PATCH v2 2/6] test/depriv: Add a tool to check
process-level depriv"):
> Add a tool to check whether the various process-level deprivileging
> operations have actually taken place on the process.
...
> +# Example input:
> +# Uid: 1193119311931193
>
It is MASK_EXTR() in disguise, but less flexible.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Paul Durrant
CC: Suravee Suthikulpanit
CC: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 2 +-
In practice, this allows the compiler to replace the loop with a pair of movs.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Paul Durrant
CC: Suravee Suthikulpanit
CC: Brian Woods
---
xen/drivers/passthrough/amd/iommu_cmd.c
George Dunlap writes ("[PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU
sandboxing"):
> QEMU has a `sandbox` feature, wherein it will use seccomp2 to restrict
> what system calls it is able to make.
...
> +flexarray_append(dm_args,
>
George Dunlap writes ("[PATCH v2 5/6] tools/dm_depriv: Add first cut RLIMITs"):
> Limit the ability of a potentially compromised QEMU to consume system
> resources. Key limits:
...
> +static struct {
> +int resource;
> +rlim_t limit;
> +} rlimits[] = {
> +{
> +.resource =
George Dunlap writes ("[PATCH v2 4/6] tools/dm_restrict: Unshare mount and IPC
namespaces on Linux"):
> QEMU running under Xen doesn't need mount or IPC functionality.
> Create and enter separate namespaces for each of these before
> executing QEMU, so that in the event that other restrictions
BOOTSTRAP_DIRECTMAP_END is gone. The comment in question should refer
to BOOSTRAP_MAP_BASE and BOOTSTRAP_MAP_LIMIT instead.
Remove two trailing spaces while fixing the comment.
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
1 - 100 of 116 matches
Mail list logo