On 19.01.2021 19:09, Andrew Cooper wrote:
> On 19/01/2021 16:48, Jan Beulich wrote:
>> On 19.01.2021 14:02, Andrew Cooper wrote:
>>> This code has been copied in 3 places, but it is problematic.
>>>
>>> All cases will hit a BUG() later in domain teardown, when a the missing
>>> type/count reference
On 20.01.2021 00:10, Michael Young wrote:
> I have been trying the "[PATCH v2 1/5] libxenguest: support zstd
> compressed kernel" patch, and (assuming I haven't broken anything trying
> to migrate it to 4.14) it fails with
>
> onfigure: error: Package requirements (libzstd) were not met:
>
> Pa
On 19.01.2021 20:36, Claudemir Todo Bom wrote:
> I do not have serial output on this setup, so I recorded a video with
> boot_delay=50 in order to be able to get all the kernel messages:
> https://youtu.be/y95h6vqoF7Y
This doesn't show any badness afaics.
> This is running 4.14 from debian bullse
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> The IOREQ is a common feature now and this helper will be used
> on Arm as is. Move it to xen/ioreq.h and remove "hvm" prefix.
>
> Although PIO handling on Arm is not introduced with the current series
> (it will be implemented when
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> The IOREQ is a common feature now and these helpers will be used
> on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes
> with "ioreq".
>
> Signed-off-by: Oleksandr Tyshchenko
> Reviewed-by: Paul Durrant
> CC: Julien
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> The IOREQ is a common feature now and these structs will be used
> on Arm as is. Move them to xen/ioreq.h and remove "hvm" prefixes.
>
> Signed-off-by: Oleksandr Tyshchenko
> Acked-by: Jan Beulich
> CC: Julien Grall
> [On Arm onl
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> The IOREQ is a common feature now and this struct will be used
> on Arm as is. Move it to common struct domain. This also
> significantly reduces the layering violation in the common code
> (*arch.hvm* usage).
>
> We don't move iore
On 19.01.2021 19:43, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-dom0pvh-xl-intel
> 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/li
On 19.01.2021 15:55, Andrew Cooper wrote:
> On 19/01/2021 14:38, Roger Pau Monné wrote:
>> On Fri, Jan 15, 2021 at 11:10:44PM +, Andrew Cooper wrote:
>>> So all the moving parts are in one function.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Andrew Cooper
>>> ---
>>> CC: Jan Beulich
On 16.01.2021 00:10, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -834,6 +834,29 @@ void load_system_tables(void)
> BUG_ON(system_state != SYS_STATE_early_boot && (stack_bottom & 0xf));
> }
>
> +static void skinit_enable_intr(void)
> +{
> +
Hello,
by way of monitoring the stable Linux kernel logs I've become
aware of Linux commit dca5244d2f5b raising the minimum version
to 5.1. For Arm we currently document 4.8 - should this be
adjusted (and perhaps split for Arm32 and Arm64)?
Jan
Hi Alex,
On 20/01/2021 08:48, Alex Bennée wrote:
Oleksandr Tyshchenko writes:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this helper will be used
on Arm as is. Move it to xen/ioreq.h and remove "hvm" prefix.
Although PIO handling on Arm is not introduced with the cur
On 20/01/2021 09:25, Jan Beulich wrote:
Hello,
Hi Jan,
by way of monitoring the stable Linux kernel logs I've become
aware of Linux commit dca5244d2f5b raising the minimum version
to 5.1. For Arm we currently document 4.8 - should this be
adjusted (and perhaps split for Arm32 and Arm64)?
flight 158538 xen-unstable-coverity real [real]
flight 158539 xen-unstable-coverity real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158538/
http://logs.test-lab.xenproject.org/osstest/logs/158539/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blo
On 2021-01-19, Jan Beulich wrote:
> On 15.01.2021 15:44, Roger Pau Monné wrote:
> > On Fri, Jan 15, 2021 at 03:30:50PM +0100, Hubert Jasudowicz wrote:
> >> This patch is a result of a downstream bug report[1]. Xen fails to
> >> create a HVM domain while running under VMware Fusion 12.1.0 on
> >> a
On Mon, Jan 18, 2021 at 03:04:26PM +0100, Roger Pau Monne wrote:
> commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream
>
> Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
> addr = 0 in order to fetch the size of a specific resource.
>
> Add a shortcut to the default map r
Supported values are
0b GIC CPU interface system registers not implemented.
0b0001 System register interface to versions 3.0 and 4.0 of the GIC
CPU interface is supported.
0b0011 System register interface to version 4.1 of the GIC CPU
interface is supported.
4.1 is still backw
The ARMv8.3 Pointer Authentication extension is not supported by Xen
at the moment, so do not expose that via ID register.
Signed-off-by: Vladimir Murzin
Reviewed-by: Bertrand Marquis
---
xen/arch/arm/cpufeature.c| 6 +
xen/include/asm-arm/cpufeature.h | 38
flight 158535 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 20/01/2021 09:25, Jan Beulich wrote:
> Hello,
>
> by way of monitoring the stable Linux kernel logs I've become
> aware of Linux commit dca5244d2f5b raising the minimum version
> to 5.1. For Arm we currently document 4.8 - should this be
> adjusted (and perhaps split for Arm32 and Arm64)?
I poi
flight 158532 xen-unstable real [real]
flight 158540 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158532/
http://logs.test-lab.xenproject.org/osstest/logs/158540/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm6
Hi Vladimir,
> On 20 Jan 2021, at 11:26, Vladimir Murzin wrote:
>
> Supported values are
>
> 0b GIC CPU interface system registers not implemented.
>
> 0b0001 System register interface to versions 3.0 and 4.0 of the GIC
> CPU interface is supported.
>
> 0b0011 System register interf
From: Peter Zijlstra
Some static call declarations are going to be needed on low level header
files. Move the necessary material to the dedicated static call types
header to avoid inclusion dependency hell.
[jgr...@suse.com: updated tools/include/linux/static_call_types.h, too]
Signed-off-by: P
SWAPGS is used only for interrupts coming from user mode or for
returning to user mode. So there is no reason to use the PARAVIRT
framework, as it can easily be replaced by an ALTERNATIVE depending
on X86_FEATURE_XENPV.
There are several instances using the PV-aware SWAPGS macro in paths
which are
Xen PV guests don't use IST. For double fault interrupts switch to
the same model as NMI.
Correct a typo in a comment while copying it.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Thomas Gleixner
---
V2:
- fix typo (Andy Lutomirski)
---
arch/x86/include/asm/idte
USERGS_SYSRET64 is used to return from a syscall via sysret, but
a Xen PV guest will nevertheless use the iret hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just u
Xen PV guests don't use IST. For machine check interrupts switch to
the same model as debug interrupts.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Thomas Gleixner
---
arch/x86/include/asm/idtentry.h | 3 +++
arch/x86/xen/enlighten_pv.c | 16 +++-
[Resend due to all the Cc:'s missing]
This is a major cleanup of the paravirt infrastructure aiming at
eliminating all custom code patching via paravirt patching.
This is achieved by using ALTERNATIVE instead, leading to the ability
to give objtool access to the patched in instructions.
In order
"popf" is a rather expensive operation, so don't use it for restoring
irq flags. Instead test whether interrupts are enabled in the flags
parameter and enable interrupts via "sti" in that case.
This results in the restore_fl paravirt op to be no longer needed.
Suggested-by: Andy Lutomirski
Signe
Instead of only supporting to modify instructions when a specific
feature is set, support doing so for the case a feature is not set.
Add ALTERNATIVE_TERNARY support for replacing an initial instruction
with either of two instructions depending on a feature:
ALTERNATIVE_TERNARY "default_instr",
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this allows quite some simplification of the pvops implementation.
Signed-off-by: Juergen Gross
---
V4:
- drop p
For being able to switch paravirt patching from special cased custom
code sequences to ALTERNATIVE handling some X86_FEATURE_* are needed
as new features. This enables to have the standard indirect pv call
as the default code and to patch that with the non-Xen custom code
sequence via ALTERNATIVE p
The iret paravirt op is rather special as it is using a jmp instead
of a call instruction. Switch it to ALTERNATIVE.
Signed-off-by: Juergen Gross
---
V3:
- use ALTERNATIVE_TERNARY
---
arch/x86/include/asm/paravirt.h | 6 +++---
arch/x86/include/asm/paravirt_types.h | 5 +
arch/x86/ke
The central pvops call macros PVOP_CALL() and PVOP_VCALL() are
looking very similar now.
The main differences are using PVOP_VCALL_ARGS or PVOP_CALL_ARGS, which
are identical, and the return value handling.
So drop PVOP_VCALL_ARGS and instead of PVOP_VCALL() just use
(void)PVOP_CA
PVOP_VCALL4() is only used for Xen PV, while PVOP_CALL4() isn't used
at all. Keep PVOP_CALL4() for 64 bits due to symmetry reasons.
This allows to remove the 32-bit definitions of those macros leading
to a substantial simplification of the paravirt macros, as those were
the only ones needing non-e
Instead of using paravirt patching for custom code sequences add
support for using ALTERNATIVE handling combined with paravirt call
patching.
Signed-off-by: Juergen Gross
---
V3:
- drop PVOP_ALT_VCALL() macro
---
arch/x86/include/asm/paravirt_types.h | 49 ++-
1 file
There is no need any longer to have different paravirt patch functions
for native and Xen. Eliminate native_patch() and rename
paravirt_patch_default() to paravirt_patch().
Signed-off-by: Juergen Gross
---
V3:
- remove paravirt_patch_insns() (kernel test robot)
---
arch/x86/include/asm/paravirt_
Instead of using paravirt patching for custom code sequences use
ALTERNATIVE for the functions with custom code replacements.
Instead of patching an ud2 instruction for unpopulated vector entries
into the caller site, use a simple function just calling BUG() as a
replacement.
Simplify the registe
Hi Roger,
I have set up a test environment based on Linux 5.11.0-rc4.
The patch did not apply clean, so I copied/pasted the patch manually.
Without the patch the call trace (as reported) is visible in dmesg.
With the patch the call trace in dmesg is gone, but ... (there is always a
but) ...
Now
Hi Roger,
I have set up a test environment based on Linux 5.11.0-rc4.
The patch did not apply clean, so I copied/pasted the patch manually.
Without the patch the call trace (as reported) is visible in dmesg.
With the patch the call trace in dmesg is gone, but ... (there is
always a but) ...
Now
On Wed, Jan 20, 2021 at 03:23:30PM +0100, Arthur Borsboom wrote:
> Hi Roger,
>
> I have set up a test environment based on Linux 5.11.0-rc4.
> The patch did not apply clean, so I copied/pasted the patch manually.
>
> Without the patch the call trace (as reported) is visible in dmesg.
> With the p
On 20.01.2021 15:35, Roger Pau Monné wrote:
> On Wed, Jan 20, 2021 at 03:23:30PM +0100, Arthur Borsboom wrote:
>> Hi Roger,
>>
>> I have set up a test environment based on Linux 5.11.0-rc4.
>> The patch did not apply clean, so I copied/pasted the patch manually.
>>
>> Without the patch the call tra
From: Leon Romanovsky
arch/x86/xen/smp_hvm.c: In function 'xen_hvm_smp_init':
arch/x86/xen/smp_hvm.c:77:3: error: 'nopvspin' undeclared (first use in this
function)
nopvspin = true;
^~~~
arch/x86/xen/smp_hvm.c:77:3: note: each undeclared identifier is reported only
once for each
On Wed, Jan 20, 2021 at 03:37:57PM +0100, Jan Beulich wrote:
> On 20.01.2021 15:35, Roger Pau Monné wrote:
> > On Wed, Jan 20, 2021 at 03:23:30PM +0100, Arthur Borsboom wrote:
> >> Hi Roger,
> >>
> >> I have set up a test environment based on Linux 5.11.0-rc4.
> >> The patch did not apply clean, so
On 20.01.21 15:43, Leon Romanovsky wrote:
From: Leon Romanovsky
arch/x86/xen/smp_hvm.c: In function 'xen_hvm_smp_init':
arch/x86/xen/smp_hvm.c:77:3: error: 'nopvspin' undeclared (first use in this
function)
nopvspin = true;
^~~~
arch/x86/xen/smp_hvm.c:77:3: note: each undec
Roger Pau Monné writes ("Re: [PATCH] libs/light: make it build without
setresuid()"):
> On Tue, Jan 12, 2021 at 07:12:36PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > NetBSD doesn't have setresuid(). Add a configure check for it,
> > and use plain setuid() if !HAVE_SETRESUID
...
This patch series is v5 of the work to add support for the SMMUv3 driver.
Approach taken is to first merge the Linux copy of the SMMUv3 driver
(tag v5.8.18) and then modify the driver to build on XEN.
MSI and PCI ATS functionality are not supported. Code is not tested and
compiled. Code is guarde
Based on tag Linux 5.8.18 commit ab435ce49bd1d02e33dfec24f76955dc1196970b
Directory structure change for the SMMUv3 driver starting from
Linux 5.9, to revert the patches smoothly using the "git revert" command
we decided to choose Linux 5.8.18.
Only difference between latest stable Linux 5.9.12 a
Linux SMMUv3 code implements the commands-queue insertion based on
atomic operations implemented in Linux. Atomic functions used by the
commands-queue insertion are not implemented in XEN therefore revert the
patch that implemented the commands-queue insertion based on atomic
operations.
Reverted
On Wed, Jan 20, 2021 at 03:47:00PM +0100, Jürgen Groß wrote:
> On 20.01.21 15:43, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > arch/x86/xen/smp_hvm.c: In function 'xen_hvm_smp_init':
> > arch/x86/xen/smp_hvm.c:77:3: error: 'nopvspin' undeclared (first use in
> > this function)
> >
XArray is not implemented in XEN revert the patch that introduce the
XArray code in SMMUv3 driver.
XArray is added in preparation for sharing some ASIDs with the CPU,
As XEN support only Stage-2 translation, ASID is used for Stage-1
translation there is no consequences of reverting this patch for
Linux SMMUv3 driver supports both Stage-1 and Stage-2 translations.
As of now only Stage-2 translation support has been tested.
Once Stage-1 translation support is tested this patch can be added.
Signed-off-by: Rahul Singh
Acked-by: Stefano Stabellini
---
Changes since v2: No changes
Changes si
Remove code that is related to below functionality :
1. struct io_pgtable_ops
2. struct io_pgtable_cfg
3. struct iommu_flush_ops,
4. struct iommu_ops
5. module_param_named, MODULE_PARM_DESC, module_platform_driver,
MODULE_*
6. IOMMU domain-types
7. arm_smmu_set_bus_ops
8. iommu_device_s
Import the Linux helper of_property_match_string. This function searches
a string list property and returns the index of a specific string value.
Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Reviewed-by: Stefano Stabellini
---
Changes since v2:
- This patch is introduce in this ver
-Wimplicit-fallthrough warns when a switch case falls through. Warning
can be suppress by either adding a /* fallthrough */ comment, or by
using a null statement: __attribute__ ((fallthrough))
Define the pseudo keyword 'fallthrough' for the ability to convert the
various case block /* fallthrough
Backport commit df561f6688fef775baa341a0f5d960becd248b11
"treewide: Use fallthrough pseudo-keyword" from Linux kernel.
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the c
Replace all Linux device tree handling function with the XEN
functions.
Replace all Linux ktime function with the XEN time functions.
Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
Reviewed-by: Bertrand Marquis
---
Changes since v2:
- This patch is introduce in this version.
Chang
Add support for ARM architected SMMUv3 implementation. It is based on
the Linux SMMUv3 driver.
Driver is currently supported as Tech Preview.
Major differences with regard to Linux driver are as follows:
2. Only Stage-2 translation is supported as compared to the Linux driver
that supports bot
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.11-rc5-tag
xen: branch for v5.11-rc5
It contains a fix for build failure showing up in some configurations.
Thanks.
Juergen
arch/x86/xen/smp_hvm.c | 2 ++
1 file changed, 2 ins
(+ Ian)
Hi Vladimir,
On 20/01/2021 11:26, Vladimir Murzin wrote:
Supported values are
0b GIC CPU interface system registers not implemented.
0b0001 System register interface to versions 3.0 and 4.0 of the GIC
CPU interface is supported.
0b0011 System register interface to version
Manuel Bouyer writes ("Re: [PATCH 05/24] Introduce locking functions for block
device setup on NetBSD"):
> On Tue, Dec 29, 2020 at 12:29:09PM +0100, Roger Pau Monné wrote:
> > I think you want tot CC the tools dev on this one, specially Ian who
> > knows how the Linux one is implemented and can li
On Wed, Jan 20, 2021 at 02:52:06PM +, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH] libs/light: make it build without
> setresuid()"):
> > On Tue, Jan 12, 2021 at 07:12:36PM +0100, Manuel Bouyer wrote:
> > > From: Manuel Bouyer
> > >
> > > NetBSD doesn't have setresuid(). Add a c
On 20.01.21 09:50, Jan Beulich wrote:
On 19.01.2021 20:36, Claudemir Todo Bom wrote:
I do not have serial output on this setup, so I recorded a video with
boot_delay=50 in order to be able to get all the kernel messages:
https://youtu.be/y95h6vqoF7Y
This doesn't show any badness afaics.
This
This time the patch applied cleanly.
The trim command seems to work as well, meaning no error messages and
a certain amount of blocks (5GB) is trimmed.
The trimming did consume a bit of time (10-20 seconds), assuming it is
actually discarding the blocks at the host.
First run:
[arthur@test-arch
Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
setresuid()"):
> On Wed, Jan 20, 2021 at 02:52:06PM +, Ian Jackson wrote:
> > I don't think setuid is safe - at least, if we are trying to restrict
> > the dm. Since I think after the libxl child is forked, and has called
>
Julien Grall writes ("Re: [XEN PATCH] xen/arm: Relax GIC version check"):
> On 20/01/2021 11:26, Vladimir Murzin wrote:
> > Supported values are
> >
> > 0b GIC CPU interface system registers not implemented.
> >
> > 0b0001 System register interface to versions 3.0 and 4.0 of the GIC
> >
Hi Rahul,
> On 20 Jan 2021, at 14:52, Rahul Singh wrote:
>
> Add support for ARM architected SMMUv3 implementation. It is based on
> the Linux SMMUv3 driver.
>
> Driver is currently supported as Tech Preview.
>
> Major differences with regard to Linux driver are as follows:
> 2. Only Stage-2 t
Hi Rahul,
> On 20 Jan 2021, at 14:52, Rahul Singh wrote:
>
> Backport commit df561f6688fef775baa341a0f5d960becd248b11
> "treewide: Use fallthrough pseudo-keyword" from Linux kernel.
>
> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallth
Hi Oleksandr,
On 17/01/2021 18:52, Oleksandr wrote:
diff --git a/xen/include/asm-arm/domain.h
b/xen/include/asm-arm/domain.h
index 6819a3b..c235e5b 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
M
Hi Stefano,
On 20/01/2021 00:50, Stefano Stabellini wrote:
On Tue, 19 Jan 2021, Oleksandr wrote:
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 40b9e59..0508bd8 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -101,12 +101,10 @@ enum io_state try_fwd_ioserv(struct
On Wed, Jan 20, 2021 at 03:13:22PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH 05/24] Introduce locking functions for
> block device setup on NetBSD"):
> > On Tue, Dec 29, 2020 at 12:29:09PM +0100, Roger Pau Monné wrote:
> > > I think you want tot CC the tools dev on this one, sp
Manuel Bouyer writes ("Re: [PATCH 05/24] Introduce locking functions for block
device setup on NetBSD"):
> Yes, at last the stat call will need to be patched.
> But it seems to rely on a linux-specific behavoir, which is that
> /dev/stdin points to the real file on redirection:
> >ls -l /dev/stdin
On 12.01.2021 22:52, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The IOREQ is a common feature now and these helpers will be used
> on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes
> with "ioreq".
>
> Signed-off-by: Oleksandr Tyshchenko
> Reviewed-by: Paul Durr
On 12.01.2021 22:52, Oleksandr Tyshchenko wrote:
> From: Julien Grall
>
> As a lot of x86 code can be re-used on Arm later on, this patch
> moves the IOREQ related dm-op handling to the common code.
>
> The idea is to have the top level dm-op handling arch-specific
> and call into ioreq_server_d
On 12.01.2021 22:52, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The IOREQ is a common feature now and these fields will be used
> on Arm as is. Move them to common struct vcpu as a part of new
> struct vcpu_io and drop duplicating "io" prefixes. Also move
> enum hvm_io_completio
flight 158533 linux-5.4 real [real]
flight 158543 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158533/
http://logs.test-lab.xenproject.org/osstest/logs/158543/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
Hi Oleksandr,
On 17/01/2021 22:22, Oleksandr wrote:
On 15.01.21 23:30, Julien Grall wrote:
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Julien Grall
So I am not quite too sure how this new parameter can be used. Could
you expand it?
The original idea was to set it if we are going t
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the device tree.
If this goes into DT, I think we s
On Wed, Jan 20, 2021 at 03:32:29PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
> setresuid()"):
> > On Wed, Jan 20, 2021 at 02:52:06PM +, Ian Jackson wrote:
> > > I don't think setuid is safe - at least, if we are trying to restrict
> > > th
On Wed, Jan 20, 2021 at 04:12:29PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH 05/24] Introduce locking functions for
> block device setup on NetBSD"):
> > Yes, at last the stat call will need to be patched.
> > But it seems to rely on a linux-specific behavoir, which is that
> >
Manuel Bouyer writes ("Re: [PATCH 05/24] Introduce locking functions for block
device setup on NetBSD"):
> On Wed, Jan 20, 2021 at 04:12:29PM +, Ian Jackson wrote:
> > I think NetBSD's stat(1) also takes different argumnts to specify the
> > format. NetBSD uses -f, whereas Linux uses -c. So
Hi Oleksandr,
On 18/01/2021 08:32, Oleksandr wrote:
On 16.01.21 00:01, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-disk
backend (emualator) wh
Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
setresuid()"):
> On Wed, Jan 20, 2021 at 03:32:29PM +, Ian Jackson wrote:
> > Yes, the dm is qemu. If qemu restriction is not supported, that makes
> > a big difference. The complex situation here is to do with trying to
>
Manuel Bouyer writes ("Re: [PATCH 05/24] Introduce locking functions for block
device setup on NetBSD"):
> Right, thanks. Then it would need to be done with 2 different calls
> but I don't think that's a problem (even with the linux version it would
> not be atomic anyway).
Sorry, I forgot to rep
Hi Vladimir,
On 20/01/2021 11:27, Vladimir Murzin wrote:
The ARMv8.3 Pointer Authentication extension is not supported by Xen
at the moment, so do not expose that via ID register.
Signed-off-by: Vladimir Murzin
Reviewed-by: Bertrand Marquis
Reviewed-by: Julien Grall
As I think this one ca
On Wed, Jan 20, 2021 at 05:10:36PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
> setresuid()"):
> > On Wed, Jan 20, 2021 at 03:32:29PM +, Ian Jackson wrote:
> > > Yes, the dm is qemu. If qemu restriction is not supported, that makes
> > > a
Hi Wei,
On 14/01/2021 00:18, Wei Chen wrote:
I think
if we introduce an empty helper for Arm32, we can reduce the other
chunk inside get_cycles. In addition, if we need to do the same work
for Arm32 in the future, we may not need to modify get_cycles.
I don't really follow this. I wasn't asking
Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
setresuid()"):
> On Wed, Jan 20, 2021 at 05:10:36PM +, Ian Jackson wrote:
> > My last mail had in it a thing that claims to be a proof that this is
> > not possible.
>
> This code:
> if (setreuid(375,0) < 0) {
>
On 2021-01-20 16:53, Rob Herring wrote:
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the device tree
Hi Vladimir,
On 20/01/2021 11:27, Vladimir Murzin wrote:
The ARMv8.3 Pointer Authentication extension is not supported by Xen
at the moment, so do not expose that via ID register.
Signed-off-by: Vladimir Murzin
Reviewed-by: Bertrand Marquis
---
xen/arch/arm/cpufeature.c| 6 +
Hi Ian,
On 20/01/2021 15:34, Ian Jackson wrote:
Julien Grall writes ("Re: [XEN PATCH] xen/arm: Relax GIC version check"):
On 20/01/2021 11:26, Vladimir Murzin wrote:
Supported values are
0b GIC CPU interface system registers not implemented.
0b0001 System register interface to versions 3
On 1/20/21 5:44 PM, Julien Grall wrote:
> Hi Vladimir,
>
> On 20/01/2021 11:27, Vladimir Murzin wrote:
>> The ARMv8.3 Pointer Authentication extension is not supported by Xen
>> at the moment, so do not expose that via ID register.
>>
>> Signed-off-by: Vladimir Murzin
>> Reviewed-by: Bertrand Mar
On 08/01/2021 11:50, Wei Chen wrote:
Hi Julien
Hi Wei,
Sorry for the late answer. While cleaning my inbox today, I noticied
that I didn't reply to this thread :(.
integer will do unsigned extend while doing some operations
with 64-bit unsigned integer. This can lead to unexpected
result in
Hi,
> On 20 Jan 2021, at 17:58, Julien Grall wrote:
>
> On 08/01/2021 11:50, Wei Chen wrote:
>> Hi Julien
>
> Hi Wei,
>
> Sorry for the late answer. While cleaning my inbox today, I noticied that I
> didn't reply to this thread :(.
>
integer will do unsigned extend while doing some oper
Hi,
On 19/01/2021 07:25, Elliott Mitchell wrote:
On Mon, Sep 28, 2020 at 09:41:39PM +0900, Masami Hiramatsu wrote:
With Julien's ACPI fix, I found my DeveloperBox (
https://www.96boards.org/product/developerbox/ ) still failed
to boot bcause of SPCR issue. According to the UEFI EDK2
implementat
Hi Juergen,
On 16/01/2021 10:33, Juergen Gross wrote:
There are only two keyhandlers which make use of the cpu_user_regs
struct passed to them. In order to be able to call any keyhandler in
non-interrupt contexts, too, modify those two handlers to cope with a
NULL regs pointer by using run_in_ex
Hi Juergen,
On 16/01/2021 10:33, Juergen Gross wrote:
Add support to run a function in an exception handler for Arm. Do it
as on x86 via a bug_frame, but pass the function pointer via a
register (this needs to be done that way, because inline asm support
for 32-bit Arm lacks the needed functiona
On 20.01.21 19:20, Julien Grall wrote:
Hi Juergen,
On 16/01/2021 10:33, Juergen Gross wrote:
Add support to run a function in an exception handler for Arm. Do it
as on x86 via a bug_frame, but pass the function pointer via a
register (this needs to be done that way, because inline asm support
f
On Mon, Oct 19, 2020 at 4:03 PM Jason Andryuk wrote:
>
> IRQs can be shared, so uniquely labeling doesn't always work. You run
> into issues if you have domA_t allowed access to device_A_t and domB_t
> to device_B_t. The shared IRQ can only be labeled one of
> device_A_t or device_B_t, and assig
On Wed, 20 Jan 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 20/01/2021 00:50, Stefano Stabellini wrote:
> > On Tue, 19 Jan 2021, Oleksandr wrote:
> > > diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
> > > index 40b9e59..0508bd8 100644
> > > --- a/xen/arch/arm/ioreq.c
> > > +++ b/xen/ar
1 - 100 of 136 matches
Mail list logo
