On 14.12.2021 22:16, Andrew Cooper wrote:
> Specifically, this lets the user opt in to non-default for dom0.
>
> Split features[] out of parse_xen_cpuid(), giving it a lightly more
> appropraite name, so it can be shared with parse_xen_cpuid().
With the latter one I guess you mean parse_dom0_cpui
On Tue, Dec 14, 2021 at 02:52:26PM +, Ian Jackson wrote:
> Roger has agreed to take on osstest admin for the moment. Someone who
> intents to take on the role long term will probably want to get CC's
> of these flight reports, but it's fairly noisy. So for now, send them
> only to the lists.
On Tue, Dec 14, 2021 at 02:52:25PM +, Ian Jackson wrote:
> Any such adhoc flights run from cron should be reported to
> osstest-admin, not my (soon to be deleted) Citrix adddress.
>
> Now the only remaining occurrences are
> - examples
> - authorship annotation of the init script
> - cro
On 12.12.21 04:24, Jason Wang wrote:
The double `the' in the comment in line 163 is repeated. Remove it
from the comment.
Signed-off-by: Jason Wang
---
drivers/xen/xen-pciback/pciback_ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-pciback/pciback_op
flight 167417 qemu-mainline real [real]
flight 167424 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167417/
http://logs.test-lab.xenproject.org/osstest/logs/167424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Jan,
On 15/12/2021 07:49, Jan Beulich wrote:
On 14.12.2021 18:05, Julien Grall wrote:
On 25/11/2021 13:39, Anthony PERARD wrote:
For two reasons: this macro is used to generate a "linker script" and
is not by the linker, and name starting with an underscore '_' are
supposed to be reserved,
Replying to both Julien and Jan,
On 14.12.2021 12:30, Julien Grall wrote:
>
>
> On 14/12/2021 11:01, Julien Grall wrote:
>> Hi,
>>
>> Replying in one e-mail the comments from Jan and Michal.
>>
>> On 14/12/2021 10:01, Jan Beulich wrote:
>>> On 14.12.2021 10:51, Michal Orzel wrote:
Hi Julien
On 15.12.2021 10:27, Michal Orzel wrote:
> Replying to both Julien and Jan,
>
> On 14.12.2021 12:30, Julien Grall wrote:
>>
>>
>> On 14/12/2021 11:01, Julien Grall wrote:
>>> Hi,
>>>
>>> Replying in one e-mail the comments from Jan and Michal.
>>>
>>> On 14/12/2021 10:01, Jan Beulich wrote:
O
Hi,
On 14/12/2021 09:34, Oleksii Moisieiev wrote:
Implementation includes platform-specific smc handler for rcar3 platform.
Signed-off-by: Oleksii Moisieiev
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/rcar3.c | 46 +
2 files changed,
Hi Juergen,
On 15/12/2021 07:12, Juergen Gross wrote:
On 14.12.21 18:21, Julien Grall wrote:
Hi Juergen,
On 08/12/2021 15:55, Juergen Gross wrote:
Today Arm is using another entry point for the vcpu_op hypercall as
NIT: The 'as' doesn't sound right here. Did you mean 'compare to'?
Hmm, it
On 15.12.2021 10:35, Jan Beulich wrote:
> On 15.12.2021 10:27, Michal Orzel wrote:
>> Replying to both Julien and Jan,
>>
>> On 14.12.2021 12:30, Julien Grall wrote:
>>>
>>>
>>> On 14/12/2021 11:01, Julien Grall wrote:
Hi,
Replying in one e-mail the comments from Jan and Michal.
>
On Tue, Dec 14, 2021 at 11:35 AM Oleksii Moisieiev <
oleksii_moisie...@epam.com> wrote:
Hi Oleksii
[sorry for the possible format issues]
Implementation includes platform-specific smc handler for rcar3 platform.
>
> Signed-off-by: Oleksii Moisieiev
> ---
> xen/arch/arm/platforms/Makefile | 1
(Re-sending an abridged version, as apparently spam filters didn't like
the original message with more retained context; I'll have to see whether
this one also isn't liked. Sorry.)
On 15.12.2021 10:48, Michal Orzel wrote:
> This patch and the problem it solves is about clearing top 32bits of all g
On 15.12.2021 11:32, Jan Beulich wrote:
> (Re-sending an abridged version, as apparently spam filters didn't like
> the original message with more retained context; I'll have to see whether
> this one also isn't liked. Sorry.)
>
> On 15.12.2021 10:48, Michal Orzel wrote:
>> This patch and the p
On 12/14/21 4:16 PM, Andrew Cooper wrote:
Specifically, this lets the user opt in to non-default for dom0.
Split features[] out of parse_xen_cpuid(), giving it a lightly more
appropraite name, so it can be shared with parse_xen_cpuid().
Collect all dom0 settings together in dom0_{en,dis}able_fe
flight 167428 xen-unstable-coverity real [real]
flight 167430 xen-unstable-coverity real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167428/
http://logs.test-lab.xenproject.org/osstest/logs/167430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests wh
Dear rest maintainers!
Could you please review this series which seems to get stuck?
Thank you in advance,
Oleksandr
On 25.11.21 13:02, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hi, all!
>
> 1. This patch series is focusing on vPCI and adds support for non-identity
> PC
On 15.12.2021 12:56, Oleksandr Andrushchenko wrote:
> Dear rest maintainers!
>
> Could you please review this series which seems to get stuck?
I don't seem to have any record of you having pinged Roger as the vPCI
maintainer. Also, as said on the Community Call when discussing this,
I don't think
On 15/12/2021 08:34, Jan Beulich wrote:
> On 14.12.2021 22:16, Andrew Cooper wrote:
>> Specifically, this lets the user opt in to non-default for dom0.
>>
>> Split features[] out of parse_xen_cpuid(), giving it a lightly more
>> appropraite name, so it can be shared with parse_xen_cpuid().
> With t
Hi, Jan!
On 15.12.21 14:07, Jan Beulich wrote:
> On 15.12.2021 12:56, Oleksandr Andrushchenko wrote:
>> Dear rest maintainers!
>>
>> Could you please review this series which seems to get stuck?
> I don't seem to have any record of you having pinged Roger as the vPCI
> maintainer.
No, I didn't. Ro
flight 167416 xen-4.15-testing real [real]
flight 167433 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167416/
http://logs.test-lab.xenproject.org/osstest/logs/167433/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 14.12.21 19:44, Oleksandr wrote:
Hi Anthony
On 14.12.21 18:03, Anthony PERARD wrote:
Hi Anthony
On Wed, Dec 08, 2021 at 06:59:43PM +0200, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-disk
backend (emualato
flight 167415 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167415/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 167216
test-amd64-amd64-xl-qemut-win7-a
On 15.12.21 04:58, Volodymyr Babchuk wrote:
Hi Oleksandr,
Hi Volodymyr
Oleksandr Tyshchenko writes:
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
On Fri, Sep 24, 2021 at 11:55:30AM +0200, Jan Beulich wrote:
> This is a re-usable helper (kind of a template) which gets introduced
> without users so that the individual subsequent patches introducing such
> users can get committed independently of one another.
>
> See the comment at the top of
flight 167429 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167429/
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
From: Arnd Bergmann
The #ifdef check around the definition doesn't match the one around the
declaration, leading to a link failure when CONFIG_XEN_DOM0 is enabled
but CONFIG_XEN_PV_DOM0 is not:
x86_64-linux-ld: arch/x86/kernel/apic/msi.o: in function
`arch_restore_msi_irqs':
msi.c:(.text+0x29a)
On Wed, Dec 15, 2021 at 12:22:32PM +, Oleksandr Andrushchenko wrote:
> Hi, Jan!
>
> On 15.12.21 14:07, Jan Beulich wrote:
> > On 15.12.2021 12:56, Oleksandr Andrushchenko wrote:
> >> Dear rest maintainers!
> >>
> >> Could you please review this series which seems to get stuck?
> > I don't seem
Hi, Roger!
On 15.12.21 16:51, Roger Pau Monné wrote:
> On Wed, Dec 15, 2021 at 12:22:32PM +, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 15.12.21 14:07, Jan Beulich wrote:
>>> On 15.12.2021 12:56, Oleksandr Andrushchenko wrote:
Dear rest maintainers!
Could you please rev
On 15.12.21 08:08, Juergen Gross wrote:
Hi Juergen
On 14.12.21 18:44, Oleksandr wrote:
On 14.12.21 18:03, Anthony PERARD wrote:
Hi Anthony
On Wed, Dec 08, 2021 at 06:59:43PM +0200, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds basic support for configuring an
On Fri, Sep 24, 2021 at 11:55:57AM +0200, Jan Beulich wrote:
> When a page table ends up with no present entries left, it can be
> replaced by a non-present entry at the next higher level. The page table
> itself can then be scheduled for freeing.
>
> Note that while its output isn't used there ye
On 24.09.21 12:53, Jan Beulich wrote:
Hi Jan
Having a separate flush-all hook has always been puzzling me some. We
will want to be able to force a full flush via accumulated flush flags
from the map/unmap functions. Introduce a respective new flag and fold
all flush handling to use the single
flight 167419 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167419/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 38f6d78c3b62f8825e7d802697b7992418a72da7
baseline version:
ovmf 9006967c8d24f5d958527
On 15.12.21 16:02, Oleksandr wrote:
On 15.12.21 08:08, Juergen Gross wrote:
Hi Juergen
On 14.12.21 18:44, Oleksandr wrote:
On 14.12.21 18:03, Anthony PERARD wrote:
Hi Anthony
On Wed, Dec 08, 2021 at 06:59:43PM +0200, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch a
On Tue, Dec 14 2021 at 22:19, Thomas Gleixner wrote:
> On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote:
>
> thanks for trying. I'll have a look again with brain awake tomorrow
> morning.
Morning was busy with other things, but I found what my sleepy brain
managed to do wrong yesterday evening.
On Wed, Dec 15 2021 at 17:18, Thomas Gleixner wrote:
> On Tue, Dec 14 2021 at 22:19, Thomas Gleixner wrote:
>> On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote:
>>
>> thanks for trying. I'll have a look again with brain awake tomorrow
>> morning.
>
> Morning was busy with other things, but I fou
The MSI core will introduce runtime allocation of MSI related data. This
data will be devres managed and has to be set up before enabling
PCI/MSI[-X]. This would introduce an ordering issue vs. pcim_release().
The setup order is:
pcim_enable_device()
devres_alloc(pcim_release...);
Allocate MSI device data on first use, i.e. when a PCI driver invokes one
of the PCI/MSI enablement functions.
Add a wrapper function to ensure that the ordering vs. pcim_msi_release()
is correct.
Signed-off-by: Thomas Gleixner
---
V4: Adopted to ensure devres ordering
---
drivers/pci/msi/msi.c
On 10/12/2021 18:37, Oleksandr Andrushchenko wrote:
Hi, Julien!
Hello,
On 10.12.21 19:52, Julien Grall wrote:
Hi Oleksandr,
On 09/12/2021 07:29, Oleksandr Andrushchenko wrote:
+unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
+{
+ if ( !has_vpci(d) )
+ return 0;
+
On Wed, Dec 15, 2021 at 06:16:44PM +0100, Thomas Gleixner wrote:
> The MSI core will introduce runtime allocation of MSI related data. This
> data will be devres managed and has to be set up before enabling
> PCI/MSI[-X]. This would introduce an ordering issue vs. pcim_release().
>
> The setup ord
On Wed, Dec 15, 2021 at 06:19:49PM +0100, Thomas Gleixner wrote:
> Allocate MSI device data on first use, i.e. when a PCI driver invokes one
> of the PCI/MSI enablement functions.
>
> Add a wrapper function to ensure that the ordering vs. pcim_msi_release()
> is correct.
>
> Signed-off-by: Thomas
On 09/12/2021 07:29, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
Hi Oleksandr,
This is an assorted series of patches which aim is to make some further
basis for PCI passthrough on Arm support. The series continues the work
published earlier by Arm [1] and adds new
Hi, Julien!
On 15.12.21 19:48, Julien Grall wrote:
> On 09/12/2021 07:29, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Hi, all!
>
> Hi Oleksandr,
>
>> This is an assorted series of patches which aim is to make some further
>> basis for PCI passthrough on Arm support. The
On 17:35-20211215, Thomas Gleixner wrote:
>git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git
> msi-v4.1-part-2
[...]
> That should cure the problem.
And it sure does. Thanks for looking closer and providing a fix.
https://gist.github.com/nmenon/9862a1c31b17fd6dfe0a30c
Hi,
On 15/12/2021 09:35, Jan Beulich wrote:
1. Regarding save_x0_x1, it is 0 only for guest_sync_slowpath, which is called
by guest_sync.
So as we are dealing only with compat=1, save_x0_x1 cannot be 0.
The conclusion is that we do not need to worry about it.
Oh, good point. I guess you may w
Hi Michal,
On 15/12/2021 10:40, Michal Orzel wrote:
On 15.12.2021 11:32, Jan Beulich wrote:
(Re-sending an abridged version, as apparently spam filters didn't like
the original message with more retained context; I'll have to see whether
this one also isn't liked. Sorry.)
On 15.12.2021 10:48,
flight 167435 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167435/
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
Hi Oleksandr,
Thank you for the point.
I will add it to the next patch version.
Best regards,
Oleksii
On Wed, Dec 15, 2021 at 06:38:00AM +, Oleksandr Andrushchenko wrote:
> Hi, Oleksii!
>
> On 14.12.21 11:34, Oleksii Moisieiev wrote:
> > Implementation includes platform-specific smc handle
On Mon, Dec 06 2021 at 23:51, Thomas Gleixner wrote:
>
> No functional change intended.
Famous last words.
> static int ti_sci_inta_msi_alloc_descs(struct device *dev,
> struct ti_sci_resource *res)
> {
> - struct msi_desc *msi_desc;
> + struct msi_d
flight 167423 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 15.12.21 17:58, Juergen Gross wrote:
Hi Juergen
On 15.12.21 16:02, Oleksandr wrote:
On 15.12.21 08:08, Juergen Gross wrote:
Hi Juergen
On 14.12.21 18:44, Oleksandr wrote:
On 14.12.21 18:03, Anthony PERARD wrote:
Hi Anthony
On Wed, Dec 08, 2021 at 06:59:43PM +0200, Oleksandr Ty
On 14.12.21 11:34, Oleksii Moisieiev wrote:
Hi Oleksii
This enumeration sets SCI type for the domain. Currently there is
two possible options: either 'none' or 'scmi_smc'.
'none' is the default value and it disables SCI support at all.
'scmi_smc' enables access to the Firmware from the dom
flight 167422 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167422/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64 18 guest-localmigrate/x10 fail in
167413 pass in 167422
test-amd64-amd64
flight 167418 xen-unstable real [real]
flight 167439 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167418/
http://logs.test-lab.xenproject.org/osstest/logs/167439/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
I've played with SERIALIZE, TSXLDTRK, MOVDIRI and MOVDIR64 on real hardware,
and they all seem fine, including emulation support.
SERIALIZE exists specifically to have a userspace usable serialising operation
without other side effects. (The only other two choices are CPUID which is a
VMExit unde
Andrew Cooper (4):
x86/cpuid: Split dom0 handling out of init_domain_cpuid_policy()
x86/cpuid: Factor common parsing out of parse_xen_cpuid()
x86/cpuid: Introduce dom0-cpuid command line option
x86/cpuid: Advertise SERIALIZE by default to guests
docs/misc/xen-command-line.pandoc
dom0-cpuid= is going to want to reuse the common parsing loop, so factor it
out into parse_cpuid().
Irritatingly, despite being static const, the features[] array gets duplicated
each time parse_cpuid() is inlined. As it is a large (and ever growing with
new CPU features) datastructure, move it t
To implement dom0-cpuid= support, the special cases would need extending.
However there is already a problem with late hwdom where the special cases
override toolstack settings, which is unintended and poor behaviour.
Introduce a new init_dom0_cpuid_policy() for the purpose, moving the ITSC and
AR
Specifically, this lets the user opt in to non-default for dom0.
Collect all dom0 settings together in dom0_{en,dis}able_feat[], and apply it
to dom0's policy when other tweaks are being made.
As recalculate_cpuid_policy() is an expensive action, and dom0-cpuid= is
likely to only be used by the x
flight 167437 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167437/
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 14.12.21 11:34, Oleksii Moisieiev wrote:
Hi Oleksii
Integration of the SCMI mediator with xen libs:
- add hypercalls to aquire SCI channel and set device permissions
for DomUs;
- add SCMI_SMC nodes to DomUs device-tree based on partial device-tree;
- SCI requests redirection from DomUs to
On 14.12.21 11:34, Oleksii Moisieiev wrote:
Hi Oleksii
Introducing the feature, called SCI mediator.
It's purpose is to redirect SCMI requests from the domains to firmware
(SCP, ATF etc), which controls the power/clock/resets etc.
The idea is to make SCP firmware (or similar, such as AT-F) r
Hi Thomas,
On 17:35-20211215, Thomas Gleixner wrote:
>git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git
> msi-v4.2-part-3
As you helped offline, summarizing the details on part3 of the series:
I was seeing failure[1] of NFS(DMA) on all TI K3 platforms:
[1.013258] ti
On Wed, 15 Dec 2021, Juergen Gross wrote:
> On 14.12.21 18:36, Julien Grall wrote:
> > Hi,
> >
> > On 08/12/2021 15:55, Juergen Gross wrote:
> > > Today most hypercall handlers have a return type of long, while the
> > > compat ones return an int. There are a few exceptions from that rule,
> > > h
On Tue, 14 Dec 2021, Rahul Singh wrote:
> IO ports on ARM don't exist so all IO ports related hypercalls are going
> to fail on ARM when we passthrough a PCI device.
> Failure of xc_domain_ioport_permission(..) would turn into a critical
> failure at domain creation. We need to avoid this outcome,
flight 167426 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167426/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167228
test-amd64-amd64-qemuu-nested-amd 2
Hi all,
gitlab-ci spotted another randconfig build issue on arm32. To repro, use
the attached Xen config file and build with XEN_TARGET_ARCH=arm32 (you
need an appropriate cross-compiler.) This is the error:
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/1888385010
Also appended below
flight 167436 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167436/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f14fff513540757bef62923ee4aeca4bf3ea8081
baseline version:
ovmf 38f6d78c3b62f8825e7d8
On 16.12.21 03:10, Stefano Stabellini wrote:
On Wed, 15 Dec 2021, Juergen Gross wrote:
On 14.12.21 18:36, Julien Grall wrote:
Hi,
On 08/12/2021 15:55, Juergen Gross wrote:
Today most hypercall handlers have a return type of long, while the
compat ones return an int. There are a few exceptions
Some performance counters listed to be credit or credit2 specific are
being used by the null scheduler, too.
Make those sched global ones.
Fixes: ab6ba8c6753fa76 ("perfc: conditionalize credit/credit2 counters")
Signed-off-by: Juergen Gross
---
xen/include/xen/perfc_defn.h | 6 +++---
1 file ch
From: Thomas Gleixner Sent: Wednesday, December 15, 2021
8:36 AM
>
> On Wed, Dec 15 2021 at 17:18, Thomas Gleixner wrote:
>
> > On Tue, Dec 14 2021 at 22:19, Thomas Gleixner wrote:
> >> On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote:
> >>
> >> thanks for trying. I'll have a look again with
vious typo.
Signed-off-by: Lukas Bulwahn
---
applies on next-20211215
Juergen, please ack.
Greg, please pick this minor clean-up on top of the commit above.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 97215d89df4e..a5df6e1219b6 10
On 16.12.21 07:55, Lukas Bulwahn wrote:
Commit a92548f90fa6 ("xen: add Xen pvUSB maintainer") adds the new XEN
PVUSB DRIVER section, but one file entry contains an obvious typo.
Fortunately, ./scripts/get_maintainer.pl --self-test=patterns warns:
warning: no file matchesF:divers/usb/
Hi Julien,
On 15.12.2021 19:25, Julien Grall wrote:
> Hi Michal,
>
> On 15/12/2021 10:40, Michal Orzel wrote:
>> On 15.12.2021 11:32, Jan Beulich wrote:
>>> (Re-sending an abridged version, as apparently spam filters didn't like
>>> the original message with more retained context; I'll have to se
74 matches
Mail list logo
