On 2024-06-28 01:18, Stefano Stabellini wrote:
On Thu, 27 Jun 2024, Nicola Vetrini wrote:
The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
so the code below is only executed upon erroneously reaching that
program point and calling domain_crash, thus resulting in the
for loop aft
The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
so the code below is only executed upon erroneously reaching that
program point and calling domain_crash, thus resulting in the
for loop after 'out_unmap' to become unreachable in some configurations.
This is a defensive coding meas
On 28.06.2024 00:59, Stefano Stabellini wrote:
> On Thu, 27 Jun 2024, Jan Beulich wrote:
>> On 27.06.2024 03:53, Stefano Stabellini wrote:
>>> On Wed, 26 Jun 2024, Jan Beulich wrote:
On 26.06.2024 03:11, Stefano Stabellini wrote:
> On Tue, 25 Jun 2024, Jan Beulich wrote:
>> On 25.06.20
On Thu, Jun 27, 2024 at 04:02:59PM +, Michael Kelley wrote:
> > > Conceptually, it's still being used as a boolean function based on
> > > whether the return value is NULL. Renaming it to swiotlb_get_pool()
> > > more accurately describes the return value, but obscures the
> > > intent of dete
flight 186541 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186541/
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
flight 186532 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186532/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186445
test-amd64-amd64-xl-qemuu-win7-amd64 19
On Thu, Aug 26, 2021 at 09:51:54AM +0200, Jan Beulich wrote:
> On 26.08.2021 03:18, Elliott Mitchell wrote:
>
> > What you're writing about would be looking for bugs in development
> > branches.
>
> Very much so, in case there are issues left, or ones have got
> reintroduced. That's what the prim
I'm rather surprised it was so long before the next system restart.
Seems a quiet period as far as security updates go. Good news is I made
several new observations, but I don't know how valuable these are.
On Mon, May 13, 2024 at 10:44:59AM +0200, Roger Pau Monné wrote:
>
> Does booting with
On Thu, 27 Jun 2024, Nicola Vetrini wrote:
> The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
> so the code below is only executed upon erroneously reaching that
> program point and calling domain_crash, thus resulting in the
> for loop after 'out_unmap' to become unreachable in so
flight 186539 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186539/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a5f147b2a31c093cc83a3f10cdda529c6b59799b
baseline version:
ovmf 6862b9d538d9636363567
On Thu, 27 Jun 2024, Jan Beulich wrote:
> On 27.06.2024 03:53, Stefano Stabellini wrote:
> > On Wed, 26 Jun 2024, Jan Beulich wrote:
> >> On 26.06.2024 03:11, Stefano Stabellini wrote:
> >>> On Tue, 25 Jun 2024, Jan Beulich wrote:
> On 25.06.2024 02:54, Stefano Stabellini wrote:
> > On Mon
flight 186530 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186530/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 5 host-install broken REGR. vs. 186528
test-armhf-armhf-xl
flight 186536 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186536/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6862b9d538d96363635677198899e1669e591259
baseline version:
ovmf ae09721a65ab3294439f6
From: h...@lst.de Sent: Thursday, June 27, 2024 8:25 AM
>
> On Thu, Jun 27, 2024 at 02:59:03PM +, Michael Kelley wrote:
> > Conceptually, it's still being used as a boolean function based on
> > whether the return value is NULL. Renaming it to swiotlb_get_pool()
> > more accurately describes
On 2024-06-27 17:07, Jan Beulich wrote:
On 27.06.2024 15:46, GitLab wrote:
Pipeline #1350627221 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging
)
Commit: 402e4732 (
https://gitlab.com/xen-project/xen/-/
On Wed, Jun 26, 2024 at 11:46 AM Jan Beulich wrote:
>
> On 25.06.2024 18:23, Oleksii wrote:
> > On Tue, 2024-06-25 at 16:25 +0200, Jan Beulich wrote:
> >> On 25.06.2024 15:51, Oleksii Kurochko wrote:
> >>> During Gitlab CI randconfig job for RISC-V failed witn an error:
> >>> common/trace.c:57:22
On Thu, Jun 27, 2024 at 02:59:03PM +, Michael Kelley wrote:
> Conceptually, it's still being used as a boolean function based on
> whether the return value is NULL. Renaming it to swiotlb_get_pool()
> more accurately describes the return value, but obscures the
> intent of determining if it is
On 27.06.2024 14:08, oleksii.kuroc...@gmail.com wrote:
> I saw a message in the xen-devel channel:```
> erm... We've got a problem.
> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/7185148004
> very clearly failed with a panic(), but reported success out to Gitlab
> ```
> However, I cou
From: Petr Tesařík Sent: Thursday, June 27, 2024 12:21 AM
[...]
> > @@ -187,10 +169,13 @@ static inline bool is_swiotlb_buffer(struct device
> > *dev, phys_addr_t paddr)
> > * This barrier pairs with smp_mb() in swiotlb_find_slots().
> > */
> > smp_rmb();
> > - return READ_ONCE(
On 27.06.2024 15:46, GitLab wrote:
>
>
> Pipeline #1350627221 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/xen )
> Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
>
> Commit: 402e4732 (
> https://gitlab.com/xen-project/xen/-/commit/402e473249cf62dd4c6b
From: Petr Tesařík Sent: Wednesday, June 26, 2024 11:52 PM
>
> Oh, right. The idea is good, but I was not able to reply immediately
> and then forgot about it.
>
> For the record, I considered an alternative: Call swiotlb_* functions
> unconditionally and bail out early if the pool is NULL. But
On 27.06.2024 14:01, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-06-27 at 12:10 +0200, Jan Beulich wrote:
>> On 27.06.2024 11:58, oleksii.kuroc...@gmail.com wrote:
>>> On Thu, 2024-06-27 at 09:59 +0200, Jan Beulich wrote:
On 26.06.2024 19:27, oleksii.kuroc...@gmail.com wrote:
> On Wed
On 27.06.2024 14:02, Alejandro Vallejo wrote:
> On Thu Jun 27, 2024 at 10:42 AM BST, Jan Beulich wrote:
>> Plus what about a guest which was configured to have the CPUID bit for MTRRs
>> clear?
>> I think we ought to document this as not supported for PVH (we may
>
> By "this" do you mean PVH _mus
flight 186531 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186531/
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
On 27.06.2024 15:41, Vaishali Thakkar wrote:
> On 6/13/24 1:04 PM, Jan Beulich wrote:
>> On 24.05.2024 14:31, Vaishali Thakkar wrote:
>>> -void hvm_asid_flush_core(void)
>>> +void hvm_asid_flush_all(void)
>>> {
>>> -struct hvm_asid_data *data = &this_cpu(hvm_asid_data);
>>> +struct hvm_as
On Thu, 2024-06-27 at 14:01 +0100, Andrew Cooper wrote:
> xc_dom_alloc_segment() is passed a size in bytes, calculates a size
> in pages
> from it, then fills in the new segment information with a bytes value
> re-calculated from the number of pages.
>
> This causes the module information given to
On Thu, Jun 27, 2024 at 02:01:34PM +0100, Andrew Cooper wrote:
> xc_dom_alloc_segment() is passed a size in bytes, calculates a size in pages
> from it, then fills in the new segment information with a bytes value
> re-calculated from the number of pages.
>
> This causes the module information giv
On 6/13/24 1:04 PM, Jan Beulich wrote:
On 24.05.2024 14:31, Vaishali Thakkar wrote:
--- a/xen/arch/x86/hvm/asid.c
+++ b/xen/arch/x86/hvm/asid.c
@@ -27,8 +27,8 @@ boolean_param("asid", opt_asid_enabled);
* the TLB.
*
* Sketch of the Implementation:
- *
- * ASIDs are a CPU-local resource.
Hi Teddy,
You are actually on track with what I was thinking in this area which initially
gave me 2 main ideas:
1. Take the NOVA Microhypervisor (very small TCB at only 5K LOC) and try to get
QEMU or Bhyve integrated as the VMM which would require a huge amount of
development time. The Genode
xc_dom_alloc_segment() is passed a size in bytes, calculates a size in pages
from it, then fills in the new segment information with a bytes value
re-calculated from the number of pages.
This causes the module information given to the guest (MB, or PVH) to have
incorrect sizes; specifically, sizes
flight 186529 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186529/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186517
test-amd64-amd64-xl-qemut-win7-amd64
Hi Lonnie,
Le 27/06/2024 à 11:33, Lonnie Cumberland a écrit :
> I am working towards is to have
> everything as a RAM-based ultra-lightweight thin hypervisor. I looked
> over ACRN, the NOVA Microhypervisor (Headron, Beadrock Udo),
> Rust-Shyper, Bareflank-MicroV, and many other development effor
Hi，
I use u-boot, xen, qemu to boot domU, then execute "reboot" command in
domU, domU
will hang. Could someone know this issue and this feature is supported
or not. Thanks.
#hang
info
Welcome to SNPS Mini AArch64 by Bu
I saw a message in the xen-devel channel:```
erm... We've got a problem.
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/7185148004
very clearly failed with a panic(), but reported success out to Gitlab
```
However, I couldn't determine if this is related to the patches in this
series or
On Thu Jun 27, 2024 at 10:42 AM BST, Jan Beulich wrote:
> On 26.06.2024 18:28, Alejandro Vallejo wrote:
> > This greatly simplifies a later patch that makes use of HVM contexts to
> > upload
> > LAPIC data. The idea is to reuse MTRR setting procedure to avoid code
> > duplication. It's currently o
On 27/06/2024 12:32, Julien Grall wrote:
>
>
> On 27/06/2024 08:40, Michal Orzel wrote:
>> Hi Julien,
>>
>> On 26/06/2024 22:13, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 26/06/2024 09:04, Michal Orzel wrote:
Memory node probing is done as part of early_scan_node() that is cal
On Thu, 2024-06-27 at 12:10 +0200, Jan Beulich wrote:
> On 27.06.2024 11:58, oleksii.kuroc...@gmail.com wrote:
> > On Thu, 2024-06-27 at 09:59 +0200, Jan Beulich wrote:
> > > On 26.06.2024 19:27, oleksii.kuroc...@gmail.com wrote:
> > > > On Wed, 2024-06-26 at 10:31 +0200, Jan Beulich wrote:
> > > >
On Thu, 2024-06-27 at 11:32 +0100, Julien Grall wrote:
>
>
> On 27/06/2024 08:40, Michal Orzel wrote:
> > Hi Julien,
> >
> > On 26/06/2024 22:13, Julien Grall wrote:
> > >
> > >
> > > Hi Michal,
> > >
> > > On 26/06/2024 09:04, Michal Orzel wrote:
> > > > Memory node probing is done as part o
On 27.06.2024 02:46, Stefano Stabellini wrote:
> On Wed, 26 Jun 2024, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ens
On 27/06/2024 08:40, Michal Orzel wrote:
Hi Julien,
On 26/06/2024 22:13, Julien Grall wrote:
Hi Michal,
On 26/06/2024 09:04, Michal Orzel wrote:
Memory node probing is done as part of early_scan_node() that is called
for each node with depth >= 1 (root node is at depth 0). According to
D
On 27.06.2024 11:58, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-06-27 at 09:59 +0200, Jan Beulich wrote:
>> On 26.06.2024 19:27, oleksii.kuroc...@gmail.com wrote:
>>> On Wed, 2024-06-26 at 10:31 +0200, Jan Beulich wrote:
On 25.06.2024 15:51, Oleksii Kurochko wrote:
> --- /dev/null
>>
On Wed, 2024-06-19 at 20:10 +0100, Andrew Cooper wrote:
> AMD have updated the SRSO whitepaper[1] with further information.
>
> There's a new SRSO_U/S_NO enumeration saying that SRSO attacks can't
> cross the
> user/supervisor boundary. i.e. Xen don't need to use IBPB-on-entry
> for PV.
>
> Ther
On Thu, 2024-06-27 at 09:59 +0200, Jan Beulich wrote:
> On 26.06.2024 19:27, oleksii.kuroc...@gmail.com wrote:
> > On Wed, 2024-06-26 at 10:31 +0200, Jan Beulich wrote:
> > > On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/arch/riscv/include/asm/bitops.h
> > > >
On Wed, 2024-06-26 at 10:04 +0200, Michal Orzel wrote:
> Memory node probing is done as part of early_scan_node() that is
> called
> for each node with depth >= 1 (root node is at depth 0). According to
> Devicetree Specification v0.4, chapter 3.4, /memory node can only
> exists
> as a top level no
On Wed, 2024-06-26 at 17:43 +0100, Andrew Cooper wrote:
> On 26/06/2024 5:28 pm, Alejandro Vallejo wrote:
> > hvmloader's cpuid() implementation deviates from Xen's in that the
> > value passed
> > on ecx is unspecified. This means that when used on leaves that
> > implement
> > subleaves it's unsp
On Wed, 2024-06-26 at 17:37 -0700, Stefano Stabellini wrote:
> On Wed, 26 Jun 2024, Federico Serafini wrote:
> > On 26/06/24 09:37, Oleksii wrote:
> > > On Tue, 2024-06-25 at 18:59 -0700, Stefano Stabellini wrote:
> > > > > +-doc_begin="The conversion from a function pointer to
> > > > > unsigned
>
On Wed, 2024-06-26 at 17:41 -0700, Stefano Stabellini wrote:
> On Wed, 26 Jun 2024, Federico Serafini wrote:
> > Update ECLAIR configuration to take into account the deviations
> > agreed during the MISRA meetings.
> >
> > While doing this, remove the obsolete "Set [123]" comments.
> >
> > Signed
On Mon, 2024-06-24 at 17:47 -0700, Stefano Stabellini wrote:
> Hi Oleksii,
>
> I would like to ask for a release-ack as the patch series makes very
> few
> changes outside of the static analysis configuration. The few changes
> to
> the Xen code are very limited, straightforward and makes the code
On 26.06.2024 18:28, Alejandro Vallejo wrote:
> This greatly simplifies a later patch that makes use of HVM contexts to upload
> LAPIC data. The idea is to reuse MTRR setting procedure to avoid code
> duplication. It's currently only used for PVH, but there's no real reason to
> overcomplicate the
Thanks for your suggestions and information as I will definitely look
into these more.
I have a very brief introduction to Dom0less and it is definitely
something of interest for me to review as well.
On the QubesOS side, I also read up a little on it and while it has a
number of similariti
The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
so the code below is only executed upon erroneously reaching that
program point and calling domain_crash, thus resulting in the
for loop after 'out_unmap' to become unreachable in some configurations.
This is a defensive coding meas
On 26.06.2024 18:16, Milan Djokic wrote:
>> Signed-off-by: Nikola Jelic
>
> This isn't you, is it? Your S-o-b is going to be needed, too.
>
> nikola.je...@rt-rk.com is the initial author of the patch, I'll add myself
> also if necessary
>
>> +config RISCV_EFI
>> + bool "UEFI boot service s
On 26.06.2024 22:20, Andrew Cooper wrote:
> On 20/06/2024 9:39 am, Jan Beulich wrote:
>> On 19.06.2024 21:10, Andrew Cooper wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -2390,7 +2390,7 @@ By default SSBD will be mitigated at runtime (i.e
>>>
On 27.06.2024 03:53, Stefano Stabellini wrote:
> On Wed, 26 Jun 2024, Jan Beulich wrote:
>> On 26.06.2024 03:11, Stefano Stabellini wrote:
>>> On Tue, 25 Jun 2024, Jan Beulich wrote:
On 25.06.2024 02:54, Stefano Stabellini wrote:
> On Mon, 24 Jun 2024, Federico Serafini wrote:
>> Add b
On 26.06.2024 20:09, Andrew Cooper wrote:
> On 26/06/2024 11:24 am, Jan Beulich wrote:
>> On 25.06.2024 21:07, Andrew Cooper wrote:
>>> In all 3 examples, we're iterating over a scaler. No caller can pass the
>>> COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't
>>> matter.
>
On 26.06.2024 19:27, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-06-26 at 10:31 +0200, Jan Beulich wrote:
>> On 25.06.2024 15:51, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/bitops.h
>>> @@ -0,0 +1,137 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/* Co
flight 186528 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186528/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 8 xen-boot fail REGR. vs. 186485
Tests which did not succeed,
On 26.06.2024 19:42, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-06-25 at 08:39 +0200, Jan Beulich wrote:
>> On 25.06.2024 02:47, Stefano Stabellini wrote:
>>> I would like to ask for a release-ack as the patch series makes
>>> very few
>>> changes outside of the static analysis configuration.
Hi Julien,
On 26/06/2024 22:13, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 26/06/2024 09:04, Michal Orzel wrote:
>> Memory node probing is done as part of early_scan_node() that is called
>> for each node with depth >= 1 (root node is at depth 0). According to
>> Devicetree Specification v0.4,
On Thu, 6 Jun 2024 20:14:21 -0700
mhkelle...@gmail.com wrote:
> From: Michael Kelley
>
> With CONFIG_SWIOTLB_DYNAMIC enabled, each round-trip map/unmap pair
> in the swiotlb results in 6 calls to swiotlb_find_pool(). In multiple
> places, the pool is found and used in one function, and then mus
60 matches
Mail list logo
