On 28.01.2022 02:38, Stefano Stabellini wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -284,7 +284,7 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
> xsm_evtchn_close_post(chn);
> }
>
> -static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *al
On 24.01.2022 09:40, Jan Beulich wrote:
> On 23.01.2022 22:52, Hans van Kranenburg wrote:
>> * Any suggestions about what we can do to help figure this out?
>
> I'm pretty certain this needs debugging from the binutils side, so I
> guess you will want to report it there (even more so with 2.38 aro
On 26.01.2022 16:45, Roger Pau Monné wrote:
> On Wed, Jan 26, 2022 at 03:08:28PM +0100, Jan Beulich wrote:
>> On 26.01.2022 13:26, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -479,6 +479,26 @@ unsigned int page_get_ram_type(mfn_t mfn)
>>> return type ?
flight 167921 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167921/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167906
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 167928 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167928/
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 Mon, Jan 24, 2022 at 6:11 PM Christoph Hellwig wrote:
>
> bio_alloc will never fail when it can sleep. Remove the now simple
> nilfs_alloc_seg_bio helper and open code it in the only caller.
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/nilfs2/segbuf.c | 31 ---
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年1月27日 18:01
> To: Jan Beulich ; Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org
> Subject: Re: [PATCH 20/37] xen: introduce CONFIG_EFI to stub API for non-
> EFI architecture
>
flight 167917 linux-linus real [real]
flight 167926 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167917/
http://logs.test-lab.xenproject.org/osstest/logs/167926/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Thu, 27 Jan 2022, Julien Grall wrote:
> On 27/01/2022 12:07, Jan Beulich wrote:
> > On 27.01.2022 10:51, Julien Grall wrote:
> > > On 27/01/2022 01:50, Stefano Stabellini wrote:
> > > > On Wed, 26 Jan 2022, Julien Grall wrote:
> > > > > On 26/01/2022 07:30, Jan Beulich wrote:
> > > > > > On 26.0
On Thu, 27 Jan 2022, Julien Grall wrote:
> On Thu, 27 Jan 2022 at 23:05, Julien Grall wrote:
> >
> > On Thu, 27 Jan 2022 at 22:40, Stefano Stabellini
> > wrote:
> > > I am with you on both points.
> > >
> > > One thing I noticed is that the code today is not able to deal with
> > > IO_UNHANDLED
flight 167924 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167924/
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 167920 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167920/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167788
test-amd64-amd64-qemuu-nested-amd 20 debi
flight 167916 linux-5.4 real [real]
flight 167925 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167916/
http://logs.test-lab.xenproject.org/osstest/logs/167925/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd6
On Thu, 27 Jan 2022 at 23:05, Julien Grall wrote:
>
> On Thu, 27 Jan 2022 at 22:40, Stefano Stabellini
> wrote:
> > I am with you on both points.
> >
> > One thing I noticed is that the code today is not able to deal with
> > IO_UNHANDLED for MMIO regions handled by IOREQ servers or Xen MMIO
> >
On Thu, 27 Jan 2022 at 22:40, Stefano Stabellini wrote:
> I am with you on both points.
>
> One thing I noticed is that the code today is not able to deal with
> IO_UNHANDLED for MMIO regions handled by IOREQ servers or Xen MMIO
> emulator handlers. p2m_resolve_translation_fault and try_map_mmio a
flight 167919 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167919/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6777e673839a510aaa62a48514a4223da7d3bba2
baseline version:
ovmf 8cc5590eab974ab34e2bf
On Thu, 27 Jan 2022, Julien Grall wrote:
> On 27/01/2022 15:48, Ayan Kumar Halder wrote:
> > On 27/01/2022 13:57, Julien Grall wrote:
> > >
> > >
> > > On 27/01/2022 13:20, Ayan Kumar Halder wrote:
> > > > Hi,
> > > >
> > > > Asking here as well (might not have been clear on irc).
> > > >
> > >
On 27/01/2022 07:25, Jan Beulich wrote:
> On 26.01.2022 21:16, Andrew Cooper wrote:
>> On 26/01/2022 16:50, Jan Beulich wrote:
>>> On 26.01.2022 09:44, Andrew Cooper wrote:
1) It would be slightly more efficient to pass curr and cpu_info into
vm{entry,exit}_spec_ctrl(), but setup of su
On Thu, 27 Jan 2022, Oleksii Moisieiev wrote:
> On Tue, Jan 25, 2022 at 01:19:46PM -0800, Stefano Stabellini wrote:
> > On Tue, 25 Jan 2022, Oleksii Moisieiev wrote:
> > > On Mon, Jan 24, 2022 at 02:14:43PM -0800, Stefano Stabellini wrote:
> > > > On Mon, 24 Jan 2022, Julien Grall wrote:
> > > > >
On 27.01.22 22:03, Julien Grall wrote:
Hi,
Hi Julien
On 27/01/2022 19:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
All IOMMU drivers on Arm perform almost the same generic actions in
hwdom_init callback. Move this code to common arch_iommu_hwdom_init()
in order to get ri
On 27/01/2022 15:48, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
On 27/01/2022 13:57, Julien Grall wrote:
On 27/01/2022 13:20, Ayan Kumar Halder wrote:
Hi,
Asking here as well (might not have been clear on irc).
On 27/01/2022 00:10, Julien Grall wrote:
Hi,
On Wed, 26 Jan 2022, 17:56 Ayan
Hi,
On 27/01/2022 19:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
All IOMMU drivers on Arm perform almost the same generic actions in
hwdom_init callback. Move this code to common arch_iommu_hwdom_init()
in order to get rid of code duplication.
Signed-off-by: Oleksandr Tyshchenk
From: Oleksandr Tyshchenko
Reference-count the micro-TLBs as several bus masters can be
connected to the same micro-TLB (and drop TODO comment).
This wasn't an issue so far, since the platform devices
(this driver deals with) get assigned/deassigned together during
domain creation/destruction. Bu
From: Oleksandr Tyshchenko
Hello all.
You can find the V1-V2 patch series at [1]-[2].
The first 8 patches (prereq work + R-Car S4 IPMMU support) have been already
committed.
These are remaining 2 patches which include misc changes.
[1]
https://lore.kernel.org/all/1638035505-16931-1-git-send-
From: Oleksandr Tyshchenko
All IOMMU drivers on Arm perform almost the same generic actions in
hwdom_init callback. Move this code to common arch_iommu_hwdom_init()
in order to get rid of code duplication.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Volodymyr Babchuk
Reviewed-by: Yoshihir
On 27.01.22 19:18, Volodymyr Babchuk wrote:
Hi Volodymyr
Hi Julien, Bertrand,
Sorry, I messed up with your e-mail addresses in the previous
email. Adding you correctly.
Volodymyr Babchuk writes:
HSCIF is a high-speed variant of Renesas SCIF serial interface. From
Xen point of view, they
flight 167908 xen-4.14-testing real [real]
flight 167923 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167908/
http://logs.test-lab.xenproject.org/osstest/logs/167923/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On Tue, Jan 25, 2022 at 01:19:46PM -0800, Stefano Stabellini wrote:
> On Tue, 25 Jan 2022, Oleksii Moisieiev wrote:
> > On Mon, Jan 24, 2022 at 02:14:43PM -0800, Stefano Stabellini wrote:
> > > On Mon, 24 Jan 2022, Julien Grall wrote:
> > > > On 24/01/2022 19:06, Stefano Stabellini wrote:
> > > > >
On 27/01/2022 16:41, Jan Beulich wrote:
> On 27.01.2022 17:09, Andrew Cooper wrote:
>> From: Jan Beulich
>>
>> Signed-off-by: Jan Beulich
>> Signed-off-by: Andrew Cooper
> Considering what patch 1 does to the code, would you mind dropping
> the 0x000 number prefix from the subject?
Oops, ye
On 27/01/2022 13:47, Jan Beulich wrote:
> On 26.01.2022 09:44, Andrew Cooper wrote:
>> With all other pieces in place, MSR_SPEC_CTRL is fully working for HVM
>> guests.
>>
>> Update the CPUID derivation logic (both PV and HVM to avoid losing subtle
>> changes), and explicitly enable the CPUID bits
Hi Julien, Bertrand,
Sorry, I messed up with your e-mail addresses in the previous
email. Adding you correctly.
Volodymyr Babchuk writes:
> HSCIF is a high-speed variant of Renesas SCIF serial interface. From
> Xen point of view, they almost the same, only difference is in FIFO
> size.
>
> S
On Mon, Jan 24 2022 at 4:10P -0500,
Christoph Hellwig wrote:
> Use blkdev_issue_flush, which uses an on-stack bio instead of an
> opencoded version with a bio embedded into struct pool.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
On Mon, Jan 24 2022 at 4:10P -0500,
Christoph Hellwig wrote:
> Use blkdev_issue_flush, which uses an on-stack bio instead of an
> opencoded version with a bio embedded into struct dm_snapshot.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
On Mon, Jan 24 2022 at 4:10P -0500,
Christoph Hellwig wrote:
> Just open code it next to the bio allocations, which saves a few lines
> of code, prepares for future changes and allows to remove the duplicate
> bi_opf assignment for the bio_clone_fast case in kcryptd_io_read.
>
> Signed-off-by:
On Mon, Jan 24 2022 at 4:10P -0500,
Christoph Hellwig wrote:
> Remove handling of NULL returns from sleeping bio_alloc calls given that
> those can't fail.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
flight 167918 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167918/
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/01/2022 16:39, Jan Beulich wrote:
> On 27.01.2022 17:09, Andrew Cooper wrote:
>> Adding a new feature leaf is a reasonable amount of boilerplate and for the
>> patch to build, at least one feature from the new leaf needs defining. This
>> typically causes two non-trivial changes to be merged
On 27.01.2022 17:09, Andrew Cooper wrote:
> From: Jan Beulich
>
> Signed-off-by: Jan Beulich
> Signed-off-by: Andrew Cooper
Considering what patch 1 does to the code, would you mind dropping
the 0x000 number prefix from the subject?
Jan
On 27.01.2022 17:09, Andrew Cooper wrote:
> Adding a new feature leaf is a reasonable amount of boilerplate and for the
> patch to build, at least one feature from the new leaf needs defining. This
> typically causes two non-trivial changes to be merged together.
>
> First, have gen-cpuid.py writ
flight 167911 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167911/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
The changes for the OCaml bindings are minimal and administrative. This looks
good to me.
Acked-by: Christian Lindig
mailto:christian.lin...@citrix.com>>
On 27 Jan 2022, at 16:01, Jane Malalane
mailto:jane.malal...@citrix.com>> wrote:
Introduce a new per-domain creation x86 specific flag to
s
On 27/01/2022 16:09, Andrew Cooper wrote:
> Adding a new feature leaf is a reasonable amount of boilerplate and for the
> patch to build, at least one feature from the new leaf needs defining. This
> typically causes two non-trivial changes to be merged together.
>
> First, have gen-cpuid.py write
From: Jan Beulich
Signed-off-by: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
Split in two, rebase.
---
tools/misc/xen-cpuid.c | 5 +
xen/arch/x86/cpu/common.c | 3 ++-
xen/include/public/arch-x86/cp
From: Jan Beulich
As of SDM revision 076 there is a CPUID bit for this functionality. Use
it to amend the existing model-based logic.
Signed-off-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
Split in two.
---
tools/misc/xen-cpuid.c | 1 +
xen/arc
Work to disentangle new feature addition, using PPIN as an example.
Andrew Cooper (1):
x86/cpuid: Disentangle logic for new feature leaves
Jan Beulich (2):
x86/cpuid: Infrastructure for leaf 0x0007:1.ebx
x86/Intel: use CPUID bit to determine PPIN availability
tools/misc/xen-cpuid.c
Adding a new feature leaf is a reasonable amount of boilerplate and for the
patch to build, at least one feature from the new leaf needs defining. This
typically causes two non-trivial changes to be merged together.
First, have gen-cpuid.py write out some extra placeholder defines:
#define CPU
Introduce a new per-domain creation x86 specific flag to
select whether hardware assisted virtualization should be used for
x{2}APIC.
A per-domain option is added to xl in order to select the usage of
x{2}APIC hardware assisted vitualization, as well as a global
configuration option.
Having all A
Jane Malalane (2):
xen+tools: Report Interrupt Controller Virtualization capabilities on
x86
x86/xen: Allow per-domain usage of hardware virtualized APIC
docs/man/xl.cfg.5.pod.in | 10 +++
docs/man/xl.conf.5.pod.in | 12
tools/golang/xenlight/helpers.
Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
and x2apic, on x86 hardware.
No such features are currently implemented on AMD hardware.
For that purpose, also add an arch-specific "capabilities" parameter
to struct xen_sysctl_phys
On 25.01.2022 12:00, Anthony PERARD wrote:
> clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
> only the filename rather than the full path to the source file.
>
> clang 3.8.1-24 (in our debian:stretch container) and 3.5.0-10
> (in our debian:jessie container) do store the fu
On 25.01.2022 12:00, Anthony PERARD wrote:
> This is to avoid arch/$arch/Makefile having to recurse into parents
> directories.
>
> This avoid duplication of the logic to build prelink.o between arches.
>
> In order to do that, we cut the $(TARGET) target in the main Makefile in
> two, there is a
Hi Julien,
Thanks a lot for your clarification. Appreciate your help. I have a
concern as below:-
On 27/01/2022 13:57, Julien Grall wrote:
On 27/01/2022 13:20, Ayan Kumar Halder wrote:
Hi,
Asking here as well (might not have been clear on irc).
On 27/01/2022 00:10, Julien Grall wrote:
H
On 25.01.2022 12:00, Anthony PERARD wrote:
> Exporting a variable with a dash doesn't work reliably, they may be
> striped from the environment when calling a sub-make or sub-shell.
>
> CFLAGS-stack-boundary start to be removed from env in patch "build:
> set ALL_OBJS in main Makefile; move prelin
On 25.01.2022 12:00, Anthony PERARD wrote:
> We are going to need the variable XEN_BUILD_EFI earlier.
>
> But a side effect of calculating the value of $(XEN_BUILD_EFI) is to
> also to generate "efi/check.o" which is used for further checks.
> Thus the whole chain that check for EFI support is mov
While we don't want to skip calling update_idle_stats(), arrange for it
to not increment the overall time spent in the state we didn't really
enter.
Signed-off-by: Jan Beulich
---
RFC: If we wanted to also move the tracing, then I think the part ahead
of the if() also would need moving. At t
From: Artem Bityutskiy
Enable local interrupts before requesting C1 on the last two generations
of Intel Xeon platforms: Sky Lake, Cascade Lake, Cooper Lake, Ice Lake.
This decreases average C1 interrupt latency by about 5-10%, as measured
with the 'wult' tool.
The '->enter()' function of the dr
1: enable interrupts before C1 on Xeons
2: squash stats update when not actually entering C-state
Jan
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 overlapping
the remapped range but the base GFN outside of that range, an altp2m may
wrongly not
On 04.01.2022 11:57, Jan Beulich wrote:
> 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 i
On 04.01.2022 10:48, Jan Beulich wrote:
> 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 calle
On 04.01.2022 10:41, Jan Beulich wrote:
> 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
Ping?
Jan
On 04.01.2022 10:41, Jan Beulich wrote:
> 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
flight 167906 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167906/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail pass in 167851
Tests which did not succeed, but
Determining that behavior is correct (i.e. results in failure) for a
passed in GFN equaling INVALID_GFN is non-trivial. Make this quite a bit
more obvious by checking input in generic code - both for singular
requests to not match the value and for range ones to not pass / wrap
through it.
For Arm
The VT-d hook can indicate an error, which shouldn't be ignored. Convert
the hook's return value to a proper error code, and let that bubble up.
Signed-off-by: Jan Beulich
---
I'm not convinced of the XSM related behavior here: It's neither clear
why the check gets performed on the possible furth
Let's use infrastructure we have available instead of an open-coded
wbinvd() invocation.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -78,8 +78,6 @@ int __must_check qinval_device_iotlb_syn
The actual function should always have lived in core x86 code; move it
there, replacing get_cache_line_size() by readily available (except very
early during boot; see the code comment) data. Also rename the function.
Drop the respective IOMMU hook, (re)introducing a respective boolean
instead. Rep
This is, once again, to limit the number of indirect calls as much as
possible. The only hook invocation which isn't sensible to convert is
setup(). And of course Arm-only use sites are left alone as well.
Note regarding the introduction / use of local variables in pci.c:
struct pci_dev's involved
Besides the altcall conversion, some further adjustments appeared desirable
to do while touching that area.
1: IOMMU/x86: switch to alternatives-call patching in further instances
2: VT-d / x86: re-arrange cache syncing
3: VT-d: replace flush_all_cache()
4: IOMMU/PCI: propagate get_device_group_id
Hello Michał,
09.01.2022 02:35, Michał Mirosław пишет:
> BTW, I couldn't find a right description of my idea of unifying the
> chains before, so let me sketch it now.
>
> The idea is to have a single system-off chain in which the callback
> gets a mode ({QUERY_*, PREP_*, DO_*} for each of {*_REBO
The increasing amount of constructs along the lines of
if ( !condition )
{
ASSERT_UNREACHABLE();
return;
}
is not only longer than necessary, but also doesn't produce incident
specific console output (except for file name and line number). Allow
the intended effect to
On 27/01/2022 13:20, Ayan Kumar Halder wrote:
Hi,
Asking here as well (might not have been clear on irc).
On 27/01/2022 00:10, Julien Grall wrote:
Hi,
On Wed, 26 Jan 2022, 17:56 Ayan Kumar Halder,
wrote:
Hi Julien,
On 26/01/2022 17:22, Julien Grall wrote:
Hi,
On Wed,
On 26.01.2022 09:44, Andrew Cooper wrote:
> With all other pieces in place, MSR_SPEC_CTRL is fully working for HVM guests.
>
> Update the CPUID derivation logic (both PV and HVM to avoid losing subtle
> changes), and explicitly enable the CPUID bits for HVM guests.
>
> Signed-off-by: Andrew Coope
Hi,
On 27/01/2022 12:07, Jan Beulich wrote:
On 27.01.2022 10:51, Julien Grall wrote:
On 27/01/2022 01:50, Stefano Stabellini wrote:
On Wed, 26 Jan 2022, Julien Grall wrote:
On 26/01/2022 07:30, Jan Beulich wrote:
On 26.01.2022 02:03, Stefano Stabellini wrote:
Are you guys OK with something
Hi,
Asking here as well (might not have been clear on irc).
On 27/01/2022 00:10, Julien Grall wrote:
Hi,
On Wed, 26 Jan 2022, 17:56 Ayan Kumar Halder,
wrote:
Hi Julien,
On 26/01/2022 17:22, Julien Grall wrote:
Hi,
On Wed, 26 Jan 2022, 16:58 Ayan Kumar Halder,
wrote:
On 27.01.22 13:48, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 20/12/2021 21:15, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Reference-count the micro-TLBs as several bus masters can be
connected to the same micro-TLB (and drop TODO comment).
This wasn't an issue so far,
On 26.01.2022 09:44, Andrew Cooper wrote:
> Fill in VMCB accessors for spec_ctrl in svm_{get,set}_reg(), and CPUID checks
> for all supported bits in guest_{rd,wr}msr().
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 27.01.22 14:36, Julien Grall wrote:
Hi,
Hi Julien
On 20/12/2021 21:15, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hello all.
You can find the V1 patch series at [1].
The R-Car S4 is an automotive System-on-Chip (SoC) for Car
Server/Communication
Gateway and is one of
As of SDM revision 076 there is a CPUID bit for this functionality. Use
it to amend the existing model-based logic.
Signed-off-by: Jan Beulich
---
It continues to be unclear for which CPU models, if any, the PPIN_CAP
bit in PLATFORM_INFO could be used in favor of a model check.
---
v3: Actually r
flight 167907 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167907/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8cc5590eab974ab34e2bfa1c9d6a7ef94c70ffae
baseline version:
ovmf 7e5c603cba0823fd97456
Hi,
On 20/12/2021 21:15, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hello all.
You can find the V1 patch series at [1].
The R-Car S4 is an automotive System-on-Chip (SoC) for Car Server/Communication
Gateway and is one of the first products in Renesas’ 4th-generation R-Car
Famil
On 27.01.2022 11:45, Julien Grall wrote:
> On 12/01/2022 08:45, Jan Beulich wrote:
>> From: Sergey Temerkhanov
>>
>> This helps overcome problems observed with some UEFI implementations
>
> Would it be possible to provide some details about the platform? This is
> helpful to track why a workarou
On 27.01.2022 10:47, Roger Pau Monné wrote:
> On Thu, Jan 27, 2022 at 09:48:16AM +0100, Jan Beulich wrote:
>> On 27.01.2022 09:22, Roger Pau Monne wrote:
>>> --- a/xen/arch/arm/mm.c
>>> +++ b/xen/arch/arm/mm.c
>>> @@ -1625,6 +1625,17 @@ bool is_iomem_page(mfn_t mfn)
>>> return !mfn_valid(mfn);
On 27.01.22 13:54, Julien Grall wrote:
Hi,
Hi Julien
On 20/12/2021 21:15, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
All IOMMU drivers on Arm perform almost the same generic actions in
hwdom_init callback. Move this code to common arch_iommu_hwdom_init()
in order to get ri
On 27.01.2022 10:51, Julien Grall wrote:
> On 27/01/2022 01:50, Stefano Stabellini wrote:
>> On Wed, 26 Jan 2022, Julien Grall wrote:
>>> On 26/01/2022 07:30, Jan Beulich wrote:
On 26.01.2022 02:03, Stefano Stabellini wrote:
> Are you guys OK with something like this?
With proper
Hi,
On 20/12/2021 21:15, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
All IOMMU drivers on Arm perform almost the same generic actions in
hwdom_init callback. Move this code to common arch_iommu_hwdom_init()
in order to get rid of code duplication.
Signed-off-by: Oleksandr Tyshchenk
Hi Oleksandr,
On 20/12/2021 21:15, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Reference-count the micro-TLBs as several bus masters can be
connected to the same micro-TLB (and drop TODO comment).
This wasn't an issue so far, since the platform devices
(this driver deals with) get a
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/IOeM+94IftDZ0Byu-0aR9n0D/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the document.
Hi Jan,
On 12/01/2022 08:45, Jan Beulich wrote:
From: Sergey Temerkhanov
This helps overcome problems observed with some UEFI implementations
Would it be possible to provide some details about the platform? This is
helpful to track why a workaround is present.
which don't set the Attribu
Hi Ayan,
Below some more comments on a few issues I noticed while reviewing your
other patch yesterday.
On 25/01/2022 21:18, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 729287e37c..b9c15e1fe7 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -106,
Hi,
On 27/01/2022 09:27, Jan Beulich wrote:
On 27.01.2022 10:25, Wei Chen wrote:
From: Jan Beulich
Sent: 2022年1月27日 17:17
On 27.01.2022 10:09, Wei Chen wrote:
From: Jan Beulich
Sent: 2022年1月27日 17:00
But you realize we already have such a stub file on x86?
Yes, we found the redefinition
Hi Stefano,
On 27/01/2022 01:50, Stefano Stabellini wrote:
On Wed, 26 Jan 2022, Julien Grall wrote:
On 26/01/2022 07:30, Jan Beulich wrote:
On 26.01.2022 02:03, Stefano Stabellini wrote:
Are you guys OK with something like this?
With proper proof that this isn't going to regress anything el
On Thu, Jan 27, 2022 at 09:48:16AM +0100, Jan Beulich wrote:
> On 27.01.2022 09:22, Roger Pau Monne wrote:
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -1625,6 +1625,17 @@ bool is_iomem_page(mfn_t mfn)
> > return !mfn_valid(mfn);
> > }
> >
> > +bool is_iomem_range(paddr_t
Andrew says "Given the AMD MSR_SPEC_CTRL series just posted, use of
CPUID bits will often be symmetrical and it's awkward to have one or
with a prefix and the other without." Let's drop the two prefixes of
this kind that we have.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New
flight 167894 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167894/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167620
test-amd64-amd64-xl-qemuu-win7-a
On 27.01.2022 10:25, Wei Chen wrote:
>> From: Jan Beulich
>> Sent: 2022年1月27日 17:17
>>
>> On 27.01.2022 10:09, Wei Chen wrote:
From: Jan Beulich
Sent: 2022年1月27日 17:00
But you realize we already have such a stub file on x86?
>>>
>>> Yes, we found the redefinition errors t
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年1月27日 17:22
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 12/37] xen/x86: decouple nodes_cover_memory from E820
> map
>
> On 27.01.2022
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年1月27日 17:17
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 20/37] xen: introduce CONFIG_EFI to stub API for non-
> EFI architecture
>
>
On 27.01.2022 10:03, Wei Chen wrote:
>> From: Jan Beulich
>> Sent: 2022年1月27日 16:09
>>
>> On 27.01.2022 09:03, Wei Chen wrote:
From: Jan Beulich
Sent: 2022年1月25日 0:59
On 23.09.2021 14:02, Wei Chen wrote:
> We will reuse nodes_cover_memory for Arm to check its bootmem
>
On 27.01.2022 10:09, Wei Chen wrote:
>> From: Jan Beulich
>> Sent: 2022年1月27日 17:00
>>
>> On 27.01.2022 09:51, Wei Chen wrote:
From: Xen-devel On Behalf Of
>> Wei
Chen
Sent: 2022年1月27日 16:45
> From: Jan Beulich
> Sent: 2022年1月25日 18:35
>
> On 23.09.2021 14:02,
1 - 100 of 121 matches
Mail list logo
