On 04.01.2022 18:03, Boris Ostrovsky wrote:
>
> On 1/4/22 11:54 AM, Jan Beulich wrote:
>> On 04.01.2022 17:50, Boris Ostrovsky wrote:
>>> On 1/4/22 3:46 AM, Jan Beulich wrote:
The hypervisor has been supplying this information for a couple of major
releases. Make use of it. The need to
On 15.04.2021 11:57, Jan Beulich wrote:
> On 01.04.2021 12:50, Paul Durrant wrote:
>> On 01/04/2021 11:22, Roger Pau Monne wrote:
>>> The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU
>>> as current, as there's no support for EOI'ing interrupts on a remote
>>> vCPU.
>>>
>>> While
On 26.08.2021 12:06, Jan Beulich wrote:
> The first four patches can be attributed to the former, the last four
> patches to the latter. The middle patch had been submitted standalone
> before, has a suitable Reviewed-by tag, but also has an objection by
> Andrew pending, which unfortunately has
On 04.01.2022 22:41, Oleksandr wrote:
> On 04.01.22 10:36, Jan Beulich wrote:
>> On 22.12.2021 13:44, Oleksandr wrote:
>>> I also wonder, can we apply pattern for all type of pages here (without
>>> differentiating)?
>> I'm afraid I don't understand this part: How could we get along without
>>
flight 167604 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167604/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167596
test-armhf-armhf-libvirt 16
flight 167603 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167603/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167597
test-armhf-armhf-libvirt 16
On 04.01.22 10:36, Jan Beulich wrote:
Hi Jan
On 22.12.2021 13:44, Oleksandr wrote:
On 22.12.21 14:33, Julien Grall wrote:
Hi Jan,
Hi Julien, Jan
On 22/12/2021 13:05, Jan Beulich wrote:
On 22.12.2021 11:01, Julien Grall wrote:
On 14/12/2021 17:45, Jan Beulich wrote:
On 14.12.2021
> I may be entirely wrong and hence that part of the change may also be
> wrong, but I'm having trouble seeing why the original
> "!mfn_eq(m, INVALID_MFN)" wasn't "mfn_eq(m, INVALID_MFN)". Isn't the
> goal there to pre-fill entries that were previously invalid, instead of
> undoing prior
On Tue, Jan 4, 2022 at 11:14 AM Jan Beulich wrote:
>
> On 04.01.2022 16:00, Tamas K Lengyel wrote:
> > On Tue, Jan 4, 2022 at 4:48 AM Jan Beulich wrote:
> >>
> >> Prior to XSA-304 the only caller merely happened to not use any further
> >> the order value that it passes into the function.
On 1/4/22 11:54 AM, Jan Beulich wrote:
On 04.01.2022 17:50, Boris Ostrovsky wrote:
On 1/4/22 3:46 AM, Jan Beulich wrote:
The hypervisor has been supplying this information for a couple of major
releases. Make use of it. The need to set a flag in the capabilities
field also points out that
On 04.01.2022 17:50, Boris Ostrovsky wrote:
>
> On 1/4/22 3:46 AM, Jan Beulich wrote:
>> The hypervisor has been supplying this information for a couple of major
>> releases. Make use of it. The need to set a flag in the capabilities
>> field also points out that the prior setting of that field
On 1/4/22 3:46 AM, Jan Beulich wrote:
The hypervisor has been supplying this information for a couple of major
releases. Make use of it. The need to set a flag in the capabilities
field also points out that the prior setting of that field from the
hypervisor interface's gbl_caps one was wrong,
On 06.09.2021 14:58, Jan Beulich wrote:
> Before the code freeze I thought I'd check the original driver again,
> and indeed there were a few changes we want to inherit.
>
> 1: mention assumption that WBINVD is not needed
> 2: add SnowRidge C-state table
> 3: update ICX C6 data
> 4: add Icelake-D
On 04.01.2022 15:44, Andrew Cooper wrote:
> Since this logic was introduced, opt_tsx has become more complicated and
> shouldn't be compared to 0 directly. While there are no buggy logic paths,
> the correct expression is !(opt_tsx & 1) but the rtm_disabled boolean is
> easier and clearer to use.
On 04.01.2022 16:00, Tamas K Lengyel wrote:
> On Tue, Jan 4, 2022 at 4:48 AM Jan Beulich wrote:
>>
>> Prior to XSA-304 the only caller merely happened to not use any further
>> the order value that it passes into the function. Already then this was
>> a latent issue: The function really should,
> > > > But seems like this patch is not stable enough yet and has its own
> > > > issue -- memory is not properly released?
> > >
> > > I know. I've been working on improving it this morning and I'm
> > > attaching an updated version below.
> > >
> > Good news.
> > With this new patch, the NAS
On Tue, Jan 4, 2022 at 4:48 AM Jan Beulich wrote:
>
> Prior to XSA-304 the only caller merely happened to not use any further
> the order value that it passes into the function. Already then this was
> a latent issue: The function really should, in the "get" case, hand back
> the order the
Since this logic was introduced, opt_tsx has become more complicated and
shouldn't be compared to 0 directly. While there are no buggy logic paths,
the correct expression is !(opt_tsx & 1) but the rtm_disabled boolean is
easier and clearer to use.
Fixes: 8fe24090d940 ("x86/cpuid: Rework HLE and
Hello,
Does the Xen hypervisor use the Rust-Lang or will use it in the future?
Thank you.
Hi Jan,
On 04/01/2022 13:35, Jan Beulich wrote:
On 04.01.2022 14:31, Julien Grall wrote:
Sending the e-mail to xen-devel as well. The community call has been
moved to the 11th January, 4pm BST.
FAOD I assume you mean GMT / UTC, not BST?
Oops. Yes I meant GMT/UTC.
Cheers,
--
Julien Grall
On 04.01.2022 14:31, Julien Grall wrote:
> Sending the e-mail to xen-devel as well. The community call has been
> moved to the 11th January, 4pm BST.
FAOD I assume you mean GMT / UTC, not BST?
Jan
Hi all,
Sending the e-mail to xen-devel as well. The community call has been
moved to the 11th January, 4pm BST.
Best regards.
Forwarded Message
Subject: Updated invitation with note: Xen Community Call @ Tue Jan 11,
2022 11am - 12pm (EST) (jul...@xen.org)
Date: Thu,
flight 167602 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167602/
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
When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count should indicate too large a
value in preference to a too small one, to avoid functions bailing early
when they find the count is zero. Hence increments should happen ahead
of P2M updates,
Jan Beulich writes ("Re: [PATCH] SUPPORT.md, MAINTAINERS: De-support
qemu-xen-traditional"):
> FWIW I agree that this needs updating at the same time or in a prereq
> change. I guess it'll need to be someone other than Ian now to pick
> up and progress this patch, though.
Yes, I'm afraid so.
flight 167601 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167601/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 079a58276b98dc97ca363e3bc8b35cc7baa56d76
baseline version:
ovmf
On Fri, Dec 31, 2021 at 10:47:57PM +0800, G.R. wrote:
> On Fri, Dec 31, 2021 at 2:52 AM Roger Pau Monné wrote:
> >
> > On Thu, Dec 30, 2021 at 11:12:57PM +0800, G.R. wrote:
> > > On Thu, Dec 30, 2021 at 3:07 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Wed, Dec 29, 2021 at 11:27:50AM
On 06.12.2021 14:21, Jan Beulich wrote:
> 1: tidy paging_mfn_is_dirty()
> 2: replace most mfn_valid() in log-dirty handling
Any chance of getting an ack or otherwise here?
Thanks, Jan
On 03.12.2021 13:09, Jan Beulich wrote:
> The 64-bit form forces %ecx to 0 while the 32-bit one so far didn't - it
> only ended up that way when "pv_context" is zero. While presently no
> leaf queried by callers has separate subleaves, let's avoid chancing it.
>
> While there
> - replace
For higher order mappings the comparison against p2m->min_remapped_gfn
needs to take the upper bound of the covered GFN range into account, not
just the base GFN.
Otherwise, i.e. when dropping a mapping and not overlapping the remapped
range, XXX.
Note that there's no need to call
Prior to XSA-304 the only caller merely happened to not use any further
the order value that it passes into the function. Already then this was
a latent issue: The function really should, in the "get" case, hand back
the order the underlying mapping actually uses (or actually the smaller
of the
Avoid recurring MFN -> page or page -> MFN translations. Drop the pretty
pointless local variable "p". Make sure the MFN logged in a debugging
error message is actually the offending one. Return negative errno
values rather than -1 (presently no caller really cares, but imo this
should change).
1: PoD: simplify / improve p2m_pod_cache_add()
2: altp2m: p2m_altp2m_get_or_propagate() should honor present page order
3: altp2m: p2m_altp2m_propagate_change() should honor present page order
The last one continues to be RFC, as there is an aspect I can't make sense
of. See there.
Jan
Do away with the "pod_target_out_unlock" label. In particular by folding
if()-s, the logic can be expressed with less code (and no goto-s) this
way.
Limit scope of "p2m", constifying it at the same time.
Signed-off-by: Jan Beulich
---
v2: Re-base over new earlier patch.
--- a/xen/arch/x86/mm.c
While it is okay for IOMMU page tables to get set up for guests starting
in PoD mode, actual device assignment may only occur once all PoD
entries have been removed from the P2M. So far this was enforced only
for boot-time assignment, and only in the tool stack.
Also use the new function to
1: IOMMU/x86: disallow device assignment to PoD guests
2: x86/mm: tidy XENMEM_{get,set}_pod_target handling
Jan
flight 167597 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167597/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167593
test-armhf-armhf-libvirt 16
On 04.01.2022 09:57, Roger Pau Monné wrote:
> On Tue, Dec 21, 2021 at 09:09:45AM +0100, Jan Beulich wrote:
>> On 20.12.2021 16:25, Roger Pau Monné wrote:
>>> I think it might be interesting to add some kind of unit testing to
>>> this code in tools/tests. It's a standalone piece of code that could
On Tue, Dec 21, 2021 at 09:09:45AM +0100, Jan Beulich wrote:
> On 20.12.2021 16:25, Roger Pau Monné wrote:
> > I think it might be interesting to add some kind of unit testing to
> > this code in tools/tests. It's a standalone piece of code that could
> > be easily tested for correct
Hi, Daniel!
On 21.12.21 18:04, Daniel P. Smith wrote:
> From: Christopher Clark
>
> This is a split out of the hyperlaunch dom0 series.
>
> There were several instances of open-coded domid range checking. This commit
> replaces those with the is_system_domain or is_system_domid inline function.
The hypervisor has been supplying this information for a couple of major
releases. Make use of it. The need to set a flag in the capabilities
field also points out that the prior setting of that field from the
hypervisor interface's gbl_caps one was wrong, so that code gets deleted
(there's also
flight 167598 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167598/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 13d9e8ec98ee3f9f14a45471b38a22b9fd66d1ce
baseline version:
ovmf
On 22.12.2021 13:44, Oleksandr wrote:
>
> On 22.12.21 14:33, Julien Grall wrote:
>> Hi Jan,
>
>
> Hi Julien, Jan
>
>
>
>>
>> On 22/12/2021 13:05, Jan Beulich wrote:
>>> On 22.12.2021 11:01, Julien Grall wrote:
On 14/12/2021 17:45, Jan Beulich wrote:
> On 14.12.2021 17:26, Oleksandr
On 22.12.2021 13:33, Julien Grall wrote:
> On 22/12/2021 13:05, Jan Beulich wrote:
>> On 22.12.2021 11:01, Julien Grall wrote:
>>> On 14/12/2021 17:45, Jan Beulich wrote:
On 14.12.2021 17:26, Oleksandr wrote:
> On 14.12.21 15:37, Jan Beulich wrote:
>> On 03.12.2021 21:33, Oleksandr
On 04/01/2022 07:53, Jan Beulich wrote:
On 14.12.2021 08:49, Jan Beulich wrote:
Attempting to wait when the backend hasn't been created yet can't work:
the function will complain "Backend ... does not exist". Move the
waiting past the creation of the backend (and that of other related
nodes),
45 matches
Mail list logo
