Hello Roger,
Sorry if I'm disturbing your vacation. If you are already came back to work,
may I ask your opinion about this patch?
On Wed, 18 Dec 2019 19:37:16 +0100 SeongJae Park wrote:
> From: SeongJae Park
>
> Each `blkif` has a free pages pool for the grant mapping. The size of
> the po
flight 145497 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
145025
Tests whic
flight 145500 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145500/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
The __uaccess_ttbr0_disable and __uaccess_ttbr0_enable,
are the last two macros defined in asm-uaccess.h.
For now move them to entry.S where they are used. Eventually,
these macros should be replaced with C wrappers to reduce the
maintenance burden.
Also, once these macros are unified with the C
The assmbly functions __asm_flush_cache_user_range and
__asm_invalidate_icache_range have alternatives:
alternative_if ARM64_HAS_CACHE_DIC
...
alternative_if ARM64_HAS_CACHE_IDC
...
But, the implementation of those alternatives is trivial and therefore
can be done in the C inline wrappers.
Sign
__asm_flush_icache_range is an alias to __asm_flush_cache_user_range,
but now that these functions are called from C wrappers the fall
through can instead be done at a higher level.
Remove the __asm_flush_icache_range alias in assembly, and instead call
__flush_cache_user_range() from __flush_icac
The arm and arm64 versions of hypercall.h are missing the include
guards. This is needed because C inlines for privcmd_call are going to
be added to the files.
Signed-off-by: Pavel Tatashin
Reviewed-by: Julien Grall
---
arch/arm/include/asm/xen/hypercall.h | 4
arch/arm64/include/asm/xen
We currently duplicate the logic to enable/disable uaccess via TTBR0,
with C functions and assembly macros. This is a maintenenace burden
and is liable to lead to subtle bugs, so let's get rid of the assembly
macros, and always use the C functions. This requires refactoring
some assembly functions
Changelog:
v5:
- Fixed build issue reported by kbuild
- Removed a comment fix from the first patch
- Added reviewed-by's from Julien Grall
- Now, these patches apply against mainline
v4:
- Split the first patch into two as Julien Grall
- Also as Mark
privcmd_call requires to enable access to userspace for the
duration of the hypercall.
Currently, this is done via assembly macros. Change it to C
inlines instead.
Signed-off-by: Pavel Tatashin
Acked-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
arch/arm/include/asm/xen/hypercall.h |
flight 145486 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145486/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
Linux stubdom patches currently require qemu in dom0 for consoles [1], due to
the upstream toolstack need for save/restore. Until a long-term solution is
available (multiple console support in xenconsoled), would tools maintainers
consider a patch that made save/restore build-time configurable
On Thu, Jan 02, 2020 at 06:04:33PM +, Ian Jackson wrote:
> This affects only x86 and only the branches that aren't linux-*, since
> obviously the latter use whatever version they are using.
>
> I compared the most recent linux-4.19 results with the most recent
> linux-4.14 ones, and there was
On Thu, Jan 02, 2020 at 05:20:12PM +, Andrew Cooper wrote:
> On 02/01/2020 16:55, Wei Liu wrote:
> > On Thu, Jan 02, 2020 at 02:59:53PM +, Andrew Cooper wrote:
> >> The jmp after setting %cr0 is redundant with the following ljmp.
> >>
> >> The CPUID to protect the jump to higher mappings wa
Ian Jackson writes ("[PATCH] tools/xl/xl_cmdtable.c: Fix a simple typo."):
> From: Chad Dougherty
>
> Signed-off-by: Chad Dougherty
> ---
> tools/xl/xl_cmdtable.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
> index 5b
From: Chad Dougherty
Signed-off-by: Chad Dougherty
---
tools/xl/xl_cmdtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 5baa6023aa..3b302b2f20 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -502
On Thu, Jan 02, 2020 at 06:04:33PM +, Ian Jackson wrote:
> This affects only x86 and only the branches that aren't linux-*, since
> obviously the latter use whatever version they are using.
>
> I compared the most recent linux-4.19 results with the most recent
> linux-4.14 ones, and there was
This affects only x86 and only the branches that aren't linux-*, since
obviously the latter use whatever version they are using.
I compared the most recent linux-4.19 results with the most recent
linux-4.14 ones, and there was only one new failure (in 143841):
test-amd64-i386-qemuu-rhel6hvm-inte
flight 145492 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145492/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 145481 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145481/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
145025
Tests whic
On 23/12/2019 18:23, Julien Grall wrote:
> Hi,
>
> On 17/12/2019 21:15, Andrew Cooper wrote:
>> xc_dom_p2m() and dom->p2m_host[] implement a linear transform for
>> translated
>> domains, but waste a substantial chunk of RAM doing so.
>>
>> ARM literally never reads dom->p2m_host[] (because of the
On 30/12/2019 13:45, Julien Grall wrote:
> Hi,
>
> On 30/12/2019 13:38, Andrew Cooper wrote:
>> On 30/12/2019 13:15, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 27/12/2019 13:45, Andrew Cooper wrote:
The call to xc_domain_disable_migrate() is made only from x86,
while its
handling
On 24/12/2019 13:04, Paul Durrant wrote:
> The value of 'rover' is the value at which Xen will start searching for an
> unused domid if none is specified. Currently it is only updated when a
> domid is automatically chosen, rather than specified by the caller, which
> makes it very hard to describe
Paul Durrant writes ("[PATCH 6/6] xl: allow specified domain id to be used for
create, restore and migrate"):
> This patch adds the option to use a specified domain id to be used for
> the create, restore and migrate lifecycle operations and documentation
> thereof.
I approve of the idea that the
Paul Durrant writes ("[PATCH 5/6] libxl: allow creation of domains with
specified or random domid"):
> This patch modifies do_domain_create() to use the value of domid that is
> passed in. A new 'special value' - RANDOM_DOMID - is added into the API
> and this, INVALID_DOMID or any valid domid is
Paul Durrant writes ("[PATCH 4/6] domctl: set XEN_DOMCTL_createdomain 'rover'
if valid domid is specified"):
> The value of 'rover' is the value at which Xen will start searching for an
> unused domid if none is specified. Currently it is only updated when a
> domid is automatically chosen, rather
Paul Durrant writes ("[PATCH 2/6] libxl_create: make 'soft reset' explicit"):
> The 'soft reset' code path in libxl__domain_make() is currently taken if a
> valid domid is passed into the function. A subsequent patch will enable
> higher levels of the toolstack to determine the domid of newly creat
Paul Durrant writes ("[PATCH 3/6] domctl: return EEXIST from
XEN_DOMCTL_createdomain..."):
> ...if a specified domid is already in use.
>
> XEN_DOMCTL_createdomain allows a domid to be specified by its caller and
> will correctly fail if that domid is already in use. However the errno
> returned
On 02/01/2020 16:55, Wei Liu wrote:
> On Thu, Jan 02, 2020 at 02:59:53PM +, Andrew Cooper wrote:
>> The jmp after setting %cr0 is redundant with the following ljmp.
>>
>> The CPUID to protect the jump to higher mappings was inserted due to an
>> abundance of caution/paranoia before Spectre was
Paul Durrant writes ("[PATCH 1/6] libxl: add definition of INVALID_DOMID to the
API"):
> Currently both xl and libxl have internal definitions of INVALID_DOMID
> which happen to be identical. However, for the purposes of describing the
> behaviour of libxl_domain_create_new/restore() it is useful
On Thu, Jan 02, 2020 at 02:59:53PM +, Andrew Cooper wrote:
> The jmp after setting %cr0 is redundant with the following ljmp.
>
> The CPUID to protect the jump to higher mappings was inserted due to an
> abundance of caution/paranoia before Spectre was public. There is not a
> matching protec
On Thu, Jan 02, 2020 at 01:56:24PM +, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Preferably with one additional adjustment below.
>
> static void __init efi_arch_cfg_file_early(EFI_FILE_HANDLE dir_handle, char
> *section)
> diff
On Thu, 2 Jan 2020 at 16:21, Andrew Cooper wrote:
>
> This ought to have disappeared in c/s 60685089cb0
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
This ought to have disappeared in c/s 60685089cb0
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/boot/x86_64.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 64a04a65a5..ec72
On 02/01/2020 15:16, Ian Jackson wrote:
> This is a conventional filename for this
Really? Citation definitely needed, because neither Google nor Github
can find a single example matching this.
Linux has its sole copy in Documentation/process/submitting-patches.rst
so ours living in CONTRIBUTING
This is a conventional filename for this and makes it more
discoverable. The text is small enough that the copy in
CONTRIBUTING can stay a copy, I think.
Signed-off-by: Ian Jackson
---
CONTRIBUTING | 6 +-
DEVELOPER-CERTIFICATE | 38 ++
2 files
Various block drivers implement the CDROMMULTISESSION,
CDROM_GET_CAPABILITY, and CDROMEJECT ioctl commands, relying on the
block layer to handle compat_ioctl mode for them.
Move this into the drivers directly as a preparation for simplifying
the block layer later.
When only integer arguments or n
The jmp after setting %cr0 is redundant with the following ljmp.
The CPUID to protect the jump to higher mappings was inserted due to an
abundance of caution/paranoia before Spectre was public. There is not a
matching protection in the S3 resume path, and there is nothing
interesting in memory at
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
---
xen/arch/arm/efi/efi-boot.h | 2 +-
xen/arch/x86/efi/efi-boot.h | 2 +-
xen/common/efi/boot.c | 1 -
3 files change
flight 145472 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
flight 145480 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145480/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b948a496150f4ae4f656c0f0ab672608723c80e6
baseline version:
ovmf a5abd9cc2cebe7fac001f
41 matches
Mail list logo
