On Thu, May 18, 2023 at 08:18:39PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, May 18, 2023 at 03:42:51PM +0200, Christoph Hellwig wrote:
> > Remove the dangerous late initialization of xen-swiotlb in
> > pci_xen_swiotlb_init_late and instead just always initialize
> > xen-swiotlb in the
On Wed, May 17, 2023 at 06:10:21PM -0400, Stefan Hajnoczi wrote:
> Stop using the .bdrv_co_io_plug() API because it is not multi-queue
> block layer friendly. Use the new blk_io_plug_call() API to batch I/O
> submission instead.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> include/block/raw-aio.h
On Wed, May 17, 2023 at 06:10:22PM -0400, Stefan Hajnoczi wrote:
> No block driver implements .bdrv_co_io_plug() anymore. Get rid of the
> function pointers.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> include/block/block-io.h | 3 ---
> include/block/block_int-common.h | 11 --
On Wed, May 17, 2023 at 06:10:18PM -0400, Stefan Hajnoczi wrote:
> Stop using the .bdrv_co_io_plug() API because it is not multi-queue
> block layer friendly. Use the new blk_io_plug_call() API to batch I/O
> submission instead.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> block/nvme.c | 44
On Wed, May 17, 2023 at 06:10:19PM -0400, Stefan Hajnoczi wrote:
> Stop using the .bdrv_co_io_plug() API because it is not multi-queue
> block layer friendly. Use the new blk_io_plug_call() API to batch I/O
> submission instead.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> block/blkio.c | 40
On Wed, May 17, 2023 at 06:10:20PM -0400, Stefan Hajnoczi wrote:
> Stop using the .bdrv_co_io_plug() API because it is not multi-queue
> block layer friendly. Use the new blk_io_plug_call() API to batch I/O
> submission instead.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> include/block/raw-aio.h
On Thu, 18 May 2023, Roger Pau Monné wrote:
> On Wed, May 17, 2023 at 05:59:31PM -0700, Stefano Stabellini wrote:
> > Hi all,
> >
> > I have run into another PVH Dom0 issue. I am trying to enable a PVH Dom0
> > test with the brand new gitlab-ci runner offered by Qubes. It is an AMD
> > Zen3
Hi all,
After many PVH Dom0 suspend/resume cycles we are seeing the following
Xen crash (it is random and doesn't reproduce reliably):
(XEN) [555.042981][] R
arch/x86/irq.c#_clear_irq_vector+0x214/0x2bd
(XEN) [555.042986][] F destroy_irq+0xe2/0x1b8
(XEN) [555.042991][] F msi_free_irq+0x5e/0x1a7
On Wed, May 17, 2023 at 06:10:17PM -0400, Stefan Hajnoczi wrote:
> Introduce a new API for thread-local blk_io_plug() that does not
> traverse the block graph. The goal is to make blk_io_plug() multi-queue
> friendly.
>
> Instead of having block drivers track whether or not we're in a plugged
>
flight 180700 linux-linus real [real]
flight 180703 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180700/
http://logs.test-lab.xenproject.org/osstest/logs/180703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 180702 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180702/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 180691
build-amd64
Hi Luca,
On 24/04/2023 07:02, Luca Fancellu wrote:
Add sve_vl field to arch_domain and xen_arch_domainconfig struct,
to allow the domain to have an information about the SVE feature
and the number of SVE register bits that are allowed for this
domain.
sve_vl field is the vector length in bits
On Wed, May 17, 2023 at 05:59:31PM -0700, Stefano Stabellini wrote:
> Hi all,
>
> I have run into another PVH Dom0 issue. I am trying to enable a PVH Dom0
> test with the brand new gitlab-ci runner offered by Qubes. It is an AMD
> Zen3 system and we already have a few successful tests with it,
On 18/5/23 12:31, Roger Pau Monné wrote:
On Thu, May 18, 2023 at 10:24:10AM +0300, Xenia Ragiadakou wrote:
On 15/5/23 17:17, Jan Beulich wrote:
On 13.05.2023 03:17, Stefano Stabellini wrote:
From: Stefano Stabellini
Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
On Thu, May 18, 2023 at 10:24:10AM +0300, Xenia Ragiadakou wrote:
>
> On 15/5/23 17:17, Jan Beulich wrote:
> > On 13.05.2023 03:17, Stefano Stabellini wrote:
> > > From: Stefano Stabellini
> > >
> > > Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
> > > the tables in the
Hi Luca,
On 24/04/2023 07:02, Luca Fancellu wrote:
SVE has a new exception class with code 0x19, introduce the new code
and handle the exception.
Signed-off-by: Luca Fancellu
Reviewed-by: Bertrand Marquis
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
When a domain parameter is provided to pci_get_pdev() the search
function would match against the bdf, without taking the segment into
account.
Fix this and also account for the passed segment.
Fixes: 8cf6e0738906 ('PCI: simplify (and thus correct)
pci_get_pdev{,_by_domain}()')
Signed-off-by:
On Thu, May 18, 2023 at 02:36:41PM +0300, Xenia Ragiadakou wrote:
>
> On 18/5/23 12:31, Roger Pau Monné wrote:
> > On Thu, May 18, 2023 at 10:24:10AM +0300, Xenia Ragiadakou wrote:
> > > On 15/5/23 17:17, Jan Beulich wrote:
> > > > On 13.05.2023 03:17, Stefano Stabellini wrote:
> > > > > From:
Hi Luca,
Sorry for jumping late in the review.
On 24/04/2023 07:02, Luca Fancellu wrote:
Enable Xen to handle the SVE extension, add code in cpufeature module
to handle ZCR SVE register, disable trapping SVE feature on system
boot only when SVE resources are accessed.
While there, correct
Hi,
On 24/04/2023 07:02, Luca Fancellu wrote:
When a guest is allowed to use SVE, expose the SVE features through
the identification registers.
Signed-off-by: Luca Fancellu
With one remark below:
Acked-by: Julien Grall
+case HSR_SYSREG_ID_AA64ZFR0_EL1:
+{
+/*
+ *
flight 180691 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180691/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180686
On Wed, May 17, 2023 at 02:00:01PM -0700, Stefano Stabellini wrote:
> On Wed, 17 May 2023, Roger Pau Monné wrote:
> > On Tue, May 16, 2023 at 04:34:09PM -0700, Stefano Stabellini wrote:
> > > On Tue, 16 May 2023, Roger Pau Monné wrote:
> > > > On Mon, May 15, 2023 at 05:11:25PM -0700, Stefano
On 15/5/23 17:17, Jan Beulich wrote:
On 13.05.2023 03:17, Stefano Stabellini wrote:
From: Stefano Stabellini
Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
the tables in the guest. Instead, copy the tables to Dom0.
Do you really mean "in the guest" (i.e. from Xen's
Hi Roger,
> On 18 May 2023, at 11:57 am, Roger Pau Monne wrote:
>
> When a domain parameter is provided to pci_get_pdev() the search
> function would match against the bdf, without taking the segment into
> account.
>
> Fix this and also account for the passed segment.
>
> Fixes: 8cf6e0738906
> On 18 May 2023, at 13:24, Michal Orzel wrote:
>
> The limitation was fixed by the commit:
> 45bfff651173d538239308648c6a6cd7cbe37172
>
> Signed-off-by: Michal Orzel
Hi Michal,
Looks good!
Reviewed-by: Luca Fancellu
> ---
> automation/scripts/build | 6 ++
> 1 file changed, 2
On 18/05/2023 11:57 am, Roger Pau Monne wrote:
> When a domain parameter is provided to pci_get_pdev() the search
> function would match against the bdf, without taking the segment into
> account.
>
> Fix this and also account for the passed segment.
>
> Fixes: 8cf6e0738906 ('PCI: simplify (and
On 18/05/2023 1:42 pm, Andrew Cooper wrote:
> On 18/05/2023 11:57 am, Roger Pau Monne wrote:
>> When a domain parameter is provided to pci_get_pdev() the search
>> function would match against the bdf, without taking the segment into
>> account.
>>
>> Fix this and also account for the passed
Hi All,
Please have a look at
https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html
for the context.
The benefits of using 32 bit physical addresses are as follows :-
1. It helps to use Xen on platforms (for eg R52) which supports 32-bit
physical addresses and has no
Refer ARM DDI 0406C.d ID040418, B3-1345,
"A stage 2 translation with an input address range of 31-34 bits can
start the translation either:
- With a first-level lookup, accessing a first-level translation
table with 2-16 entries.
- With a second-level lookup, accessing a set of concatenated
When 32 bit physical addresses are used (ie PHYS_ADDR_T_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm32.
Also took the opportunity to clean up dump_pt_walk(). One could use
DECLARE_OFFSETS() macro instead of declaring an array of page table
Some Arm based hardware platforms which does not support LPAE
(eg Cortex-R52), uses 32 bit physical addresses.
Also, users may choose to use 32 bits to represent physical addresses
for optimization.
To support the above use cases, we have introduced arch independent
config to choose if the
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.
Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
p2m_root_order can be obtained from the pa_range_info[].root_order and
p2m_root_level can be obtained from pa_range_info[].sl0.
The limitation was fixed by the commit:
45bfff651173d538239308648c6a6cd7cbe37172
Signed-off-by: Michal Orzel
---
automation/scripts/build | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/automation/scripts/build b/automation/scripts/build
index
On Thu, May 18, 2023 at 12:14:46PM +, Rahul Singh wrote:
> Hi Roger,
>
> > On 18 May 2023, at 11:57 am, Roger Pau Monne wrote:
> >
> > When a domain parameter is provided to pci_get_pdev() the search
> > function would match against the bdf, without taking the segment into
> > account.
> >
On Thu, May 18, 2023 at 01:58:34PM +0100, Andrew Cooper wrote:
> On 18/05/2023 1:42 pm, Andrew Cooper wrote:
> > On 18/05/2023 11:57 am, Roger Pau Monne wrote:
> >> When a domain parameter is provided to pci_get_pdev() the search
> >> function would match against the bdf, without taking the
Move the exact checks when to initialize the Xen swiotlb code out
of pci_xen_swiotlb_init and into the caller so that is uses readable
positive checks, rather than negative ones that will get even more
confusing with another addition.
Signed-off-by: Christoph Hellwig
---
Drivers have no business looking at dma-mapping or swiotlb internals.
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index af2e304c672c43..9f1fd28264a067 100644
--- a/kernel/dma/swiotlb.c
Remove the dangerous late initialization of xen-swiotlb in
pci_xen_swiotlb_init_late and instead just always initialize
xen-swiotlb in the boot code if CONFIG_XEN_PCIDEV_FRONTEND is enabled.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/xen/swiotlb-xen.h | 6 --
Hi all,
this little series removes the last swiotlb API exposed to modules.
Diffstat:
arch/x86/include/asm/xen/swiotlb-xen.h |6 --
arch/x86/kernel/pci-dma.c | 28
drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++---
Drivers have no business looking into dma-mapping internals and check
what backend is used. Unfortunstely the DRM core is still broken and
tries to do plain page allocations instead of using DMA API allocators
by default and uses various bandaids on when to use dma_alloc_coherent.
Switch nouveau
On Mon, May 15, 2023 at 05:36:00PM +0530, Viresh Kumar wrote:
> On 12-05-23, 11:43, Anthony PERARD wrote:
> > On Thu, May 11, 2023 at 01:20:43PM +0530, Viresh Kumar wrote:
> > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > > index 24ac92718288..0405f6efe62a 100644
> > > ---
On Mon, May 01, 2023 at 12:27:55PM -0700, Vishal Moola (Oracle) wrote:
> The MM subsystem is trying to shrink struct page. This patchset
> introduces a memory descriptor for page table tracking - struct ptdesc.
>
> This patchset introduces ptdesc, splits ptdesc from struct page, and
> converts
dt_device_get_address() can accept uint64_t only for address and size.
However, the address/size denotes physical addresses. Thus, they should
be represented by 'paddr_t'.
Consequently, we introduce a wrapper for dt_device_get_address() ie
dt_device_get_paddr() which accepts address/size as
The DT functions (dt_read_number(), device_tree_get_reg(), fdt_get_mem_rsv())
currently accept or return 64-bit values.
In future when we support 32-bit physical address, these DT functions are
expected to accept/return 32-bit or 64-bit values (depending on the width of
physical address). Also,
rangeset_{xxx}_range() functions are invoked with 'start' and 'size' as
arguments which are either 'uint64_t' or 'paddr_t'. However, the function
accepts 'unsigned long' for 'start' and 'size'. 'unsigned long' is 32 bits for
Arm32. Thus, there is an implicit downcasting from 'uint64_t'/'paddr_t'
As the previous patch introduces CONFIG_PHYS_ADDR_T_32 to support 32 bit
physical addresses, the code specific to "Large Physical Address Extension"
(ie LPAE) should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32".
Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t"
unsigned
flight 180693 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180693/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
Tests which are
On Thu, Apr 13, 2023 at 09:14:05AM +0200, Jens Wiklander wrote:
> Adds a new "ffa" value to the Enumeration "tee_type" to indicate if a
> guest is trusted to use FF-A.
Is "ffa" working yet in the hypervisor? (At this point in the patch
series) I'm asking because the doc change is at the end of
Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
writeq_relaxed_non_atomic() to write to it instead of invoking
writel_relaxed() twice for lower half and upper half of the register.
This also helps us as p2maddr is 'paddr_t'
handle_pci_range() and map_range_to_domain() take addr and len as uint64_t
parameters. Then frame numbers are obtained from addr and len by right shifting
with PAGE_SHIFT. The frame numbers are expressed using unsigned long.
Now if 64-bit >> PAGE_SHIFT, the result will have 52-bits as valid. On a
In the callback functions invoked by dt_for_each_range() ie handle_pci_range(),
map_range_to_domain(), 'u64' should be replaced with 'uint64_t' as the data type
for the parameters. The reason being Xen coding style mentions that u32/u64
should be avoided.
Also dt_for_each_range() invokes the
flight 180698 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180698/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 180688
test-armhf-armhf-libvirt-qcow2 15
flight 180699 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180699/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-amd64-xl broken
test-amd64-coresched-amd64-xl 26
On Tue, May 02, 2023 at 04:36:50PM -0700, Vikram Garhwal wrote:
> Signed-off-by: Vikram Garhwal
Reviewed-by: Anthony PERARD
--
Anthony PERARD
On Tue, May 02, 2023 at 04:36:49PM -0700, Vikram Garhwal wrote:
> Signed-off-by: Vikram Garhwal
Reviewed-by: Anthony PERARD
--
Anthony PERARD
From: Arnd Bergmann
Date: Tue, 16 May 2023 21:35:34 +0200
> From: Arnd Bergmann
>
> 'make W=1' warns about a function without a prototype in the x86-32 head code:
>
> arch/x86/kernel/head32.c:72:13: error: no previous prototype for
> 'mk_early_pgtbl_32' [-Werror=missing-prototypes]
>
> This
Sorry for the delay. See inline...
On 5/8/23 12:29, Wei Liu wrote:
> On Fri, May 05, 2023 at 05:20:40PM +0200, Mickaël Salaün wrote:
>> From: Madhavan T. Venkataraman
>>
>> Hypervisor Enforced Kernel Integrity (Heki) is a feature that will use
>> the hypervisor to enhance guest virtual machine
On Tue, May 02, 2023 at 04:36:48PM -0700, Vikram Garhwal wrote:
> xc_dt_overlay() sends the device tree binary overlay, size of .dtbo and
> overlay
> operation type i.e. add or remove to xen.
>
> Signed-off-by: Vikram Garhwal
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On 5/16/23 12:35, Arnd Bergmann wrote:
> The ones that are a bit awkward are those that just add a prototype to
> shut up the warning, but the prototypes are never used for calling the
> function because the only caller is in assembler code. I tried to come up
> with other ways to shut up the
flight 180696 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180696/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180689
test-amd64-i386-xl-qemuu-win7-amd64
On 5/16/23 12:35, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> arch/x86/xen/enlighten_pv.c:1233:34: error: no previous prototype for
> 'xen_start_kernel' [-Werror=missing-prototypes]
> arch/x86/xen/irq.c:22:14: error: no previous prototype for
> 'xen_force_evtchn_callback'
Hi Luca,
Sorry for the late reply.
On 25/04/2023 07:04, Luca Fancellu wrote:
On 24 Apr 2023, at 17:10, Jan Beulich wrote:
On 24.04.2023 17:43, Luca Fancellu wrote:
On 24 Apr 2023, at 16:41, Jan Beulich wrote:
On 24.04.2023 17:34, Luca Fancellu wrote:
On 24 Apr 2023, at 16:25, Jan
On Thu, May 18, 2023 at 03:42:51PM +0200, Christoph Hellwig wrote:
> Remove the dangerous late initialization of xen-swiotlb in
> pci_xen_swiotlb_init_late and instead just always initialize
> xen-swiotlb in the boot code if CONFIG_XEN_PCIDEV_FRONTEND is enabled.
>
> Signed-off-by: Christoph
Hi Luca,
On 24/04/2023 07:02, Luca Fancellu wrote:
Save/restore context switch for SVE, allocate memory to contain
the Z0-31 registers whose length is maximum 2048 bits each and
FFR who can be maximum 256 bits, the allocated memory depends on
how many bits is the vector length for the domain
Hi Luca,
One more remark.
On 24/04/2023 07:02, Luca Fancellu wrote:
#else /* !CONFIG_ARM64_SVE */
@@ -46,6 +50,15 @@ static inline unsigned int get_sys_vl_len(void)
return 0;
}
+static inline int sve_context_init(struct vcpu *v)
+{
+return 0;
The call is protected by
On 5/12/23 03:05, Jan Beulich wrote:
> On 11.05.2023 21:16, Stewart Hildebrand wrote:
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -219,7 +219,8 @@ int iommu_dt_domain_init(struct domain *d);
>> int iommu_release_dt_devices(struct domain *d);
>>
>> /*
>> - * Helper to
On 5/12/23 03:28, Jan Beulich wrote:
> On 11.05.2023 21:16, Stewart Hildebrand wrote:
>> It's not necessary to add/remove/assign/deassign pci phantom functions
>> for the ARM SMMU drivers. All associated AXI stream IDs are added during
>> the iommu call for the base PCI device/function.
>>
>>
On 5/15/23 03:30, Jan Beulich wrote:
> On 12.05.2023 23:03, Stewart Hildebrand wrote:
>> On 5/12/23 03:25, Jan Beulich wrote:
>>> On 11.05.2023 21:16, Stewart Hildebrand wrote:
@@ -762,9 +767,20 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
pdev->domain = NULL;
From: Oleksandr Tyshchenko
This flag will be re-used for PCI devices by the subsequent
patches.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Stewart Hildebrand
---
v2->v3:
* no change
v1->v2:
* no change
downstream->v1:
* rebase
* s/dev_node->is_protected/dev_node->dev.is_protected/
From: Oleksandr Tyshchenko
Move code for processing DT IOMMU specifier to a separate helper.
This helper will be re-used for adding PCI devices by the subsequent
patches as we will need exact the same actions for processing
DT PCI-IOMMU specifier.
While at it introduce NO_IOMMU to avoid magic
This series introduces SMMU handling for PCIe passthrough on ARM. These patches
are independent from (and don't depend on) the vPCI reference counting/locking
work in progress, and should be able to be upstreamed independently.
v2->v3:
* drop "pci/arm: Use iommu_add_dt_pci_device()"
* drop "RFC:
From: Oleksandr Tyshchenko
The main purpose of this patch is to add a way to register PCI device
(which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1]
before assigning that device to a domain.
This behaves in almost the same way as existing iommu_add_dt_device API,
the
Handle phantom functions in iommu_add_dt_pci_sideband_ids(). Each phantom
function will have a unique requestor ID (RID)/BDF. On ARM, we need to
map/translate the RID/BDF to an AXI stream ID for each phantom function
according to the pci-iommu device tree mapping [1]. The RID/BDF -> AXI stream ID
From: Rahul Singh
Signed-off-by: Rahul Singh
Signed-off-by: Stewart Hildebrand
---
v2->v3:
* rebase
* invoke iommu_add_pci_sideband_ids() from add_device hook
v1->v2:
* ignore add_device/assign_device/reassign_device calls for phantom functions
(i.e. devfn != pdev->devfn)
downstream->v1:
*
On Thu, 18 May 2023, Michal Orzel wrote:
> The limitation was fixed by the commit:
> 45bfff651173d538239308648c6a6cd7cbe37172
>
> Signed-off-by: Michal Orzel
Acked-by: Stefano Stabellini
> ---
> automation/scripts/build | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Stewart Hildebrand
---
v2->v3:
* invoke iommu_add_pci_sideband_ids() from add_device hook
v1->v2:
* ignore add_device/assign_device/reassign_device calls for phantom
On 5/5/23 01:59, Juergen Gross wrote:
> On 01.05.23 22:30, Stewart Hildebrand wrote:
>> When creating a domU, but the creation fails, there is a corner case that may
>> lead to a crash in the null scheduler when running a debug build of Xen.
>>
>> (XEN)
>>
On 5/16/23 12:35, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This addresses all x86 specific prototype warnings. The majority of the
> patches should be straightforward, either adding an #include statement
> to get the right header, or ensuring that an unused global function is
> left out of
78 matches
Mail list logo
