On 13.11.2024 00:46, Andrew Cooper wrote:
> On 12/11/2024 2:59 pm, Jan Beulich wrote:
>> Apparently I blindly copied the constants from the BEXTR case, where SF
>> indeed wants leaving out. For BLSI, BLSMSK, BLSR, and BZHI SF is
>> defined, and hence wants checking. This is noticable in particular
Hi Jan,
It is challenging to create a solution that satisfies everyone for this
patch. However, we should add R8.3 to the clean list as soon as possible
to enable rule blocking in GitLab-CI. Failing to do so risks introducing
regressions, as recently occurred, undoing the significant efforts made
On Tue, 12 Nov 2024, Julien Grall wrote:
> Hi,
>
> On 12/11/2024 16:00, Stewart Hildebrand wrote:
> > On 11/12/24 08:00, Jan Beulich wrote:
> > > All,
> > >
> > > the release is due by the end of the month. Please point out backports you
> > > find
> > > missing from the respective staging branch
On Tue, 12 Nov 2024, Andrew Cooper wrote:
> The work to address Rule 5.3 introduced violations of Rule 8.3 by failing to
> rename the parameters in the declaration.
>
> Fixes: b5fd405aa381 ("x86/e820 address violations of MISRA C:2012 Rule 5.3")
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefan
On Tue, 11 Nov 2024, Andrew Cooper wrote:
> This resolves 4 Misra violations of Rule 8.4 caused by the function
> definitions not being able to see their declarations.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Stefan
On 12/11/2024 3:00 pm, Jan Beulich wrote:
> While result values and other status flags are unaffected as long as we
> can ignore the case of registers having their upper 32 bits non-zero
> outside of 64-bit mode, EFLAGS.SF may obtain a wrong value when we
> mistakenly re-execute the original insn w
On 12/11/2024 2:59 pm, Jan Beulich wrote:
> Apparently I blindly copied the constants from the BEXTR case, where SF
> indeed wants leaving out. For BLSI, BLSMSK, BLSR, and BZHI SF is
> defined, and hence wants checking. This is noticable in particular for
> BLSR, where with the input we use SF will
This resolves 4 Misra violations of Rule 8.4 caused by the function
definitions not being able to see their declarations.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: consult...@bugseng.com
---
xen/arch/x86/genapic/delivery.c | 3 ++-
1 file
The work to address Rule 5.3 introduced violations of Rule 8.3 by failing to
rename the parameters in the declaration.
Fixes: b5fd405aa381 ("x86/e820 address violations of MISRA C:2012 Rule 5.3")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Al
Introduce PV<->VF links and fix a regressiong related to a locking
change.
Stewart Hildebrand (2):
xen/pci: introduce PF<->VF links
x86/msi: fix locking for SR-IOV devices
xen/arch/x86/msi.c| 36 ---
xen/drivers/passthrough/pci.c | 82 +++--
With the tangle of logic starting to come under control, it is now plain to
see that parse_blob()'s side effect of re-gathering the signature/revision is
pointless.
The cpu_request_microcode() hooks need the signature only. The BSP gathers
this in early_microcode_init(), the APs and S3 in microco
All uses of MIS_UCODE, have been removed, leaving only a simple ordering
relation, and microcode_match_result being a stale name.
Drop the enum entirely, and use a simple int -1/0/1 scheme like other standard
ordering primitives in C.
Swap the order or parameters to compare_patch(), to reduce cog
microcode_update_cache() now has a single caller, but inlining it shows how
unnecessarily complicated the logic really is.
Outside of error paths, there is always one microcode patch to free. Its
either result of parse_blob(), or it's the old cached value.
In order to fix this, have a local patc
Remains of the previous patches, posted as a single series.
Andrew Cooper (3):
x86/ucode: Remove the collect_cpu_info() call from parse_blob()
x86/ucode: Fix cache handling in microcode_update_helper()
x86/ucode: Drop MIS_UCODE and microcode_match_result
xen/arch/x86/cpu/microcode/amd.c
Add links between a VF's struct pci_dev and its associated PF struct
pci_dev.
The hardware domain is expected to add a PF first before adding
associated VFs. Similarly, the hardware domain is expected to remove the
associated VFs before removing the PF. If adding/removing happens out of
order, pri
In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
structure") a lock was moved from allocate_and_map_msi_pirq() to the
caller and changed from pcidevs_lock() to read_lock(&d->pci_lock).
However, one call path wasn't updated to reflect the change, leading to
a failed assertion o
On October 18, 2024 Ayan Kumar Halder wrote:
> From: Michal Orzel
>
> Add requirements for dom0less domain creation.
>
> Signed-off-by: Michal Orzel
> Signed-off-by: Ayan Kumar Halder
> ---
Reviewed-by: Artem Mygaiev
Minor: in lines like
- Xen shall assign multiple vCPUs to a domain
- Xen
On 12/11/2024 5:17 pm, Demi Marie Obenour wrote:
> On Tue, Nov 12, 2024 at 12:05:47PM +, Xen Security wrote:
>> Only PVH guests can leverage the vulnerability. HVM and PV guests
>> cannot leverage the vulnerability. Note that PV guests when run inside
>> the (PVH) shim can't leverage the vuln
On 11/12/24 04:39, Jan Beulich wrote:
> On 12.11.2024 10:02, Roger Pau Monné wrote:
>> On Mon, Nov 11, 2024 at 03:07:28PM -0500, Stewart Hildebrand wrote:
>>> On 10/28/24 14:41, Roger Pau Monné wrote:
if ( !pdev->info.is_virtfn && !list_empty(&pdev->vf_list) )
{
struct pci_dev *v
This xtf test tests a bug to hardware IO port breakpoints fixed by
08aacc392d86 ("x86/emul: Fix misaligned IO breakpoint behaviour in PV guests")
Signed-off-by: Matthew Barnes
---
docs/all-tests.dox | 2 +
tests/misaligned-io-breakpoints/Makefile | 9 +
tests/misaligned
On Tue, Nov 12, 2024 at 12:05:47PM +, Xen Security wrote:
> Only PVH guests can leverage the vulnerability. HVM and PV guests
> cannot leverage the vulnerability. Note that PV guests when run inside
> the (PVH) shim can't leverage the vulnerability.
Is this unconditional (perhaps because the
Hi,
On 12/11/2024 16:00, Stewart Hildebrand wrote:
On 11/12/24 08:00, Jan Beulich wrote:
All,
the release is due by the end of the month. Please point out backports you find
missing from the respective staging branch, but which you consider relevant.
Advance notice: 4.18.4 ought to follow abo
Hello everyone,
This email only tracks big items for xen.git tree. Please reply for items
you
would like to see in 4.20 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
---
On 11/12/24 08:00, Jan Beulich wrote:
> All,
>
> the release is due by the end of the month. Please point out backports you
> find
> missing from the respective staging branch, but which you consider relevant.
>
> Advance notice: 4.18.4 ought to follow about two weeks later.
>
> Jan
>
Looking
While result values and other status flags are unaffected as long as we
can ignore the case of registers having their upper 32 bits non-zero
outside of 64-bit mode, EFLAGS.SF may obtain a wrong value when we
mistakenly re-execute the original insn with VEX.W set.
Note that the memory access, if an
Apparently I blindly copied the constants from the BEXTR case, where SF
indeed wants leaving out. For BLSI, BLSMSK, BLSR, and BZHI SF is
defined, and hence wants checking. This is noticable in particular for
BLSR, where with the input we use SF will be set in the result (and
hence is being switched
1: correct EFLAGS testing for BMI1/BMI2
2: ignore VEX.W for BMI{1,2} insns in 32-bit mode
Jan
All,
the release is due by the end of the month. Please point out backports you find
missing from the respective staging branch, but which you consider relevant.
Advance notice: 4.18.4 ought to follow about two weeks later.
Jan
On 12.11.2024 13:55, Andrew Cooper wrote:
> On 12/11/2024 10:45 am, Jan Beulich wrote:
>> On 07.11.2024 13:21, Andrew Cooper wrote:
>>> Fold microcode_update_cpu() into its single remaining caller and simplify
>>> the
>>> logic by removing the patch != NULL path with microcode_mutex held.
>>>
>>>
On 12/11/2024 10:45 am, Jan Beulich wrote:
> On 07.11.2024 13:21, Andrew Cooper wrote:
>> Fold microcode_update_cpu() into its single remaining caller and simplify the
>> logic by removing the patch != NULL path with microcode_mutex held.
>>
>> Explain why we bother grabbing the microcode revision
On 06/11/24 12:22, Jan Beulich wrote:
On 06.11.2024 10:04, Federico Serafini wrote:
The pseudo keyword fallthrough shall be used to make explicit the
fallthrough intention at the end of a case statement (doing this
through comments is deprecated).
Signed-off-by: Federico Serafini
---
xen/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2024-45819 / XSA-464
version 2
libxl leaks data to PVH guests via ACPI tables
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
===
On Mon, Nov 11, 2024 at 12:21:32PM +, Mykyta Poturai wrote:
> On 06.11.24 16:57, Roger Pau Monné wrote:
> >
> > Let's try to figure out what causes msi_maxvec to be 0 in your case
> > and then we can see how to better detect this. If msi_maxvec needs to
> > be checked it should likely be done
On 11.11.2024 19:16, Oleksii Kurochko wrote:
> @@ -25,8 +27,11 @@
>
> static inline void *maddr_to_virt(paddr_t ma)
> {
> -BUG_ON("unimplemented");
> -return NULL;
> +unsigned long va_offset = maddr_to_directmapoff(ma);
> +
> +ASSERT(va_offset < DIRECTMAP_SIZE);
Much like with
On 12.11.2024 11:57, Andrew Cooper wrote:
> On 12/11/2024 10:49 am, Jan Beulich wrote:
>> On 12.11.2024 11:36, Andrew Cooper wrote:
>>> On 07/11/2024 9:58 pm, Andrew Cooper wrote:
On 07/11/2024 12:21 pm, Andrew Cooper wrote:
> With the tangle of logic starting to come under control, it is
On 08.11.2024 15:42, Andrew Cooper wrote:
> This function is overloaded, creating complexity; 3 of 4 callers already only
> want it for it's "applicable to this CPU or not" answer, and handle revision
> calculations separately.
>
> Change it to be microcode_fits_cpu(), returning a simple boolean.
On 12/11/2024 10:49 am, Jan Beulich wrote:
> On 12.11.2024 11:36, Andrew Cooper wrote:
>> On 07/11/2024 9:58 pm, Andrew Cooper wrote:
>>> On 07/11/2024 12:21 pm, Andrew Cooper wrote:
With the tangle of logic starting to come under control, it is now plain to
see that parse_blob()'s side e
On 08.11.2024 15:42, Andrew Cooper wrote:
> This function is overloaded, creating complexity; 3 of 4 callers already only
> want it for it's "applicable to this CPU or not" answer, and handle revision
> calculations separately.
>
> Change it to be microcode_fits_cpu(), returning a simple boolean.
On 12.11.2024 11:36, Andrew Cooper wrote:
> On 07/11/2024 9:58 pm, Andrew Cooper wrote:
>> On 07/11/2024 12:21 pm, Andrew Cooper wrote:
>>> With the tangle of logic starting to come under control, it is now plain to
>>> see that parse_blob()'s side effect of re-gathering the signature/revision
>>>
On 07.11.2024 13:21, Andrew Cooper wrote:
> Fold microcode_update_cpu() into its single remaining caller and simplify the
> logic by removing the patch != NULL path with microcode_mutex held.
>
> Explain why we bother grabbing the microcode revision even if we can't load
> microcode.
>
> Furtherm
On 07/11/2024 9:58 pm, Andrew Cooper wrote:
> On 07/11/2024 12:21 pm, Andrew Cooper wrote:
>> With the tangle of logic starting to come under control, it is now plain to
>> see that parse_blob()'s side effect of re-gathering the signature/revision is
>> pointless.
>>
>> The cpu_request_microcode()
On 07.11.2024 13:21, Andrew Cooper wrote:
> There are two callers of microcode_update_cpu(), and because one passes NULL
> and one doesn't, there are effectively two disjoint pieces of logic wrapped in
> a single function.
>
> early_microcode_load()'s use skips all the microcode_cache handling, an
On 11.11.2024 19:16, Oleksii Kurochko wrote:
> NOTE:
> I am not insisiting on having separate CONFIG_UART_INIT. If it would be fine
> just to have in xen/drivers/char/Makefile:
>obj-$(CONFIG_ARM) += uart-init.c
>obj-$(CONFIG_RISCV) += uart-init.c
With PPC also using DT, a 3rd instance w
On 11.11.2024 19:06, Ayan Kumar Halder wrote:
> As CONFIG_HAS_PASSTHROUGH is enabled only for MMU, thus any common code
> accessing iommu needs to be enclosed within CONFIG_HAS_PASSTHROUGH.
I'm not an Arm maintainer, so my opinion may not count much, but that's
quite a bit of #ifdef-ary. In at lea
On 11.11.2024 21:07, Stewart Hildebrand wrote:
> On 10/28/24 14:41, Roger Pau Monné wrote:
>> I see previous code also catered for VFs being added without the PF
>> being present, so I assume there was some need for this.
>
> This is exactly the source of the confusion on my part. In the removal
>
On 12.11.2024 10:02, Roger Pau Monné wrote:
> On Mon, Nov 11, 2024 at 03:07:28PM -0500, Stewart Hildebrand wrote:
>> On 10/28/24 14:41, Roger Pau Monné wrote:
>>> if ( !pdev->info.is_virtfn && !list_empty(&pdev->vf_list) )
>>> {
>>> struct pci_dev *vf_pdev;
>>>
>>> while ( (vf_pdev = list_f
On 12.11.2024 03:16, Stefano Stabellini wrote:
> On Mon, 11 Nov 2024, Jan Beulich wrote:
>> On 11.11.2024 03:24, Stefano Stabellini wrote:
>>> On Wed, 6 Nov 2024, Jan Beulich wrote:
On 06.11.2024 10:04, Federico Serafini wrote:
> The pseudo keyword fallthrough shall be used to make explici
On Mon, Nov 11, 2024 at 07:40:14AM +0100, Jan Beulich wrote:
> On 08.11.2024 17:29, Stewart Hildebrand wrote:
> > On 11/8/24 10:19, Roger Pau Monné wrote:
> >> On Fri, Nov 08, 2024 at 02:17:40PM +0100, Jan Beulich wrote:
> >>> On 08.11.2024 13:42, Alejandro Vallejo wrote:
> On Mon Nov 4, 2024
On Mon, Nov 11, 2024 at 03:07:28PM -0500, Stewart Hildebrand wrote:
> On 10/28/24 14:41, Roger Pau Monné wrote:
> > On Fri, Oct 18, 2024 at 04:39:09PM -0400, Stewart Hildebrand wrote:
> > IOW: shouldn't the PF
> > always be added first, so that SR-IOV can be enabled and the VFs added
> > afterwards
49 matches
Mail list logo
