On 24.01.2024 17:24, Andrew Cooper wrote:
> On 24/01/2024 3:27 pm, Jan Beulich wrote:
>> ... if available only, of course.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -406,9 +406,15 @@ void __init early_cpu_init(bool verbose)
>>
On 24.01.2024 18:23, Andrew Cooper wrote:
> On 24/01/2024 3:37 pm, Jan Beulich wrote:
>> On 23.01.2024 21:59, Andrew Cooper wrote:
>>> Always run microcode_update_helper() on the BSP, so the the updated Raw CPU
>>> policy doesn't get non-BSP topology details included.
>> Wouldn't it be better (and
On 24.01.2024 18:51, Roger Pau Monné wrote:
> On Wed, Jan 24, 2024 at 12:34:10PM +0100, Jan Beulich wrote:
>> On 24.01.2024 10:24, Roger Pau Monné wrote:
>>> On Wed, Jan 24, 2024 at 09:48:35AM +0100, Jan Beulich wrote:
On 23.01.2024 16:07, Roger Pau Monné wrote:
> On Tue, Jan 23, 2024 at
On 2024/1/24 00:02, Bjorn Helgaas wrote:
> On Tue, Jan 23, 2024 at 10:13:52AM +, Chen, Jiqian wrote:
>> On 2024/1/23 07:37, Bjorn Helgaas wrote:
>>> On Fri, Jan 05, 2024 at 02:22:17PM +0800, Jiqian Chen wrote:
There is a need for some scenarios to use gsi sysfs.
For example, when xen
flight 184449 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184449/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184434
On 24/01/2024 7:28 am, Jan Beulich wrote:
> On 24.01.2024 02:34, Stefano Stabellini wrote:
>> I managed to get back to read the mailing list and noticed this patch.
>>
>> Is it still relevant and needs to be reviewed?
>>
>> Are there any outstanding disagreements between maintainers on the
>>
On Wed, Jan 24, 2024 at 3:23 AM Roger Pau Monné
wrote:
> > >
> > >>
> > >> > I had been working with ASRock support ever since I got my brand
> > >> > new motherboard because I couldn't see the BIOS/UEFI screens. I
> could
> > >> boot
> > >> > up, and once native linux took control amdgpu got
On Wed, 24 Jan 2024, Andrew Cooper wrote:
> On 24/01/2024 1:07 am, Stefano Stabellini wrote:
> >> I agree with Jan that we could reuse
> >> xendevicemodel_inject_msi by assuing that PCI BDF zero is invalid.
>
> I've already explained why that will break future x86. (See the other
> thread off
On 23/01/2024 8:29 am, Bertrand Marquis wrote:
>> Thanks for raising the visibility of this. I'm not familiar with ARM,
>> but if I were investigating this I'd try to figure out what the
>> "unhandled" error messages are. "gnttab_mark_dirty not implemented
>> yet" looks pretty sus too, and also
Elliot, Bertrand, George: Thanks for your replies.
Am 23.01.2024 um 09:29 schrieb Bertrand Marquis:
Hi,
will try to explain some of the messages here after but I am not sure of the
reason
of the crash so I will just set some pointers...
On 22 Jan 2024, at 11:46, George Dunlap wrote:
On
When HWP is active, the cpufreq P-state information is not updated. In
that case, return -EOPNOTSUPP instead of bogus, incomplete info.
Similarly, set_cpufreq_para() is not applicable when HWP is active.
Many of the options already checked the governor and were inaccessible,
but
xenpm get-cpufreq-states currently just prints no output when cpufreq is
disabled or HWP is running. Have it print an appropriate message. The
cpufreq disabled one mirros the cpuidle disabled one.
cpufreq disabled:
$ xenpm get-cpufreq-states
Either Xen cpufreq is disabled or no valid
Have xen return -EOPNOTSUPP for more pmstat hypercalls instead of
returning misleading data under HWP. Enhance xenpm to handle
-EOPNOTSUPP and provide more informative messages.
Jason Andryuk (2):
pmstat: Limit hypercalls under HWP
xenpm: Print message for disabled commands
On 24/01/2024 1:07 am, Stefano Stabellini wrote:
>> I agree with Jan that we could reuse
>> xendevicemodel_inject_msi by assuing that PCI BDF zero is invalid.
I've already explained why that will break future x86. (See the other
thread off this patch for specifics).
When we add vIOMMUs to
On 14/01/2024 10:01 am, Mykyta Poturai wrote:
> diff --git a/tools/include/xendevicemodel.h b/tools/include/xendevicemodel.h
> index 797e0c6b29..4833e55bce 100644
> --- a/tools/include/xendevicemodel.h
> +++ b/tools/include/xendevicemodel.h
> @@ -236,6 +236,20 @@ int xendevicemodel_inject_msi(
>
On 1/24/24 03:21, Roger Pau Monné wrote:
> On Wed, Jan 24, 2024 at 12:07:28AM -0500, Stewart Hildebrand wrote:
>> On 1/23/24 09:29, Jan Beulich wrote:
>>> On 15.01.2024 20:43, Stewart Hildebrand wrote:
@@ -1043,11 +1043,11 @@ static int __pci_enable_msix(struct pci_dev *pdev,
struct
flight 184445 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184445/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184431
test-armhf-armhf-libvirt-qcow2 15
flight 184453 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184453/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ff52277e3796c50511e544219dde0b21edf5c53e
baseline version:
ovmf
On Wed, Jan 24, 2024 at 12:34:10PM +0100, Jan Beulich wrote:
> On 24.01.2024 10:24, Roger Pau Monné wrote:
> > On Wed, Jan 24, 2024 at 09:48:35AM +0100, Jan Beulich wrote:
> >> On 23.01.2024 16:07, Roger Pau Monné wrote:
> >>> On Tue, Jan 23, 2024 at 03:32:12PM +0100, Jan Beulich wrote:
> On
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 RAM address.
Instead of iterating over memory
Hello,
The aim of the series is to reduce boot time setup of IOMMU page tables
for dom0.
This patches rework the hardware domain IOMMU setup to use a rangeset
instead of iterating over all addresses up to the max RAM page. See
patch 2/3 for performance figures.
Jan: I've kept your RB in patch
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.
No functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v2:
- Do remove vpci_is_mmcfg_address().
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 copy the logic in xen_in_range() and
On 24/01/2024 3:37 pm, Jan Beulich wrote:
> On 23.01.2024 21:59, Andrew Cooper wrote:
>> Always run microcode_update_helper() on the BSP, so the the updated Raw CPU
>> policy doesn't get non-BSP topology details included.
> Wouldn't it be better (and consistent with ...
>
>> Have
Xen PV domains show CPA W^X violations like:
CPA detected W^X violation: 0064 -> 0067 range:
0x8881 - 0x88810fff PFN 10
WARNING: CPU: 0 PID: 30 at arch/x86/mm/pat/set_memory.c:613
__change_page_attr_set_clr+0x113a/0x11c0
Modules linked in: xt_physdev
On Tue, Jan 23, 2024 at 3:17 AM Jan Beulich wrote:
>
> On 22.01.2024 20:09, Jason Andryuk wrote:
> > When HWP is active, the cpufreq P-state information is not updated. In
> > that case, return -ENODEV instead of bogus, incomplete info. The xenpm
> > command already supports skipping results
shutdown_pirq and startup_pirq are not taking the
irq_mapping_update_lock because they can't due to lock inversion. Both
are called with the irq_desc->lock being taking. The lock order,
however, is first irq_mapping_update_lock and then irq_desc->lock.
This opens multiple races:
- shutdown_pirq
On 24/01/2024 3:27 pm, Jan Beulich wrote:
> ... if available only, of course.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -406,9 +406,15 @@ void __init early_cpu_init(bool verbose)
> paddr_bits -= (ebx >> 6) & 0x3f;
>
On 24/01/2024 3:21 pm, Jan Beulich wrote:
> Observing
>
> "Testing NMI watchdog on all CPUs: 0 stuck"
>
> it felt like it's not quite right, but I still read it as "no CPU stuck;
> all good", when really the system suffered from what 6bdb965178bb
> ("x86/intel: ensure Global Performance Counter
On Wed, Jan 24, 2024 at 04:21:24PM +0100, Jan Beulich wrote:
> Observing
>
> "Testing NMI watchdog on all CPUs: 0 stuck"
>
> it felt like it's not quite right, but I still read it as "no CPU stuck;
> all good", when really the system suffered from what 6bdb965178bb
> ("x86/intel: ensure Global
cr4_pv32_restore() needs two registers. Right now, it spills %rdx and
clobbers %rax.
However, %rcx is free to use at all callsites. Annotate CR4_PV32_RESTORE with
our usual clobber comments, and swap %rdx for %rcx in the non-fatal paths
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC:
On 24/01/2024 3:23 pm, Jan Beulich wrote:
> Now that we have %r14 set up using GET_STACK_END() in a number of
> places, in two places we can eliminate the redundancy of GET_CURRENT()
> also invoking that macro. In handle_ist_exception() actually go a step
> farther and avoid using %rbx altogether
On 24.01.2024 16:33, Oleksii wrote:
> On Wed, 2024-01-24 at 12:27 +0100, Jan Beulich wrote:
>> On 24.01.2024 11:12, Oleksii wrote:
>>> On Wed, 2024-01-24 at 09:19 +0100, Jan Beulich wrote:
On 23.01.2024 18:08, Oleksii wrote:
> On Tue, 2024-01-23 at 12:39 +0100, Jan Beulich wrote:
>>
On 23.01.2024 21:59, Andrew Cooper wrote:
> Always run microcode_update_helper() on the BSP, so the the updated Raw CPU
> policy doesn't get non-BSP topology details included.
Wouldn't it be better (and consistent with ...
> Have calculate_raw_cpu_policy() clear the instantanious XSTATE sizes.
On Wed, 2024-01-24 at 12:27 +0100, Jan Beulich wrote:
> On 24.01.2024 11:12, Oleksii wrote:
> > On Wed, 2024-01-24 at 09:19 +0100, Jan Beulich wrote:
> > > On 23.01.2024 18:08, Oleksii wrote:
> > > > On Tue, 2024-01-23 at 12:39 +0100, Jan Beulich wrote:
> > > > > On 22.12.2023 16:13, Oleksii
On 24.01.2024 16:04, Oleksii wrote:
> On Wed, 2024-01-24 at 12:24 +0100, Jan Beulich wrote:
>> On 24.01.2024 10:34, Oleksii wrote:
>>> On Tue, 2024-01-23 at 14:37 +0100, Jan Beulich wrote:
On 23.01.2024 13:34, Oleksii wrote:
> On Tue, 2024-01-23 at 12:14 +0100, Jan Beulich wrote:
>>
... if available only, of course.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -406,9 +406,15 @@ void __init early_cpu_init(bool verbose)
paddr_bits -= (ebx >> 6) & 0x3f;
}
- if (!(c->x86_vendor & (X86_VENDOR_AMD |
Now that we have %r14 set up using GET_STACK_END() in a number of
places, in two places we can eliminate the redundancy of GET_CURRENT()
also invoking that macro. In handle_ist_exception() actually go a step
farther and avoid using %rbx altogether when retrieving the processor
ID: Obtain the
Observing
"Testing NMI watchdog on all CPUs: 0 stuck"
it felt like it's not quite right, but I still read it as "no CPU stuck;
all good", when really the system suffered from what 6bdb965178bb
("x86/intel: ensure Global Performance Counter Control is setup
correctly") works around. Convert this
On Wed, Jan 24, 2024 at 08:23:15AM +0100, Jan Beulich wrote:
> On 23.01.2024 23:52, Elliott Mitchell wrote:
> > On Tue, Jan 23, 2024 at 11:44:03AM +0100, Jan Beulich wrote:
> >> On 22.01.2024 21:53, Elliott Mitchell wrote:
> >>
> >>> I find the present handling of MCE in Xen an odd choice. Having
On Wed, 2024-01-24 at 12:24 +0100, Jan Beulich wrote:
> On 24.01.2024 10:34, Oleksii wrote:
> > On Tue, 2024-01-23 at 14:37 +0100, Jan Beulich wrote:
> > > On 23.01.2024 13:34, Oleksii wrote:
> > > > On Tue, 2024-01-23 at 12:14 +0100, Jan Beulich wrote:
> > > > > On 22.12.2023 16:13, Oleksii
On Wed, 2024-01-24 at 12:19 +0100, Jan Beulich wrote:
> On 24.01.2024 10:23, Oleksii wrote:
> > On Tue, 2024-01-23 at 14:30 +0100, Jan Beulich wrote:
> > > On 23.01.2024 13:24, Oleksii wrote:
> > > > On Tue, 2024-01-23 at 11:30 +0100, Jan Beulich wrote:
> > > > > On 23.01.2024 11:21, Oleksii
From: Oleksandr Tyshchenko
[ Upstream commit 2d2db7d40254d5fb53b11ebd703cd1ed0c5de7a1 ]
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately,
From: Oleksandr Tyshchenko
[ Upstream commit 2d2db7d40254d5fb53b11ebd703cd1ed0c5de7a1 ]
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately,
From: Oleksandr Tyshchenko
[ Upstream commit 2d2db7d40254d5fb53b11ebd703cd1ed0c5de7a1 ]
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately,
From: Oleksandr Tyshchenko
[ Upstream commit 2d2db7d40254d5fb53b11ebd703cd1ed0c5de7a1 ]
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately,
From: Oleksandr Tyshchenko
[ Upstream commit 2d2db7d40254d5fb53b11ebd703cd1ed0c5de7a1 ]
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately,
On Tue, 2024-01-23 at 08:34 +0100, Jan Beulich wrote:
> On 22.01.2024 23:47, Stefano Stabellini wrote:
> > On Mon, 22 Jan 2024, Jan Beulich wrote:
> > > What definitely needs clarifying is what "review" is: Are R-b tags
> > > counted, or is it the number of replies sent commenting on patches?
> >
- AB
Hi Jan,
Please see my reply to the points below
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Mon, Jan 22, 2024 at 10:32 AM Jan Beulich wrote:
> On 17.01.2024 18:10, Kelly Choi wrote:
> > Hi everyone,
> >
> > I've spent a bit of time talking to various individuals and the
On 14/1/24 13:25, Michael S. Tsirkin wrote:
On Sun, Jan 14, 2024 at 12:21:59PM +, Bernhard Beschow wrote:
Am 7. Januar 2024 23:16:23 UTC schrieb Bernhard Beschow :
This is a follow-up on commit 89965db43cce "hw/isa/piix3: Avoid Xen-specific
variant of piix3_write_config()" which
flight 184443 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184443/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184432
test-amd64-amd64-xl-qemut-win7-amd64
Hi,
On 14/01/2024 10:01, Mykyta Poturai wrote:
Add the vgic_its_trigger_msi() function to the vgic interface. This
function allows to inject MSIs from the Hypervisor to the guest.
Which is useful for userspace PCI backend drivers.
Signed-off-by: Mykyta Poturai
---
On 24.01.2024 10:24, Roger Pau Monné wrote:
> On Wed, Jan 24, 2024 at 09:48:35AM +0100, Jan Beulich wrote:
>> On 23.01.2024 16:07, Roger Pau Monné wrote:
>>> On Tue, Jan 23, 2024 at 03:32:12PM +0100, Jan Beulich wrote:
On 15.01.2024 20:43, Stewart Hildebrand wrote:
> @@ -2888,6 +2888,8 @@
On 24.01.2024 11:12, Oleksii wrote:
> On Wed, 2024-01-24 at 09:19 +0100, Jan Beulich wrote:
>> On 23.01.2024 18:08, Oleksii wrote:
>>> On Tue, 2024-01-23 at 12:39 +0100, Jan Beulich wrote:
On 22.12.2023 16:13, Oleksii Kurochko wrote:
> @@ -53,6 +56,18 @@ struct cpu_user_regs
>
Hi,
On 14/01/2024 10:01, Mykyta Poturai wrote:
This series adds the base support for MSI injection on Arm. This is
needed to streamline virtio-pci interrupt triggering.
With this patches, MSIs can be triggered in guests by issuing the new
DM op, inject_msi2. This op is similar to inject_msi,
On 24.01.2024 10:34, Oleksii wrote:
> On Tue, 2024-01-23 at 14:37 +0100, Jan Beulich wrote:
>> On 23.01.2024 13:34, Oleksii wrote:
>>> On Tue, 2024-01-23 at 12:14 +0100, Jan Beulich wrote:
On 22.12.2023 16:13, Oleksii Kurochko wrote:
> --- a/xen/common/Kconfig
> +++
Hi,
On 24/01/2024 01:17, Stefano Stabellini wrote:
On Sun, 14 Jan 2024, Mykyta Poturai wrote:
Add the vgic_its_trigger_msi() function to the vgic interface. This
function allows to inject MSIs from the Hypervisor to the guest.
Which is useful for userspace PCI backend drivers.
Signed-off-by:
On 24.01.2024 10:23, Oleksii wrote:
> On Tue, 2024-01-23 at 14:30 +0100, Jan Beulich wrote:
>> On 23.01.2024 13:24, Oleksii wrote:
>>> On Tue, 2024-01-23 at 11:30 +0100, Jan Beulich wrote:
On 23.01.2024 11:21, Oleksii wrote:
> On Mon, 2024-01-22 at 17:56 +0100, Jan Beulich wrote:
>>
flight 184448 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184448/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 97e1ef87300cdf01f5b21cd4c5ee1d8df6ae1f39
baseline version:
ovmf
On 1/22/2024 11:06, Sébastien Chaumat wrote:
Le mer. 17 janv. 2024 à 03:20, Mario Limonciello
mailto:mario.limoncie...@amd.com>> a écrit :
On 1/16/2024 10:18, Jan Beulich wrote:
> On 16.01.2024 16:52, Sébastien Chaumat wrote:
>> Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat
> Subject: Re: [PATCH] xen: Drop out of coroutine context
> xen_invalidate_map_cache_entry
>
> On Tue, 16 Jan 2024, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > xen_invalidate_map_cache_entry is not expected to run in a coroutine.
> > Without this, there is crash:
> >
> >
On Wed, Jan 24, 2024 at 8:45 AM Roger Pau Monne wrote:
>
> The MMIO RO rangeset overlap check is bogus: the rangeset is inclusive so the
> passed end mfn should be the last mfn to be mapped (not last + 1).
>
> Fixes: 6fa1755644d0 ('amd/npt/shadow: replace assert that prevents creating
> 2M/1G
On Wed, 2024-01-24 at 09:19 +0100, Jan Beulich wrote:
> On 23.01.2024 18:08, Oleksii wrote:
> > On Tue, 2024-01-23 at 12:39 +0100, Jan Beulich wrote:
> > > On 22.12.2023 16:13, Oleksii Kurochko wrote:
> > > > Signed-off-by: Oleksii Kurochko
> > > > ---
> > > > Changes in V3:
> > > > - Update the
On Wed, 2024-01-24 at 09:09 +0100, Jan Beulich wrote:
> On 23.01.2024 17:54, Oleksii wrote:
> > On Tue, 2024-01-23 at 12:36 +0100, Jan Beulich wrote:
> > > On 22.12.2023 16:13, Oleksii Kurochko wrote:
> > > > Signed-off-by: Oleksii Kurochko
> > > > Acked-by: Jan Beulich
> > > > ---
> > > >
On Wed, 2024-01-24 at 09:07 +0100, Jan Beulich wrote:
> On 23.01.2024 17:50, Oleksii wrote:
> > On Tue, 2024-01-23 at 12:32 +0100, Jan Beulich wrote:
> > > On 22.12.2023 16:13, Oleksii Kurochko wrote:
> > > > @@ -22,25 +30,56 @@
> > > > *
> > > > * It means that:
> > > > * top VA bits are
On Wed, Jan 24, 2024 at 09:56:42AM +0100, Jan Beulich wrote:
> On 23.01.2024 16:23, Roger Pau Monné wrote:
> > On Tue, Jan 23, 2024 at 03:26:26PM +0100, Jan Beulich wrote:
> >> On 15.01.2024 20:43, Stewart Hildebrand wrote:
> >>> --- a/xen/arch/x86/hvm/vmsi.c
> >>> +++ b/xen/arch/x86/hvm/vmsi.c
>
On Tue, 2024-01-23 at 14:37 +0100, Jan Beulich wrote:
> On 23.01.2024 13:34, Oleksii wrote:
> > On Tue, 2024-01-23 at 12:14 +0100, Jan Beulich wrote:
> > > On 22.12.2023 16:13, Oleksii Kurochko wrote:
> > > > --- a/xen/common/Kconfig
> > > > +++ b/xen/common/Kconfig
> > > > @@ -47,6 +47,9 @@
On Wed, Jan 24, 2024 at 09:48:35AM +0100, Jan Beulich wrote:
> On 23.01.2024 16:07, Roger Pau Monné wrote:
> > On Tue, Jan 23, 2024 at 03:32:12PM +0100, Jan Beulich wrote:
> >> On 15.01.2024 20:43, Stewart Hildebrand wrote:
> >>> @@ -2888,6 +2888,8 @@ int allocate_and_map_msi_pirq(struct domain
On Tue, 2024-01-23 at 14:30 +0100, Jan Beulich wrote:
> On 23.01.2024 13:24, Oleksii wrote:
> > On Tue, 2024-01-23 at 11:30 +0100, Jan Beulich wrote:
> > > On 23.01.2024 11:21, Oleksii wrote:
> > > > On Mon, 2024-01-22 at 17:56 +0100, Jan Beulich wrote:
> > > > > On 22.12.2023 16:12, Oleksii
On Tue, Jan 23, 2024 at 02:43:15PM +0100, Jan Beulich wrote:
> On 23.01.2024 14:37, Roger Pau Monné wrote:
> > On Tue, Jan 23, 2024 at 10:22:10AM +0100, Jan Beulich wrote:
> >> On 22.01.2024 19:17, Andrew Cooper wrote:
> >>> It is bad form to have inter-function fallthrough. It only functions
>
On Mon, Jan 22, 2024 at 06:17:14PM +, Andrew Cooper wrote:
> Each of these symbols are local to their main function. By not having them
> globally visible, livepatch's binary diffing logic can reason about the
> functions properly.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
>
On Tue, 2024-01-23 at 14:27 +0100, Jan Beulich wrote:
> On 23.01.2024 13:18, Oleksii wrote:
> > On Tue, 2024-01-23 at 11:28 +0100, Jan Beulich wrote:
> > > On 23.01.2024 11:15, Oleksii wrote:
> > > > On Mon, 2024-01-22 at 17:27 +0100, Jan Beulich wrote:
> > > > > On 22.12.2023 16:12, Oleksii
On 23.01.2024 16:23, Roger Pau Monné wrote:
> On Tue, Jan 23, 2024 at 03:26:26PM +0100, Jan Beulich wrote:
>> On 15.01.2024 20:43, Stewart Hildebrand wrote:
>>> --- a/xen/arch/x86/hvm/vmsi.c
>>> +++ b/xen/arch/x86/hvm/vmsi.c
>>> @@ -468,7 +468,7 @@ int msixtbl_pt_register(struct domain *d, struct
On 24.01.2024 06:07, Stewart Hildebrand wrote:
> On 1/23/24 09:29, Jan Beulich wrote:
>> On 15.01.2024 20:43, Stewart Hildebrand wrote:
>>> @@ -1043,11 +1043,11 @@ static int __pci_enable_msix(struct pci_dev *pdev,
>>> struct msi_info *msi,
>>> {
>>> struct msi_desc *old_desc;
>>>
>>> -
flight 184434 xen-unstable real [real]
flight 184447 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184434/
http://logs.test-lab.xenproject.org/osstest/logs/184447/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 23.01.2024 16:07, Roger Pau Monné wrote:
> On Tue, Jan 23, 2024 at 03:32:12PM +0100, Jan Beulich wrote:
>> On 15.01.2024 20:43, Stewart Hildebrand wrote:
>>> @@ -2888,6 +2888,8 @@ int allocate_and_map_msi_pirq(struct domain *d, int
>>> index, int *pirq_p,
>>> {
>>> int irq, pirq, ret;
The MMIO RO rangeset overlap check is bogus: the rangeset is inclusive so the
passed end mfn should be the last mfn to be mapped (not last + 1).
Fixes: 6fa1755644d0 ('amd/npt/shadow: replace assert that prevents creating
2M/1G MMIO entries')
Signed-off-by: Roger Pau Monné
---
On 24.01.2024 09:20, Federico Serafini wrote:
> On 22/01/24 15:02, Jan Beulich wrote:
>> On 22.01.2024 14:48, Federico Serafini wrote:
>>> --- a/xen/include/xen/compiler.h
>>> +++ b/xen/include/xen/compiler.h
>>> @@ -64,6 +64,14 @@
>>> # define fallthroughdo {} while (0) /* fallthrough
flight 184446 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184446/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d24187a81f724fc2af4f739ad92a9b158c9254df
baseline version:
ovmf
On Tue, Jan 23, 2024 at 08:27:18PM -0500, Patrick Plenefisch wrote:
> On Sat, Jan 20, 2024 at 8:33 PM Patrick Plenefisch
> wrote:
>
> >
> >
> > On Fri, Jan 19, 2024 at 6:06 AM Roger Pau Monné
> > wrote:
> >
> >> On Fri, Jan 19, 2024 at 02:44:35AM -0500, Patrick Plenefisch wrote:
> >> > On Thu,
On 23.01.2024 18:27, Oleksii wrote:
> On Tue, 2024-01-23 at 14:03 +0100, Jan Beulich wrote:
>> On 22.12.2023 16:13, Oleksii Kurochko wrote:
>>> +#define _PGC_extra PG_shift(10)
>>> +#define PGC_extra PG_mask(1, 10)
>>> +
>>> +#define is_xen_heap_page(page) ((page)->count_info &
On Wed, Jan 24, 2024 at 12:07:28AM -0500, Stewart Hildebrand wrote:
> On 1/23/24 09:29, Jan Beulich wrote:
> > On 15.01.2024 20:43, Stewart Hildebrand wrote:
> >> @@ -1043,11 +1043,11 @@ static int __pci_enable_msix(struct pci_dev *pdev,
> >> struct msi_info *msi,
> >> {
> >> struct
On 22/01/24 15:02, Jan Beulich wrote:
On 22.01.2024 14:48, Federico Serafini wrote:
Introduce macro static_asser_unreachable() to check that a program
point is considered unreachable by the static analysis performed by the
compiler, even at optimization level -O0.
Is it really intended to
On 23.01.2024 18:08, Oleksii wrote:
> On Tue, 2024-01-23 at 12:39 +0100, Jan Beulich wrote:
>> On 22.12.2023 16:13, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>> ---
>>> Changes in V3:
>>> - Update the commit message
>>
>> ??? (again)
> The same as with previous.
On 23.01.2024 17:54, Oleksii wrote:
> On Tue, 2024-01-23 at 12:36 +0100, Jan Beulich wrote:
>> On 22.12.2023 16:13, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>> Acked-by: Jan Beulich
>>> ---
>>> Changes in V3:
>>> - update the commit message
>>
>> Once again I find this
On 23.01.2024 17:50, Oleksii wrote:
> On Tue, 2024-01-23 at 12:32 +0100, Jan Beulich wrote:
>> On 22.12.2023 16:13, Oleksii Kurochko wrote:
>>> @@ -22,25 +30,56 @@
>>> *
>>> * It means that:
>>> * top VA bits are simply ignored for the purpose of translating
>>> to PA.
>>> +#endif
>>> *
86 matches
Mail list logo
