On 15.12.2023 03:43, Shawn Anastasio wrote:
> Introduce setup.h to asm-generic based off of ARM's to define all
> stubs necessary to compile bootfdt.c
And - I'm sorry to ask - how's that "generic"? I'm also not convinced at
all that a generic header can validly use BUG() in the way you propose.
flight 184179 linux-linus real [real]
flight 184188 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184179/
http://logs.test-lab.xenproject.org/osstest/logs/184188/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 184184 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184184/
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
flight 184185 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184185/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a83d953dc2741f650cc273f39fe803ae406b0fad
baseline version:
ovmf
I'd think you'd need the right virtualization loader. I'm not entirely sure
the u-boot.bin you've been creating is for a dom-u..
If I misunderstood, then the below isn't good advice. Chain booting the
u-boot, the first u-boot initializes things so you want
to start with stage after the SPL. But
Pipeline #1113609566 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 725acf8e (
https://gitlab.com/xen-project/xen/-/commit/725acf8e4d406bf0a24441ac1738eb6f4f6ef0c3
)
Commit Message: xen/arm:
On Sat, 2 Dec 2023, Volodymyr Babchuk wrote:
> Add per-domain d->pci_lock that protects access to
> d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
> that underlying pdev will not disappear under feet. This is a rw-lock,
> but this patch adds only write_lock()s. There will be
On Sat, 2 Dec 2023, Volodymyr Babchuk wrote:
> Previously pci_enable_msi() function obtained pdev pointer by itself,
> but taking into account upcoming changes to PCI locking, it is better
> when caller passes already acquired pdev pointer to the function,
> because caller knows better how to
On Tue, 19 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> Function ERR_CAST contains a violation of MISRA C:2012 Rule 11.8,
> whose headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
>
On Tue, 19 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> The
On Tue, 19 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Add
On Tue, 19 Dec 2023, Julien Grall wrote:
> Hi,
>
> On 19/12/2023 14:18, Mykyta Poturai wrote:
> > Following up with relevant QEMU patch link.
> >
> > https://patchwork.kernel.org/project/qemu-devel/patch/c7a180a5874f036c246fc39f921eefafecbc8c76.1702994649.git.mykyta_potu...@epam.com/
>
> I
On Tue, 19 Dec 2023, Julien Grall wrote:
> Hi Stefano,
>
> On 15/12/2023 21:02, Stefano Stabellini wrote:
> > On Fri, 15 Dec 2023, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 09/12/2023 01:39, Stefano Stabellini wrote:
> > > >
> > > > Signed-off-by: Stefano Stabellini
> > > > ---
> >
On Tue, 19 Dec 2023, Jan Beulich wrote:
> The function has a few stray scopes and inconsistent use (indentation)
> of break statements. Drop the stray braces and bring all the break-s in
> line with one another. This in particular means dropping a redundant
> break from XENPF_cpu_offline handling,
Le mer. 20 déc. 2023 à 00:50, Sébastien Chaumat a
écrit :
>
>
> Le mer. 20 déc. 2023 à 00:11, Sébastien Chaumat a
> écrit :
>
>>
>>
>> Le mer. 20 déc. 2023 à 00:06, Sébastien Chaumat a
>> écrit :
>>
>>>
>>>
>>> Le mar. 19 déc. 2023 à 20:03, Sébastien Chaumat a
>>> écrit :
>>>
Le mar. 19
On Tue, 19 Dec 2023, Jan Beulich wrote:
> The final return statement is unreachable and hence disliked by Misra
> C:2012 (rule 2.1). Convert those case-specific (main) return statements
> which already use "rc", or in one case when it can be used without
> further adding of code, to break.
>
> No
On Tue, 19 Dec 2023, Luca Fancellu wrote:
> Hi!
>
> > On 19 Dec 2023, at 11:05, Nicola Vetrini wrote:
> >
> > On 2023-12-19 11:51, Nicola Vetrini wrote:
> >> On 2023-12-19 11:37, Jan Beulich wrote:
> >>> On 19.12.2023 10:02, Nicola Vetrini wrote:
> --- a/docs/misra/exclude-list.json
>
Le mer. 20 déc. 2023 à 00:11, Sébastien Chaumat a
écrit :
>
>
> Le mer. 20 déc. 2023 à 00:06, Sébastien Chaumat a
> écrit :
>
>>
>>
>> Le mar. 19 déc. 2023 à 20:03, Sébastien Chaumat a
>> écrit :
>>
>>> Le mar. 19 déc. 2023 à 16:15, Sébastien Chaumat a
>>> écrit :
>>> >
>>> > I did add an
flight 184176 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184176/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 12 redhat-install fail REGR. vs. 184172
On Tue, 19 Dec 2023 at 12:17, Linus Torvalds
wrote:
>
> That said, I still think that just getting rid of this horrid special
> case for posix timers is the right thing, and we should just remove
> that SYS_NI() alias thing entirely.
IOW, something like the attached patch.
It's not extensively
Le mer. 20 déc. 2023 à 00:06, Sébastien Chaumat a
écrit :
>
>
> Le mar. 19 déc. 2023 à 20:03, Sébastien Chaumat a
> écrit :
>
>> Le mar. 19 déc. 2023 à 16:15, Sébastien Chaumat a
>> écrit :
>> >
>> > I did add an extra printk in PHYSDEVOP_setup_gsi
>> > so the "first one" is my printk
Le mar. 19 déc. 2023 à 20:03, Sébastien Chaumat a
écrit :
> Le mar. 19 déc. 2023 à 16:15, Sébastien Chaumat a
> écrit :
> >
> > I did add an extra printk in PHYSDEVOP_setup_gsi
> > so the "first one" is my printk (available in xl dmesg)
> > the second message is from xen_register_gsi (from
I've asked some help on the channel #arm on Reddit and someone replied :
https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_arm32_bit_as_domu_with/
Maybe his answer can be useful to understand why it does not work.
On Tue, Dec 19, 2023 at 8:33 PM Stefano Stabellini
wrote:
>
flight 184178 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184178/
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
The following hack makes the test pass but there are larger safety
issues that I'll need to look at on Wednesday:
diff --git a/nbd/server.c b/nbd/server.c
index 895cf0a752..cf4b7d5c6d 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1617,7 +1617,7 @@ static void nbd_drained_begin(void *opaque)
On 15/12/2023 11:18 am, Roger Pau Monne wrote:
> Introduce a helper to perform checks related to self modifying code, and start
> by creating a simple test to check that alternatives have been applied.
>
> Such test is hooked into the boot process and called just after alternatives
> have been
On Tue, 19 Dec 2023 at 11:15, Andrew Cooper wrote:
>
> -asmlinkage long sys_ni_posix_timers(void);
> +asmlinkage long sys_ni_posix_timers(const struct pt_regs *regs);
I don't think it should be asmlinkage. That means "use legacy asm
calling conventions", and for x86-32 that means pass on stack.
On Tue, 19 Dec 2023 at 10:59, Kevin Wolf wrote:
>
> Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> > This is the big patch that removes
> > aio_context_acquire()/aio_context_release() from the block layer and
> > affected block layer users.
> >
> > There isn't a clean way to split this
Pipeline #1113302155 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 1b42304f (
https://gitlab.com/xen-project/xen/-/commit/1b42304fd1d84adcf7caf8c12c33ec66347b6dcc
)
Commit Message: xen/arm:
Hi,
On 09/11/2023 18:27, Stewart Hildebrand wrote:
From: Rahul Singh
When ITS is enabled and PCI devices that are behind an SMMU generate an
MSI interrupt, SMMU fault will be observed as there is currently no
mapping in p2m table for the ITS translation register (GITS_TRANSLATER).
A mapping
On 15/12/2023 11:18 am, Roger Pau Monne wrote:
> The minimal function size requirements for livepatch are either 5 bytes (for
"for an x86 livepatch", seeing as we're touching multiple architectures
worth of files.
I know it's at the end of the sentence, but it wants to be earlier to be
clearer.
flight 184177 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184177/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8c1e9f9c6fa7b5137003b0cfa6d54a6bada16d8e
baseline version:
ovmf
Hi Stewart,
On 09/11/2023 18:27, Stewart Hildebrand wrote:
Enable the use of IOMMU + PCI in dom0 without having to specify
"pci-passthrough=yes". We rely on dom0 to initialize the PCI controller
and perform a PHYSDEVOP_pci_device_add call to add each device to SMMU.
Enable pci_init() for
+Michal
Hi Mario,
I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:
name="test"
kernel="u-boot.bin"
extra = "console=hvc0"
memory=256
vcpus=1
disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
Hi Stewart,
On 09/11/2023 18:27, Stewart Hildebrand wrote:
From: Rahul Singh
Current code skip the mapping for PCI bridge MMIO region to dom0 when
pci_passthrough_enabled flag is set. Mapping should be skip when
has_vpci(d) is enabled for the domain, as we need to skip the mapping
only when
Hi,
On 09/11/2023 18:27, Stewart Hildebrand wrote:
From: Rahul Singh
Looking at the code, most of my comments on SMMUv2 apply here too. So I
will not repeat them.
Cheers,
--
Julien Grall
Hi Stewart,
On 09/11/2023 18:27, Stewart Hildebrand wrote:
From: Oleksandr Andrushchenko
In general, we should avoid blank commit. In this case, I think some
details would be useful about the implementation. Some of the details I
am interested in is how the logic works and why we don't
On Tue, Dec 19, 2023 at 10:21 AM Linus Torvalds
wrote:
>
> On Tue, 19 Dec 2023 at 01:58, Borislav Petkov wrote:
> >
> > Looking at the dmesg, I think you missed the most important part - the
> > preceding line:
> >
> > [ 13.480504][ T48] CFI failure at int80_emulation+0x67/0xb0 (target:
> >
On 19/12/2023 6:20 pm, Linus Torvalds wrote:
> On Tue, 19 Dec 2023 at 01:58, Borislav Petkov wrote:
>> Looking at the dmesg, I think you missed the most important part - the
>> preceding line:
>>
>> [ 13.480504][ T48] CFI failure at int80_emulation+0x67/0xb0 (target:
>>
Le mar. 19 déc. 2023 à 16:15, Sébastien Chaumat a écrit :
>
> I did add an extra printk in PHYSDEVOP_setup_gsi
> so the "first one" is my printk (available in xl dmesg)
> the second message is from xen_register_gsi (from linux kernel)
>
> Le mar. 19 déc. 2023 à 14:15, Jan Beulich a écrit :
> >
>
On 12/15/23 04:36, Rahul Singh wrote:
> Hi Stewart,
>
>> On 29 Nov 2023, at 9:25 pm, Stewart Hildebrand
>> wrote:
>>
>> On 11/14/23 04:11, Jan Beulich wrote:
>>> On 13.11.2023 23:21, Stewart Hildebrand wrote:
@@ -709,10 +710,17 @@ int arch_sanitise_domain_config(struct
Hi Stefano,
On 15/12/2023 21:02, Stefano Stabellini wrote:
On Fri, 15 Dec 2023, Julien Grall wrote:
Hi Stefano,
On 09/12/2023 01:39, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- separated 17.1 in its own patch
- add a comment
diff --git
Hi,
On 18/12/2023 14:33, Bertrand Marquis wrote:
Hi Jens,
On 13 Dec 2023, at 11:31, Jens Wiklander wrote:
Until now has FFA_PARTITION_INFO_GET always returned zero in w3, but
FF-A v1.1 requires FFA_PARTITION_INFO_GET to return the size of each
partition information descriptor returned if
Hi Jan,
On 19/12/2023 17:03, Jan Beulich wrote:
On 15.12.2023 03:43, Shawn Anastasio wrote:
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV. Only a minor change to
conditionalize a call to a function only available on
On Tue, 19 Dec 2023 at 01:58, Borislav Petkov wrote:
>
> Looking at the dmesg, I think you missed the most important part - the
> preceding line:
>
> [ 13.480504][ T48] CFI failure at int80_emulation+0x67/0xb0 (target:
> sys_ni_posix_timers+0x0/0x70; expected type: 0xb02b34d9)
>
Am 19.12.2023 um 16:28 hat Kevin Wolf geschrieben:
> Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> > aio_context_acquire()/aio_context_release() has been replaced by
> > fine-grained locking to protect state shared by multiple threads. The
> > AioContext lock still plays the role of
On Tue, Dec 19, 2023 at 04:11:09PM +0100, Roger Pau Monné wrote:
> On Tue, Dec 19, 2023 at 03:06:50PM +0100, Jan Beulich wrote:
> > On 19.12.2023 12:48, Roger Pau Monné wrote:
> > > On Tue, Dec 19, 2023 at 10:56:16AM +0100, Jan Beulich wrote:
> > >> On 18.12.2023 18:24, Roger Pau Monné wrote:
> >
On 15.12.2023 03:43, Shawn Anastasio wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/static-shmem.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __ASM_GENERIC_STATIC_SHMEM_H__
> +#define __ASM_GENERIC_STATIC_SHMEM_H__
> +
> +static inline int
On 15.12.2023 03:43, Shawn Anastasio wrote:
> Move Arm's bootfdt.c to xen/common so that it can be used by other
> device tree architectures like PPC and RISCV. Only a minor change to
> conditionalize a call to a function only available on EFI-supporting
> targets was made to the code itself.
>
>
On 19/12/2023 4:28 pm, Joe Tretter wrote:
> On 12/19/23 10:05, Andrew Cooper wrote:
>> Is it always the same test which fails, or is it random?
> Which test fails seems to be random (see attached screenshot).
>> Looking at https://github.com/Tarsnap/scrypt it's only a trivial piece
>> of userspace
On 16.12.2023 08:01, Neowutran wrote:
> I am wondering if the variable "allow_memory_relocate" is still
> relevant today and if its default value is still relevant.
> Should it be defined to 0 by default instead of 1 (it seems to be a
> workaround for qemu-traditional, so maybe an outdated
On 15.12.2023 12:18, Roger Pau Monne wrote:
> Introduce a helper to perform checks related to self modifying code, and start
> by creating a simple test to check that alternatives have been applied.
>
> Such test is hooked into the boot process and called just after alternatives
> have been
On 15.12.2023 12:18, Roger Pau Monne wrote:
> The minimal function size requirements for livepatch are either 5 bytes (for
> jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm. Ensure
> that distance between functions entry points is always at least of the minimal
> required size
On 19.12.2023 12:05, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Change
On 15.12.2023 15:18, Roger Pau Monne wrote:
> Remove xen_in_range() and vpci_is_mmcfg_address() now that hey are unused.
>
> Adjust comments to point to the new functions that replace the existing ones.
And because of this affecting what was done earlier in the series, perhaps
best if patches
On 15.12.2023 15:18, Roger Pau Monne wrote:
> The current loop that iterates from 0 to the maximum RAM address in order to
> setup the IOMMU mappings is highly inefficient, and it will get worse as the
> amount of RAM increases. It's also not accounting for any reserved regions
> past the last
On 15.12.2023 15:18, Roger Pau Monne wrote:
> Introduce the code to remove regions not to be mapped from the rangeset
> that will be used to setup the IOMMU page tables for the hardware domain.
>
> This change also introduces two new functions: remove_xen_ranges() and
> vpci_subtract_mmcfg() that
On 15.12.2023 15:18, Roger Pau Monne wrote:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -370,10 +370,88 @@ static unsigned int __hwdom_init hwdom_iommu_map(const
> struct domain *d,
> return perms;
> }
>
> +struct map_data {
> +struct
On 19/12/2023 12:32 am, Joe Tretter wrote:
> Hi Andrew.
>
> Yes, running the scrypt unit test twice simultaneously made the error
> occur faster.
> This time, this wasn't required because it failed straight away - the
> boot parameter is present:
Is it always the same test which fails, or is it
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> This is the big patch that removes
> aio_context_acquire()/aio_context_release() from the block layer and
> affected block layer users.
>
> There isn't a clean way to split this patch and the reviewers are likely
> the same group of
On 15.12.2023 15:18, Roger Pau Monne wrote:
> However take into account the minimum number of levels required by unity maps
> when setting the page table levels.
>
> The previous setting of the page table levels for PV guests based on the
> highest RAM address was bogus, as there can be other
On 15.12.2023 15:18, Roger Pau Monne wrote:
> The function also supports non-paging domains, and hence it being placed in
> p2m.h and named with the paging_ prefix is misleading.
>
> Move to x86 domain.c and rename to domain_max_paddr_bits(). Moving to a
> different header is non trivial, as the
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> aio_context_acquire()/aio_context_release() has been replaced by
> fine-grained locking to protect state shared by multiple threads. The
> AioContext lock still plays the role of balancing locking in
> AIO_WAIT_WHILE() and many functions in
flight 184174 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184174/
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
On 19.12.2023 15:36, Roger Pau Monné wrote:
> On Mon, Dec 18, 2023 at 03:39:55PM +0100, Jan Beulich wrote:
>> ..., at least as reasonably feasible without making a check hook
>> mandatory (in particular strict vs relaxed/zero-extend length checking
>> can't be done early this way).
>>
>> Note that
I did add an extra printk in PHYSDEVOP_setup_gsi
so the "first one" is my printk (available in xl dmesg)
the second message is from xen_register_gsi (from linux kernel)
Le mar. 19 déc. 2023 à 14:15, Jan Beulich a écrit :
>
> On 18.12.2023 17:21, Sébastien Chaumat wrote:
> > On 05.12.2023
flight 184175 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184175/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b1f33cbf8113bb07526c9f6946c250c7d9db44f9
baseline version:
ovmf
On Tue, Dec 19, 2023 at 03:06:50PM +0100, Jan Beulich wrote:
> On 19.12.2023 12:48, Roger Pau Monné wrote:
> > On Tue, Dec 19, 2023 at 10:56:16AM +0100, Jan Beulich wrote:
> >> On 18.12.2023 18:24, Roger Pau Monné wrote:
> >>> On Tue, Feb 14, 2023 at 05:12:08PM +0100, Jan Beulich wrote:
> ---
On 2023-12-19 12:28, Jan Beulich wrote:
On 19.12.2023 12:05, Simone Ballarin wrote:
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -109,6 +109,7 @@ static unsigned long copy_guest(void *buf,
uint64_t addr, unsigned int len,
unsigned long raw_copy_to_guest(void *to, const
On 19.12.2023 15:33, Andrew Cooper wrote:
> On 19/12/2023 2:25 pm, Jan Beulich wrote:
>> On 19.12.2023 15:19, Andrew Cooper wrote:
>>> On 19/12/2023 1:48 pm, Mykyta Poturai wrote:
This patch adds the ability for the device emulator to inject MSI
interrupts into guests. This is done by
On Mon, Dec 18, 2023 at 03:41:14PM +0100, Jan Beulich wrote:
> Move the checking into a check hook, and add checking of the padding
> fields as well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks.
On Mon, Dec 18, 2023 at 03:39:55PM +0100, Jan Beulich wrote:
> ..., at least as reasonably feasible without making a check hook
> mandatory (in particular strict vs relaxed/zero-extend length checking
> can't be done early this way).
>
> Note that only one of the two uses of "real" hvm_load() is
On 19/12/2023 2:25 pm, Jan Beulich wrote:
> On 19.12.2023 15:19, Andrew Cooper wrote:
>> On 19/12/2023 1:48 pm, Mykyta Poturai wrote:
>>> This patch adds the ability for the device emulator to inject MSI
>>> interrupts into guests. This is done by adding a new DM op to the device
>>> model
Hi,
On 19/12/2023 14:18, Mykyta Poturai wrote:
Following up with relevant QEMU patch link.
https://patchwork.kernel.org/project/qemu-devel/patch/c7a180a5874f036c246fc39f921eefafecbc8c76.1702994649.git.mykyta_potu...@epam.com/
I don't seem to have the patch in my inbox. I guess you didn't CC
On 19.12.2023 15:19, Andrew Cooper wrote:
> On 19/12/2023 1:48 pm, Mykyta Poturai wrote:
>> This patch adds the ability for the device emulator to inject MSI
>> interrupts into guests. This is done by adding a new DM op to the device
>> model library.
>>
>> It is not possible to reuse already
Pipeline #1112742505 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 05b6368b (
https://gitlab.com/xen-project/xen/-/commit/05b6368ba01e07aa3b2b1f1856d77332971a7bdf
)
Commit Message: x86: don't
Hi Jan,
On 19/12/2023 14:17, Jan Beulich wrote:
On 19.12.2023 15:12, Julien Grall wrote:
On 19/12/2023 13:57, Jan Beulich wrote:
On 19.12.2023 14:48, Mykyta Poturai wrote:
This patch adds the ability for the device emulator to inject MSI
interrupts into guests. This is done by adding a new
On 19/12/2023 1:48 pm, Mykyta Poturai wrote:
> This patch adds the ability for the device emulator to inject MSI
> interrupts into guests. This is done by adding a new DM op to the device
> model library.
>
> It is not possible to reuse already existing inject_msi DM op, because
> it does not have
Following up with relevant QEMU patch link.
https://patchwork.kernel.org/project/qemu-devel/patch/c7a180a5874f036c246fc39f921eefafecbc8c76.1702994649.git.mykyta_potu...@epam.com/
On 19.12.2023 15:12, Julien Grall wrote:
> On 19/12/2023 13:57, Jan Beulich wrote:
>> On 19.12.2023 14:48, Mykyta Poturai wrote:
>>> This patch adds the ability for the device emulator to inject MSI
>>> interrupts into guests. This is done by adding a new DM op to the device
>>> model library.
>>>
On Tue, 19 Dec 2023 at 13:49, Huang Rui wrote:
>
> On Tue, Dec 19, 2023 at 08:20:22PM +0800, Akihiko Odaki wrote:
> > On 2023/12/19 16:53, Huang Rui wrote:
> > > Sync up kernel headers to update venus macro till they are merged into
> > > mainline.
> >
> > Thanks for sorting things out with the
Hi Jan,
On 19/12/2023 13:57, Jan Beulich wrote:
On 19.12.2023 14:48, Mykyta Poturai wrote:
This patch adds the ability for the device emulator to inject MSI
interrupts into guests. This is done by adding a new DM op to the device
model library.
It is not possible to reuse already existing
On 19.12.2023 12:48, Roger Pau Monné wrote:
> On Tue, Dec 19, 2023 at 10:56:16AM +0100, Jan Beulich wrote:
>> On 18.12.2023 18:24, Roger Pau Monné wrote:
>>> On Tue, Feb 14, 2023 at 05:12:08PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@
Hi,
On 19/12/2023 13:48, Mykyta Poturai wrote:
This patch adds the ability for the device emulator to inject MSI
interrupts into guests. This is done by adding a new DM op to the device
model library.
It is not possible to reuse already existing inject_msi DM op, because
it does not have a
On 19/12/2023 1:51 pm, Jan Beulich wrote:
> On 19.12.2023 14:49, Jan Beulich wrote:
>> The comment there was the wrong way round, documentation clearly states
>> that 0 is high and 1 is low.
>>
>> Signed-off-by: Jan Beulich
> And of course in the title s/RET/RTE/.
Acked-by: Andrew Cooper
On 19.12.2023 14:48, Mykyta Poturai wrote:
> This patch adds the ability for the device emulator to inject MSI
> interrupts into guests. This is done by adding a new DM op to the device
> model library.
>
> It is not possible to reuse already existing inject_msi DM op, because
> it does not have
On 19.12.2023 14:49, Jan Beulich wrote:
> The comment there was the wrong way round, documentation clearly states
> that 0 is high and 1 is low.
>
> Signed-off-by: Jan Beulich
And of course in the title s/RET/RTE/.
Jan
> --- a/xen/arch/x86/include/asm/io_apic.h
> +++
The comment there was the wrong way round, documentation clearly states
that 0 is high and 1 is low.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/include/asm/io_apic.h
+++ b/xen/arch/x86/include/asm/io_apic.h
@@ -101,7 +101,7 @@ struct IO_APIC_route_entry {
This patch adds the ability for the device emulator to inject MSI
interrupts into guests. This is done by adding a new DM op to the device
model library.
It is not possible to reuse already existing inject_msi DM op, because
it does not have a devid parameter, which is required for translation of
On Tue, Dec 19, 2023 at 08:20:22PM +0800, Akihiko Odaki wrote:
> On 2023/12/19 16:53, Huang Rui wrote:
> > Sync up kernel headers to update venus macro till they are merged into
> > mainline.
>
> Thanks for sorting things out with the kernel and spec.
>
> >
> > Signed-off-by: Huang Rui
> > ---
On 05.12.2023 21:31, Sébastien Chaumat wrote:
>> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
>
> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
> ioapic-edge and IRQ9 to ioapic-level ?
>
> IR-IO-APIC7-fasteoi pinctrl_amd
> IR-IO-APIC9-fasteoi
On Tue, Dec 19, 2023 at 08:35:27PM +0800, Akihiko Odaki wrote:
> On 2023/12/19 16:53, Huang Rui wrote:
> > Introduce a new virgl_gpu_resource data structure and helper functions
> > for virgl. It's used to add new member which is specific for virgl in
> > following patches of blob memory support.
On 19.12.2023 14:15, Jan Beulich wrote:
> On 18.12.2023 17:21, Sébastien Chaumat wrote:
>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
[2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
>>>
>>> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 )
On 18.12.2023 17:21, Sébastien Chaumat wrote:
> On 05.12.2023 21:31, Sébastien Chaumat wrote:
>>> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
>>
>> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
>> ioapic-edge and IRQ9 to ioapic-level
On Mon, 2023-12-18 at 18:03 -0800, Stefano Stabellini wrote:
> On Mon, 18 Dec 2023, Jan Beulich wrote:
> > On 18.12.2023 17:07, Andrew Cooper wrote:
> > > On 11/12/2023 3:56 pm, Jan Beulich wrote:
> > > > On 07.12.2023 21:17, Andrew Cooper wrote:
> > > > > On 07/12/2023 5:03 pm, Oleksii Kurochko
Am 05.12.2023 um 19:19 hat Stefan Hajnoczi geschrieben:
> v2:
> - Add Patch 2 "scsi: assert that callbacks run in the correct AioContext"
> [Kevin]
> - Add Patch 7 "block: remove bdrv_co_lock()" [Eric and Kevin]
> - Remove stray goto label in Patch 8 [Kevin]
> - Fix "eeked" -> "eked" typo in
On 2023/12/19 16:53, Huang Rui wrote:
Introduce a new virgl_gpu_resource data structure and helper functions
for virgl. It's used to add new member which is specific for virgl in
following patches of blob memory support.
The name is ambigious. It should tell that it's specific for virgl.
flight 184173 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184173/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3c66390e4a514dcce4c8cc82f489d653d55ee3fa
baseline version:
ovmf
On 2023/12/19 16:53, Huang Rui wrote:
Sync up kernel headers to update venus macro till they are merged into
mainline.
Thanks for sorting things out with the kernel and spec.
Signed-off-by: Huang Rui
---
Changes in v6:
- Venus capset is applied in kernel, so update it in qemu for future
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> The AioContext lock no longer exists.
>
> There is one noteworthy change:
>
> - * More specifically, these functions use BDRV_POLL_WHILE(bs), which
> - * requires the caller to be either in the main thread and hold
> - * the
1 - 100 of 131 matches
Mail list logo
