On Tue, 28 Sep 2021, Rahul Singh wrote:
> Add cmdline boot option "pci-passthrough = = " to enable or
> disable the PCI passthrough support on ARM.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
> ---
> Change in v3:
> - Remove "define pci_passthrough_enabled (false)"
> - Fixe
On Tue, 28 Sep 2021, Rahul Singh wrote:
> pci_init(..) will be called during xen startup to initialize and probe
> the PCI host-bridge driver.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
> ---
> Change in v3:
> - Some nit for device_init(..) return logic
> - Remove inline f
On Tue, 28 Sep 2021, Rahul Singh wrote:
> Based Linux commit 41e5c0f81d3e676d671d96a0a1fafb27abfbd9d7
>
> Import the Linux helper of_get_pci_domain_nr. This function will try to
> obtain the host bridge domain number by finding a property called
> "linux,pci-domain" of the given device node.
>
>
On Tue, 28 Sep 2021, Rahul Singh wrote:
> Based Linux commit a67e9472da423ec47a3586920b526ebaedf25fc3
>
> Import the Linux helper of_property_read_u32_array. This function find
> and read an array of 32 bit integers from a property.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
On Tue, 28 Sep 2021, Rahul Singh wrote:
> Based Linux commit a67e9472da423ec47a3586920b526ebaedf25fc3
>
> Import the Linux helper of_property_read_variable_u32_array. This
> function find and read an array of 32 bit integers from a property,
> with bounds on the minimum and maximum array size.
>
On Tue, 28 Sep 2021, Rahul Singh wrote:
> Hardware domain is in charge of doing the PCI enumeration and will
> discover the PCI devices and then will communicate to XEN via hyper
> call PHYSDEVOP_pci_device_add(..) to add the PCI devices in XEN.
>
> Also implement PHYSDEVOP_pci_device_remove(..) t
That's great, Ian.
Should I go ahead and add the patch to linux-arm-xen? Or do you want to
do it?
On Tue, 28 Sep 2021, i...@xenbits.xen.org wrote:
> [adhoc adhoc]
> harness 3a3089c9: mfi-common: Drop Linux dom0 i386 tests for newer Lin...
> 165241: all pass
>
> flight 165241 xen-unstable adhoc
On 23.09.21 17:31, Jan Beulich wrote:
On 23.09.2021 17:25, Juergen Gross wrote:
On 23.09.21 17:19, Jan Beulich wrote:
On 23.09.2021 17:15, Juergen Gross wrote:
On 23.09.21 17:10, Jan Beulich wrote:
On 23.09.2021 16:59, Juergen Gross wrote:
On 07.09.21 12:11, Jan Beulich wrote:
This was effe
On 28.09.21 17:26, Ian Jackson wrote:
Juergen Gross writes ("Re: [PATCH v5 2/2] tools/xenstore: set open file descriptor
limit for xenstored"):
Hmm, maybe I should just use:
prlimit --nofile=$XENSTORED_MAX_OPEN_FDS \
$XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS
I gu
Thanks! That's a good idea. I will do it in v4 patch.It seems that "dom0_mem=" is a correct setting. It means "give all unused by hypervisor memory to dom0".15:36, 28 сентября 2021 г., Anthony PERARD :On Thu, Sep 16, 2021 at 03:15:21PM +0300, Dmitry Isaykin wrote: This regex is used for auto-balloo
flight 165236 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165236/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel broken
test-amd64-i386-xl
On 9/28/21 2:22 PM, David Hildenbrand wrote:
> The callback is only used for the vmcore nowadays.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Boris Ostrovsky
On 9/28/21 2:22 PM, David Hildenbrand wrote:
> Let's simplify return handling.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/x86/xen/mmu_hvm.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c
> index b242d1f
flight 165234 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-armhf-xl-credit2
On Tue, 28 Sep 2021, Luca Fancellu wrote:
> This patch introduces the support for dom0less configuration
> when using UEFI boot on ARM, it permits the EFI boot to
> continue if no dom0 kernel is specified but at least one domU
> is found.
>
> Introduce the new property "uefi,binary" for device tre
On Tue, 28 Sep 2021, Luca Fancellu wrote:
> Add support to load Dom0 boot modules from
> the device tree using the uefi,binary property.
>
> Update documentation about that.
>
> Signed-off-by: Luca Fancellu
It is great how simple this patch is!
The patch looks all correct. Only one question: d
On Tue, 28 Sep 2021, Luca Fancellu wrote:
> Introduce the uefi,cfg-load DT property of /chosen
> node for ARM whose presence decide whether to force
> the load of the UEFI Xen configuration file.
>
> The logic is that if any multiboot,module is found in
> the DT, then the uefi,cfg-load property is
On 28/09/2021 21:30, Bobby Eshleman wrote:
> This commit allows non-x86 architecture to omit the file asm/debugger.h
> if they do not require it. It changes debugger.h to be a general
> xen/debugger.h which, if CONFIG_CRASH_DEBUG, resolves to include
> asm/debugger.h.
>
> It also changes all asm/d
On 28/09/2021 21:30, Bobby Eshleman wrote:
> Because dbg_rw_mem() has only a single call site, this commit
> expands it inline.
>
> Signed-off-by: Bobby Eshleman
Acked-by: Andrew Cooper
On 28/09/2021 21:30, Bobby Eshleman wrote:
> domain_pause_for_debugger() was previously in debugger.h. This commit
> moves it to domain.h because its implementation is in domain.c.
>
> Signed-off-by: Bobby Eshleman
Reviewed-by: Andrew Cooper
On 28/09/2021 21:30, Bobby Eshleman wrote:
> diff --git a/xen/include/asm-x86/gdbsx.h b/xen/include/asm-x86/gdbsx.h
> new file mode 100644
> index 00..473229a7fb
> --- /dev/null
> +++ b/xen/include/asm-x86/gdbsx.h
> @@ -0,0 +1,19 @@
> +#ifndef __X86_GDBX_H__
> +#define __X86_GDBX_H__
> +
>
On 28/09/2021 21:30, Bobby Eshleman wrote:
> ARM doesn't actually use debugger_trap_* anything, and is stubbed out.
>
> This commit simply removes the unneeded calls.
>
> Signed-off-by: Bobby Eshleman
Julien already acked this patch on v3. You should carry the tag on
future revisions.
Acked-by:
The call to debugger_trap_entry() should pass the correct vector. The
break-for-gdbsx logic is in practice unreachable because PV guests can't
generate #CP, but it will interfere with anyone inserting custom debugging
into debugger_trap_entry().
Fixes: 5ad05b9c2490 ("x86/traps: Implement #CP hand
On 28/09/2021 21:30, Bobby Eshleman wrote:
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index e60af16ddd..772e2a5bfc 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -858,13 +858,20 @@ static void do_trap(struct cpu_user_regs *regs)
> if ( regs->error_code
This commit allows non-x86 architecture to omit the file asm/debugger.h
if they do not require it. It changes debugger.h to be a general
xen/debugger.h which, if CONFIG_CRASH_DEBUG, resolves to include
asm/debugger.h.
It also changes all asm/debugger.h includes to xen/debugger.h.
Because it is n
domain_pause_for_debugger() was previously in debugger.h. This commit
moves it to domain.h because its implementation is in domain.c.
Signed-off-by: Bobby Eshleman
---
Changes in v3:
- domain_pause_for_debugger() is now moved into debugger.h, not a new
file debugger.c
Changes in v4:
- Don't u
Because dbg_rw_mem() has only a single call site, this commit
expands it inline.
Signed-off-by: Bobby Eshleman
---
Changes in v4:
- Add DCO
xen/arch/x86/gdbsx.c | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/xen/arch/x86/gdbsx.c b/xen/arch/x8
This commit renames debug.c to gdbsx.c to clarify its purpose.
The function gdbsx_guest_mem_io() is moved from domctl.c to gdbsx.c.
Although gdbsx_guest_mem_io() is conditionally removed from its single
call site in domctl.c upon !CONFIG_GDBSX and so no stub is technically
necessary, this commit
The functions debugger_trap_fatal(), debugger_trap_immediate(), and
debugger_trap_entry() are generic hook functions for debugger support.
In practice, debugger_trap_fatal() and debugger_trap_immediate() are
only used in the debugging of Xen itself and debugger_trap_entry() is
only used in the debu
ARM doesn't actually use debugger_trap_* anything, and is stubbed out.
This commit simply removes the unneeded calls.
Signed-off-by: Bobby Eshleman
---
xen/arch/arm/traps.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4ccb6e7d18..88
This series removes the unconditional requirement that all architectures
implement asm/debugger.h. It additionally removes arm's debugger.h and
disentangles some of the x86 gdbsx/gdbstub/generic debugger code.
Additionally, this series does the following:
- Provides generic stubs when !CONFIG_CRAS
On Tue, Sep 28, 2021 at 9:26 AM Stefano Stabellini
wrote:
Hi Stefano, all
[Sorry for the possible format issues]
On Mon, 27 Sep 2021, Christopher Clark wrote:
> > On Mon, Sep 27, 2021 at 3:06 AM Alex Bennée via Stratos-dev <
> stratos-...@op-lists.linaro.org> wrote:
> >
> > Marek Marczyk
flight 165243 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 165233
Tests which
flight 165231 linux-linus real [real]
flight 165244 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165231/
http://logs.test-lab.xenproject.org/osstest/logs/165244/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
Let's prepare for a new virtio-mem kdump mode in which we don't actually
hot(un)plug any memory but only observe the state of device blocks.
Signed-off-by: David Hildenbrand
---
drivers/virtio/virtio_mem.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers
Let's prepare for a new virtio-mem kdump mode in which we don't actually
hot(un)plug any memory but only observe the state of device blocks.
Signed-off-by: David Hildenbrand
---
drivers/virtio/virtio_mem.c | 81 -
1 file changed, 44 insertions(+), 37 deletions
Let's support multiple registered callbacks, making sure that
registering vmcore callbacks cannot fail. Make the callback return a
bool instead of an int, handling how to deal with errors internally.
Drop unused HAVE_OLDMEM_PFN_IS_RAM.
We soon want to make use of this infrastructure from other dri
Although virtio-mem currently supports reading unplugged memory in the
hypervisor, this will change in the future, indicated to the device via
a new feature flag. We similarly sanitized /proc/kcore access recently. [1]
Let's register a vmcore callback, to allow vmcore code to check if a PFN
belong
Let's prepare for a new virtio-mem kdump mode in which we don't actually
hot(un)plug any memory but only observe the state of device blocks.
Signed-off-by: David Hildenbrand
---
drivers/virtio/virtio_mem.c | 87 +++--
1 file changed, 45 insertions(+), 42 deletions
If the property is not present in the device tree node for host bridge,
XEN while creating the dtb for hwdom will create this property and
assigns the already allocated segment to the host bridge
so that XEN and linux will have the same segment for the host bridges.
Signed-off-by: Rahul Singh
---
libxl will create an emulated PCI device tree node in the device tree to
enable the guest OS to discover the virtual PCI during guest boot.
Emulated PCI device tree node will only be created when there is any
device assigned to guest.
A new area has been reserved in the arm guest physical map at
w
This patch will be reverted once we add support for VPCI MSI/MSIX
support on ARM.
Signed-off-by: Rahul Singh
---
Change in v3: none
Change in v2: Patch introduced in v2
---
xen/drivers/vpci/Makefile | 3 ++-
xen/drivers/vpci/header.c | 2 ++
xen/include/asm-arm/pci.h | 8
3 files change
The callback should deal with errors internally, it doesn't make sense to
expose these via pfn_is_ram(). We'll rework the callbacks next. Right now
we consider errors as if "it's RAM"; no functional change.
Signed-off-by: David Hildenbrand
---
fs/proc/vmcore.c | 8
1 file changed, 4 ins
Let's simplify return handling.
Signed-off-by: David Hildenbrand
---
arch/x86/xen/mmu_hvm.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c
index b242d1f4b426..eb61622df75b 100644
--- a/arch/x86/xen/mmu_hvm.c
+++ b/a
The existing VPCI support available for X86 is adapted for Arm.
When the device is added to XEN via the hyper call
“PHYSDEVOP_pci_device_add”, VPCI handler for the config space
access is added to the Xen to emulate the PCI devices config space.
A MMIO trap handler for the PCI ECAM space is registe
The callback is only used for the vmcore nowadays.
Signed-off-by: David Hildenbrand
---
arch/x86/xen/mmu_hvm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c
index 57409373750f..b242d1f4b426 100644
--- a/arch/x86/xen/m
As so often with virtio-mem changes that mess with common MM
infrastructure, this might be a good candiate to go via Andrew's tree.
--
After removing /dev/kmem, sanitizing /proc/kcore and handling /dev/mem,
this series tackles the last sane way how a VM could accidentially access
logically unplug
Implement generic pci access functions to read/write the configuration
space.
Signed-off-by: Rahul Singh
---
Change in v3:
- Remove PRI_pci as not used.
- Replace uint32_t sbdf to pci_sbdf_t sbdf to avoid typecast
Change in v2: Fixed comments
---
xen/arch/arm/pci/pci-access.c | 57 +
From: Oleksandr Andrushchenko
Add support for Xilinx ZynqMP PCI host controller to map the PCI config
space to the XEN memory.
Patch helps to understand how the generic infrastructure for PCI
host-bridge discovery will be used for future references.
Signed-off-by: Oleksandr Andrushchenko
---
C
XEN during boot will read the PCI device tree node “reg” property
and will map the PCI config space to the XEN memory.
As of now only "pci-host-ecam-generic" compatible board is supported.
"linux,pci-domain" device tree property assigns a fixed PCI domain
number to a host bridge, otherwise an uns
Add cmdline boot option "pci-passthrough = = " to enable or
disable the PCI passthrough support on ARM.
Signed-off-by: Rahul Singh
---
Change in v3:
- Remove "define pci_passthrough_enabled (false)"
- Fixed coding style and minor comment
Change in v2:
- Add option in xen-command-line.pandoc
- Cha
pci_init(..) will be called during xen startup to initialize and probe
the PCI host-bridge driver.
Signed-off-by: Rahul Singh
---
Change in v3:
- Some nit for device_init(..) return logic
- Remove inline from acpi_pci_init(..)
- Modify return value for apci_pci_init(..) to return -EOPNOTSUPP
Chan
Based Linux commit 41e5c0f81d3e676d671d96a0a1fafb27abfbd9d7
Import the Linux helper of_get_pci_domain_nr. This function will try to
obtain the host bridge domain number by finding a property called
"linux,pci-domain" of the given device node.
Signed-off-by: Rahul Singh
---
Change in v3:
- Modify
Based Linux commit a67e9472da423ec47a3586920b526ebaedf25fc3
Import the Linux helper of_property_read_u32_array. This function find
and read an array of 32 bit integers from a property.
Signed-off-by: Rahul Singh
---
Change in v3:
- Modify commit message to include upstream Linux commit-id not st
Based Linux commit a67e9472da423ec47a3586920b526ebaedf25fc3
Import the Linux helper of_property_read_variable_u32_array. This
function find and read an array of 32 bit integers from a property,
with bounds on the minimum and maximum array size.
Signed-off-by: Rahul Singh
---
Change in v3:
- Modi
Hardware domain is in charge of doing the PCI enumeration and will
discover the PCI devices and then will communicate to XEN via hyper
call PHYSDEVOP_pci_device_add(..) to add the PCI devices in XEN.
Also implement PHYSDEVOP_pci_device_remove(..) to remove the PCI device.
As most of the code for
ARM architecture does not implement I/O ports. Ignore this call on ARM
to avoid the overhead of making a hypercall just for Xen to return
-ENOSYS.
Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
---
Change in v3: Added Reviewed-by: Stefano Stabellini
Change in v2:
- Instead of return
prelink.o: In function `pcie_aer_get_firmware_first’:
drivers/passthrough/pci.c:1251: undefined reference to `apei_hest_parse'
Compilation error is observed when ACPI and HAS_PCI is enabled for ARM
architecture. APEI not supported on ARM yet move the code under
CONFIG_X86 flag to gate the code for
In a follow-up we will enable PCI support in Xen on Arm (i.e select
HAS_PCI).
The generic code expects the arch to implement a few functions:
arch_iommu_use_permitted()
arch_pci_clean_pirqs()
Note that this is not yet sufficient to enable HAS_PCI and will be
addressed in follow-ups.
Signed-off-b
On Arm, the initial plan is to only support GICv3 ITS which doesn't
require us to manage the MSIs because the HW will protect against
spoofing. Move the code under CONFIG_HAS_PCI_MSI flag to gate the code
for ARM.
No functional change intended.
Signed-off-by: Rahul Singh
Reviewed-by: Daniel P. S
Hello All,
The purpose of this patch series is to add PCI passthrough support to Xen on
Arm. PCI passthrough support on ARM is the collaboration work between EPAM and
ARM. ARM submitted the partial RFC [1][2] last year to get early feedback. We
tried to fix all the comments and added more features
[adhoc adhoc]
harness 3a3089c9: mfi-common: Drop Linux dom0 i386 tests for newer Lin...
165241: all pass
flight 165241 xen-unstable adhoc [adhoc]
http://logs.test-lab.xenproject.org/osstest/logs/165241/
Perfect :-)
All tests in this flight passed as required
jobs:
build-arm64-pvops
flight 165233 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165233/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Jan
> On 24 Sep 2021, at 8:44 am, Jan Beulich wrote:
>
> On 22.09.2021 13:35, Rahul Singh wrote:
>> @@ -623,7 +624,7 @@ int arch_sanitise_domain_config(struct
>> xen_domctl_createdomain *config)
>> unsigned int max_vcpus;
>>
>> /* HVM and HAP must be set. IOMMU may or may not be */
Add support to load Dom0 boot modules from
the device tree using the uefi,binary property.
Update documentation about that.
Signed-off-by: Luca Fancellu
---
Changes in v3:
- new patch
---
docs/misc/arm/device-tree/booting.txt | 8
docs/misc/efi.pandoc | 64 +++
This patch introduces the support for dom0less configuration
when using UEFI boot on ARM, it permits the EFI boot to
continue if no dom0 kernel is specified but at least one domU
is found.
Introduce the new property "uefi,binary" for device tree boot
module nodes that are subnode of "xen,domain" c
This serie introduces a way to start a dom0less setup when Xen is booting as EFI
application.
Using the device tree it's now possible to fetch from the disk and load in
memory all the modules needed to start any domU defined in the DT.
Dom0less for now is supported only by the arm architecture.
Lu
Introduce the uefi,cfg-load DT property of /chosen
node for ARM whose presence decide whether to force
the load of the UEFI Xen configuration file.
The logic is that if any multiboot,module is found in
the DT, then the uefi,cfg-load property is used to see
if the UEFI Xen configuration file is nee
Jan Beulich writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
> Ian, for your setting up of a one-off flight (as just talked about),
> you can find the patch at
> https://lists.xen.org/archives/html/xen-devel/2021-09/msg01691.html
> (and perhaps in your mailbox). In case that's easier
On Tue, 28 Sep 2021, Oleksandr Andrushchenko wrote:
> [snip]
> >> Sorry I didn't follow your explanation.
> >>
> >> My suggestion is to remove the #ifdef CONFIG_HAS_PCI completely from
> >> map_range_to_domain. At the beginning of map_range_to_domain, there is
> >> already this line:
> >>
> >> bool
On 28.09.21 09:28, Michal Orzel wrote:
Hi Oleksandr,
Hi Michal
On 24.09.2021 00:48, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest address
space size to the toolstack on Arm in order to properly
calculate the base and size of
flight 165227 xen-unstable real [real]
flight 165235 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165227/
http://logs.test-lab.xenproject.org/osstest/logs/165235/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
Juergen Gross writes ("Re: [PATCH v5 2/2] tools/xenstore: set open file
descriptor limit for xenstored"):
> Hmm, maybe I should just use:
>
> prlimit --nofile=$XENSTORED_MAX_OPEN_FDS \
> $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS
I guess that would probably work (altho
On 23.09.2021 04:56, Julien Grall wrote:
> We could push the patch in the branch we have. However the Linux we use is
> not fairly old (I think I did a push last year) and not even the latest
> stable.
I don't think that's a problem here - this looks to be 5.4.17-ish, which
the patch should be goo
> On 28 Sep 2021, at 16:04, Anthony PERARD wrote:
>
> This will help prevent the CI loop from having build failures when
> `checkpolicy` isn't available when doing "randconfig" jobs.
>
> To prevent "randconfig" from selecting XSM_FLASK_POLICY when
> `checkpolicy` isn't available, we will actu
On 28.09.2021 17:04, Anthony PERARD wrote:
> This will help prevent the CI loop from having build failures when
> `checkpolicy` isn't available when doing "randconfig" jobs.
>
> To prevent "randconfig" from selecting XSM_FLASK_POLICY when
> `checkpolicy` isn't available, we will actually override
On Tue, Sep 28, 2021 at 03:34:00PM +0100, Anthony PERARD wrote:
> On Tue, Sep 28, 2021 at 03:46:01PM +0200, Jan Beulich wrote:
> > On 28.09.2021 10:39, Anthony PERARD wrote:
> > > This will help prevent the CI loop from having build failures when
> > > `checkpolicy` isn't available when doing "rand
This will help prevent the CI loop from having build failures when
`checkpolicy` isn't available when doing "randconfig" jobs.
To prevent "randconfig" from selecting XSM_FLASK_POLICY when
`checkpolicy` isn't available, we will actually override the config
output with the use of KCONFIG_ALLCONFIG.
> On 28 Sep 2021, at 09:39, Anthony PERARD wrote:
>
> This will help prevent the CI loop from having build failures when
> `checkpolicy` isn't available when doing "randconfig" jobs.
>
> To prevent "randconfig" from selecting XSM_FLASK_POLICY when
> `checkpolicy` isn't available, we will actu
[snip]
>> Sorry I didn't follow your explanation.
>>
>> My suggestion is to remove the #ifdef CONFIG_HAS_PCI completely from
>> map_range_to_domain. At the beginning of map_range_to_domain, there is
>> already this line:
>>
>> bool need_mapping = !dt_device_for_passthrough(dev);
>>
>> We can change
On Tue, Sep 28, 2021 at 03:46:01PM +0200, Jan Beulich wrote:
> On 28.09.2021 10:39, Anthony PERARD wrote:
> > This will help prevent the CI loop from having build failures when
> > `checkpolicy` isn't available when doing "randconfig" jobs.
> >
> > To prevent "randconfig" from selecting XSM_FLASK_
On 28.09.2021 10:39, Anthony PERARD wrote:
> This will help prevent the CI loop from having build failures when
> `checkpolicy` isn't available when doing "randconfig" jobs.
>
> To prevent "randconfig" from selecting XSM_FLASK_POLICY when
> `checkpolicy` isn't available, we will actually override
On 22.09.2021 12:00, Roger Pau Monné wrote:
> On Wed, Sep 22, 2021 at 11:42:30AM +0200, Jan Beulich wrote:
>> On 22.09.2021 11:26, Roger Pau Monné wrote:
>>> On Tue, Sep 21, 2021 at 12:12:05PM +0200, Jan Beulich wrote:
On 21.09.2021 10:32, Roger Pau Monné wrote:
> On Mon, Sep 20, 2021 at 0
On 28.09.21 11:17, Michal Orzel wrote:
>
> On 28.09.2021 09:59, Jan Beulich wrote:
>> On 28.09.2021 09:48, Michal Orzel wrote:
>>> On 23.09.2021 14:55, Oleksandr Andrushchenko wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -833,6 +833,63 @@ int pci
flight 165226 qemu-mainline real [real]
flight 165232 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165226/
http://logs.test-lab.xenproject.org/osstest/logs/165232/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Thu, Sep 16, 2021 at 03:15:21PM +0300, Dmitry Isaykin wrote:
> This regex is used for auto-balloon mode detection based on Xen command line.
>
> The case of specifying a negative size was handled incorrectly.
> From misc/xen-command-line documentation:
>
> dom0_mem (x86)
> = List of (
Hi,
> On 24 Sep 2021, at 10:10, Igor Druzhinin wrote:
>
> Bus number 0xff is valid according to the PCI spec. Using u8 typed sub_bus
> and assigning 0xff to it will result in the following loop getting stuck.
>
>for ( ; sec_bus <= sub_bus; sec_bus++ ) {...}
>
> Just change its type to unsi
On 28.09.21 14:02, Ian Jackson wrote:
Juergen Gross writes ("[PATCH v5 2/2] tools/xenstore: set open file descriptor limit
for xenstored"):
Add a configuration item for the maximum number of open file
descriptors xenstored should be allowed to have.
The default should be "unlimited" in order n
On 23.09.2021 11:54, Julien Grall wrote:
> On 23/09/2021 08:11, Penny Zheng wrote:
>> From: Stefano Stabellini
>>
>> We are passing an extra special boolean flag at domain creation to
>> specify whether we want to the domain to be privileged (i.e. dom0) or
>> not. Another flag will be introduced l
Juergen Gross writes ("[PATCH v5 2/2] tools/xenstore: set open file descriptor
limit for xenstored"):
> Add a configuration item for the maximum number of open file
> descriptors xenstored should be allowed to have.
>
> The default should be "unlimited" in order not to restrict xenstored
> in the
Anthony PERARD writes ("Re: [XEN PATCH] Config.mk: update OVMF to
edk2-stable202108"):
> On Tue, Aug 31, 2021 at 02:58:36PM +0100, Ian Jackson wrote:
> > Anthony PERARD writes ("[XEN PATCH] Config.mk: update OVMF to
> > edk2-stable202108"):
> > > Update to the latest stable tag.
> >
> > Thanks.
On Tuesday, 14 September, 2021, 07:00:27 pm IST, P J P
wrote:
>* Thanks so much for restarting this thread. I've been at it intermittently
>last few
> months, thinking about how could we annotate the source/module objects.
>
> -> [*] https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04642
On 24/09/2021 17:02, Alex Bennée wrote:
> 1.1 Upstream an "official" rust crate for Xen ([STR-52])
>
>
> To start with we will want an upstream location for future work to be
> based upon. The intention is the crate is independent of the
flight 165228 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165228/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 23.09.2021 14:54, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This is in preparation for dynamic assignment of the vpci register
> handlers depending on the domain: hwdom or guest.
>
> Signed-off-by: Oleksandr Andrushchenko
>
> ---
> Since v1:
> - constify struct
On 9/28/2021 1:39 PM, Christoph Hellwig wrote:
On Mon, Sep 27, 2021 at 10:26:43PM +0800, Tianyu Lan wrote:
Hi Christoph:
Gentile ping. The swiotlb and shared memory mapping changes in this
patchset needs your reivew. Could you have a look? >
I'm a little too busy for a review of such a hug
Add a configuration item for the maximum number of open file
descriptors xenstored should be allowed to have.
The default should be "unlimited" in order not to restrict xenstored
in the number of domains it can support, but unfortunately the kernel
is normally limiting the maximum value via /proc/
Xenstored is absolutely mandatory for a Xen host and it can't be
restarted, so being killed by OOM-killer in case of memory shortage is
to be avoided.
Set /proc/$pid/oom_score_adj (if available) per default to -500 (this
translates to 50% of dom0 memory size) in order to allow xenstored to
use lar
Set some limits for xenstored in order to avoid it being killed by
OOM killer, or to run out of file descriptors.
Changes in V5:
- respect /proc/sys/fs/nr_open (Ian Jackson)
Changes in V4:
- add comments
- switch to configure open file descriptors directly
Changes in V3:
- make oom score configu
flight 165230 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165230/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
1 - 100 of 131 matches
Mail list logo
