This function is refactored to avoid using a
local dummy variable that served as a fallback
if the parameter 't' is NULL.
Storing the address of that variable into 't' caused
static analysis tools not to be able to recognize the
validity of the initialization, and to help with automatic
checking t
On 21.07.2023 02:23, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Rule 1.1 is uncontroversial and we are already following it.
Except for our extensive use of compiler extensions. I thought we had
agreed to add a respective remark?
> Rule 5.6 has been deemed a good rule to have by t
On 21-07-23, 08:38, kernel test robot wrote:
> Hi Viresh,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on xen-tip/linux-next]
> [also build test ERROR on linus/master v6.5-rc2 next-20230720]
> [If your patch is applied to the wrong git
On 21.07.2023 00:34, Julien Grall wrote:
> On 20/07/2023 16:04, Juergen Gross wrote:
>> The fix for XSA-417 had a bug: domain_alloc_permrefs() will not return
>> a negative value in case of an error, but a plain errno value.
>>
>> Note this is not considered to be a security issue, as the only case
Xen provides support for injecting interrupts to the guests via the
HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
device backend implementations, in an inefficient manner currently.
Generally, the Virtio backends are implemented to work with the Eventfd
based mechanism. In ord
On 06-07-23, 12:59, Viresh Kumar wrote:
> Currently, the grant mapping related device tree properties are added if
> the backend domain is not Dom0. While Dom0 is privileged and can do
> foreign mapping for the entire guest memory, it is still desired for
> Dom0 to access guest's memory via grant m
On 21.07.2023 00:12, Christopher Clark wrote:
> On Thu, Jul 13, 2023 at 11:51 PM Christopher Clark <
> christopher.w.cl...@gmail.com> wrote:
>
>>
>>
>> On Sat, Jul 8, 2023 at 11:47 AM Stefano Stabellini
>> wrote:
>>
>>> On Sat, 1 Jul 2023, Christopher Clark wrote:
To convert the x86 boot log
On 20.07.2023 18:14, Roger Pau Monné wrote:
> On Thu, Jul 20, 2023 at 06:03:49PM +0200, Jan Beulich wrote:
>> On 20.07.2023 02:32, Volodymyr Babchuk wrote:
>>> --- a/xen/drivers/vpci/msi.c
>>> +++ b/xen/drivers/vpci/msi.c
>>> @@ -190,6 +190,8 @@ static int cf_check init_msi(struct pci_dev *pdev)
>>
On 20.07.2023 23:01, Shawn Anastasio wrote:
> On 7/19/23 9:05 AM, Jan Beulich wrote:
>> Before you/we grow more assembly code, may I re-raise a request regarding
>> readability: I think it would be nice if operands started at a fixed column,
>> unless the insn mnemonic is unusually long. Where exac
On 19.07.2023 11:43, Jan Beulich wrote:
> In options like -march=, it may be only the sub-option which is
> unrecognized by the compiler. In such an event the error message often
> splits option and argument, typically saying something like "bad value
> '' for ''. Extend the grep invocation accordi
flight 181918 qemu-mainline real [real]
flight 181942 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181918/
http://logs.test-lab.xenproject.org/osstest/logs/181942/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
On 7/7/23 07:04, Rahul Singh wrote:
> Hi Stewart,
>
>> On 7 Jul 2023, at 2:47 am, Stewart Hildebrand
>> wrote:
>>
>> Remove is_hardware_domain check in has_vpci, and select
>> HAS_VPCI_GUEST_SUPPORT
>> in Kconfig.
>>
>> [1]
>> https://lists.xenproject.org/archives/html/xen-devel/2023-06/msg008
On 21.07.23 00:45, Julien Grall wrote:
Hi Juergen,
On 20/07/2023 16:08, Juergen Gross wrote:
In case get_spec_node() is being called for a special node starting
with '@' it won't set *canonical_name. This can result in a crash of
xenstored due to dereferencing the uninitialized name in
fire_wat
flight 181941 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181941/
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 Jan,
Jan Beulich writes:
> On 20.07.2023 02:32, Volodymyr Babchuk wrote:
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@ -46,6 +46,16 @@ void vpci_remove_device(struct pci_dev *pdev)
>> return;
>>
>> spin_lock(&pdev->vpci->lock);
>> +
>> +#ifdef CONFI
Hi Viresh,
kernel test robot noticed the following build errors:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on linus/master v6.5-rc2 next-20230720]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
From: Stefano Stabellini
Rule 1.1 is uncontroversial and we are already following it.
Rule 5.6 has been deemed a good rule to have by the MISRA C group.
However, we do have a significant amount of violations that will take
time to resolve and might require partial deviations in the form of
in-co
Hi Jan,
Jan Beulich writes:
> On 20.07.2023 02:32, Volodymyr Babchuk wrote:
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -476,8 +476,13 @@ static int cf_check reassign_device(
>>
>> if ( devfn == pdev->devfn && pdev->dom
On Thu, 20 Jul 2023, Petr Mladek wrote:
> On Wed 2023-07-19 18:46:08, Stefano Stabellini wrote:
> > On Wed, 19 Jul 2023, Petr Mladek wrote:
> > > On Fri 2022-05-13 14:19:38, Stefano Stabellini wrote:
> > > > From: Luca Miccio
> > > >
> > > > When running as dom0less guest (HVM domain on ARM) the
flight 181917 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181917/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 181890
test-armhf-armhf-libvirt-qcow2 15 saveres
On Thu, 20 Jul 2023, Julien Grall wrote:
> (+ Juergen)
>
> On 19/07/2023 17:13, Andrei Cherechesu (OSS) wrote:
> > Hello,
>
> Hi Andrei,
>
> > As we're running Xen 4.17 (with platform-related support added) on NXP S32G
> > SoCs (ARMv8), with a custom Linux distribution built through Yocto, and
>
Hi Roger,
Roger Pau Monné writes:
> On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
>> Add per-domain d->pci_lock that protects access to
>> d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
>> that underlying pdev will not disappear under feet. This is a
Hi Juergen,
On 20/07/2023 16:08, Juergen Gross wrote:
In case get_spec_node() is being called for a special node starting
with '@' it won't set *canonical_name. This can result in a crash of
xenstored due to dereferencing the uninitialized name in
fire_watches().
This is no security issue as it
On Sat, Jul 8, 2023 at 3:24 PM Stefano Stabellini
wrote:
> On Sat, 1 Jul 2023, Christopher Clark wrote:
> > Pointer fields within structs need to be defined as fixed size types in
> > the x86 boot build environment. Using a typedef for the field type
> > rather than a struct pointer type enables
On Thu, Jul 20, 2023 at 11:20:29PM +0200, Simone Ballarin wrote:
> +# ECLAIR configuration files are maintened by BUGSENG
> +export GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no"
> +[ -d ECLAIR_scripts ] || git clone
> ssh://g...@git.bugseng.com/eclair/scripts/XEN ECLAIR_scripts
> +(cd ECLAIR_s
On Sat, Jul 8, 2023 at 12:15 PM Stefano Stabellini
wrote:
> On Sat, 1 Jul 2023, Christopher Clark wrote:
> > Adjust the PV and PVH dom0 construction entry points to take boot module
> > structures as parameters, and add further fields to the boot module
> > structures to plumb the data needed to
Hi Juergen,
On 20/07/2023 16:04, Juergen Gross wrote:
The fix for XSA-417 had a bug: domain_alloc_permrefs() will not return
a negative value in case of an error, but a plain errno value.
Note this is not considered to be a security issue, as the only case
where domain_alloc_permrefs() will ret
On Thu, 20 Jul 2023, Simone Ballarin wrote:
> Add two pipelines that analyze an ARM64 and a X86_64 build with the
> ECLAIR static analyzer on the guidelines contained in Set1.
>
> The tool configuration is kept external to the xen repository for
> practical reasons, it will be included in a subseq
Hi Bertrand,
On 20/07/2023 11:20, Bertrand Marquis wrote:
Hi Jens,
On 17 Jul 2023, at 09:20, Jens Wiklander wrote:
Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
Partition in secure world.
This commit brings in only the parts needed to negotiate FF-A version
number with g
flight 181937 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181937/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c6b512962e92ae54a895bdfd2147abaf2c9e3e22
baseline version:
ovmf b2de9ec5a759aa4a7ac02
On 20/07/2023 11:00 pm, Julien Grall wrote:
> Hi Alejandro,
>
> Great work!
>
> On 17/07/2023 17:03, Alejandro Vallejo wrote:
>> Currently there's a CONFIG_HAS_PDX Kconfig option, but it's
>> impossible to
>> disable it because the whole codebase performs unconditional
>> compression/decompression
On Thu, Jul 13, 2023 at 11:51 PM Christopher Clark <
christopher.w.cl...@gmail.com> wrote:
>
>
> On Sat, Jul 8, 2023 at 11:47 AM Stefano Stabellini
> wrote:
>
>> On Sat, 1 Jul 2023, Christopher Clark wrote:
>> > To convert the x86 boot logic from multiboot to boot module structures,
>> > change t
On Sat, Jul 8, 2023 at 12:15 PM Stefano Stabellini
wrote:
> On Sat, 1 Jul 2023, Christopher Clark wrote:
> > Next step in incremental work towards adding a non-multiboot internal
> > representation of boot modules, converting the fields being accessed for
> > the startup calculations.
> >
> > Add
Hi Alejandro,
Great work!
On 17/07/2023 17:03, Alejandro Vallejo wrote:
Currently there's a CONFIG_HAS_PDX Kconfig option, but it's impossible to
disable it because the whole codebase performs unconditional
compression/decompression operations on addresses. This has the
unfortunate side effect
On Thu, 20 Jul 2023, Jan Beulich wrote:
> This is to avoid the need for forward declarations, which in turn
> addresses a violation of MISRA C:2012 Rule 8.3 ("All declarations of an
> object or function shall use the same names and type qualifiers").
>
> While doing so,
> - drop inline (leaving th
On Sat, Jul 8, 2023 at 11:30 AM Stefano Stabellini
wrote:
> On Sat, 1 Jul 2023, Christopher Clark wrote:
> > An initial step towards a non-multiboot internal representation of boot
> > modules for common code, starting with x86 setup and converting the
> > fields that are accessed for the startup
Add two pipelines that analyze an ARM64 and a X86_64 build with the
ECLAIR static analyzer on the guidelines contained in Set1.
The tool configuration is kept external to the xen repository for
practical reasons, it will be included in a subsequent phase.
All commits on the xen-project/xen:stagin
On 7/19/23 9:05 AM, Jan Beulich wrote:
> Before you/we grow more assembly code, may I re-raise a request regarding
> readability: I think it would be nice if operands started at a fixed column,
> unless the insn mnemonic is unusually long. Where exactly to draw the line
> is up to each archtecture;
flight 181914 qemu-upstream-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181914/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemuu-rhel6hvm-amd 12 redhat-install fail in 181865 pass in
181889
test-amd64-i3
Hi Alejandro,
On 17/07/2023 17:03, Alejandro Vallejo wrote:
arm32 merely covers the XENHEAP, whereas arm64 currently covers anything in
the frame table. These comments highlight why arm32 doesn't need to account for
PDX
compression in its __va() implementation while arm64 does.
Signed-off-by:
flight 181913 linux-linus real [real]
flight 181930 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181913/
http://logs.test-lab.xenproject.org/osstest/logs/181930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On Thu, Jul 20, 2023 at 06:03:49PM +0200, Jan Beulich wrote:
> On 20.07.2023 02:32, Volodymyr Babchuk wrote:
> > --- a/xen/drivers/vpci/msi.c
> > +++ b/xen/drivers/vpci/msi.c
> > @@ -190,6 +190,8 @@ static int cf_check init_msi(struct pci_dev *pdev)
> > uint16_t control;
> > int ret;
> >
On 20.07.2023 02:32, Volodymyr Babchuk wrote:
> @@ -431,10 +447,23 @@ static void vpci_write_helper(const struct pci_dev
> *pdev,
> r->private);
> }
>
> +/* Helper function to unlock locks taken by vpci_write in proper order */
> +static void unlock_locks(struct domain *d)
> +{
>
On 20.07.2023 02:32, Volodymyr Babchuk wrote:
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -190,6 +190,8 @@ static int cf_check init_msi(struct pci_dev *pdev)
> uint16_t control;
> int ret;
>
> +ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
I'm afraid I
On Thu, Jul 20, 2023 at 12:32:32AM +, Volodymyr Babchuk wrote:
> From: Oleksandr Andrushchenko
>
> Add relevant vpci register handlers when assigning PCI device to a domain
> and remove those when de-assigning. This allows having different
> handlers for different domains, e.g. hwdom and othe
If the value is always initialized in the callee, then there's no
problem configuring ECLAIR so that it knows that this parameter is
always written, and therefore any subsequent use in the caller is ok.
Another possibility is stating that a function never reads the
pointee before writing to
Hi Nicola,
On 20/07/2023 15:29, Nicola Vetrini wrote:
The local variables with type 'struct arm_smccc_res' are initialized
just after the declaration to avoid any possible read usage prior
to any write usage, which would constitute a violation of
MISRA C:2012 Rule 9.1.
This is already prevented
On 20.07.2023 13:20, Roger Pau Monné wrote:
> On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
>> @@ -318,14 +323,17 @@ void vpci_dump_msi(void)
>> * holding the lock.
>> */
Note the comment here.
>> printk("unable
On 20/07/23 17:39, Julien Grall wrote:
Hi,
The e-mail is getting quite long. Can you trim the unnecessary bits when
replying?
Ok.
On 20/07/2023 15:23, Nicola Vetrini wrote:
The problem is that _t may be uninitialized, hence assigning its
address to t could be problematic.
But the va
On 20.07.2023 02:32, Volodymyr Babchuk wrote:
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -476,8 +476,13 @@ static int cf_check reassign_device(
>
> if ( devfn == pdev->devfn && pdev->domain != target )
> {
> -list
Hi,
The e-mail is getting quite long. Can you trim the unnecessary bits when
replying?
On 20/07/2023 15:23, Nicola Vetrini wrote:
The problem is that _t may be uninitialized, hence assigning its
address to t could be problematic.
But the value is set right after. IOW, there is no read betwe
Hi Nicola,
On 20/07/2023 11:14, Nicola Vetrini wrote:
On 17/07/23 15:40, Julien Grall wrote:
Hi Nicola,
On 17/07/2023 13:08, Nicola Vetrini wrote:
On 14/07/23 15:00, Julien Grall wrote:
Hi Nicola,
On 14/07/2023 12:49, Nicola Vetrini wrote:
This patch aims to fix some occurrences of possi
On 20.07.2023 02:23, Stefano Stabellini wrote:
> On Wed, 19 Jul 2023, Nicola Vetrini wrote:
>> MISRA C:2012 Rule 4.1 has the following headline:
>> "Octal and hexadecimal escape sequences shall be terminated."
>>
>> The string literals modified by this patch contain octal or
>> hexadecimal escape s
In case get_spec_node() is being called for a special node starting
with '@' it won't set *canonical_name. This can result in a crash of
xenstored due to dereferencing the uninitialized name in
fire_watches().
This is no security issue as it requires either a privileged caller or
ownership of the
On Thu, Jul 20, 2023 at 02:33:34PM +0200, Federico Serafini wrote:
> Change parameter types of function declarations to be consistent with
> the ones used in the corresponding definitions,
> thus addressing violations of MISRA C:2012 Rule 8.3 ("All declarations
> of an object or function shall use
The fix for XSA-417 had a bug: domain_alloc_permrefs() will not return
a negative value in case of an error, but a plain errno value.
Note this is not considered to be a security issue, as the only case
where domain_alloc_permrefs() will return an error is a failed memory
allocation. As a guest sh
On 20.07.2023 09:53, Federico Serafini wrote:
> Give a name to unnamed parameters thus addressing violations of
> MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
> named parameters").
> Keep consistency between parameter names and types used in function
> declarations and the
The local variables with type 'struct arm_smccc_res' are initialized
just after the declaration to avoid any possible read usage prior
to any write usage, which would constitute a violation of
MISRA C:2012 Rule 9.1.
This is already prevented by suitable checks in the code,
but the correctness of t
On Thu, 2023-07-20 at 16:06 +0200, Jan Beulich wrote:
> On 20.07.2023 15:34, Oleksii wrote:
> > On Thu, 2023-07-20 at 12:29 +0200, Jan Beulich wrote:
> > > On 20.07.2023 10:28, Oleksii wrote:
> > > > On Thu, 2023-07-20 at 07:58 +0200, Jan Beulich wrote:
> > > > > On 19.07.2023 18:35, Oleksii wrote:
On 20/07/23 12:14, Nicola Vetrini wrote:
On 17/07/23 15:40, Julien Grall wrote:
Hi Nicola,
On 17/07/2023 13:08, Nicola Vetrini wrote:
On 14/07/23 15:00, Julien Grall wrote:
Hi Nicola,
On 14/07/2023 12:49, Nicola Vetrini wrote:
This patch aims to fix some occurrences of possibly uniniti
On 20.07.2023 15:34, Oleksii wrote:
> On Thu, 2023-07-20 at 12:29 +0200, Jan Beulich wrote:
>> On 20.07.2023 10:28, Oleksii wrote:
>>> On Thu, 2023-07-20 at 07:58 +0200, Jan Beulich wrote:
On 19.07.2023 18:35, Oleksii wrote:
> Then we will have completely different L0 tables for identity
>
On Thu, Jul 20, 2023 at 03:27:29PM +0200, Jan Beulich wrote:
> On 20.07.2023 13:20, Roger Pau Monné wrote:
> > On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
> >> @@ -447,8 +476,16 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg,
> >> unsigned int size,
> >>
> >> /*
flight 181904 xen-unstable real [real]
flight 181925 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181904/
http://logs.test-lab.xenproject.org/osstest/logs/181925/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Thu, 2023-07-20 at 12:29 +0200, Jan Beulich wrote:
> On 20.07.2023 10:28, Oleksii wrote:
> > On Thu, 2023-07-20 at 07:58 +0200, Jan Beulich wrote:
> > > On 19.07.2023 18:35, Oleksii wrote:
> > > > On Tue, 2023-07-18 at 17:03 +0200, Jan Beulich wrote:
> > > > > > + unsigned long load_e
On 20.07.2023 13:20, Roger Pau Monné wrote:
> On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
>> @@ -447,8 +476,16 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg,
>> unsigned int size,
>>
>> /*
>> * Find the PCI dev matching the address, which for hwdom also r
On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
> From: Oleksandr Andrushchenko
>
> When a PCI device gets assigned/de-assigned some work on vPCI side needs
> to be done for that device. Introduce a pair of hooks so vPCI can handle
> that.
>
> Signed-off-by: Oleksandr Andrushc
On 20/07/23 14:15, Roger Pau Monné wrote:
On Thu, Jul 20, 2023 at 12:48:36PM +0200, Federico Serafini wrote:
+extern uint32_t get_pat_flags(struct vcpu *v, uint32_t gl1e_flags,
+ paddr_t gpaddr, paddr_t spaddr,
+
Change parameter types of function declarations to be consistent with
the ones used in the corresponding definitions,
thus addressing violations of MISRA C:2012 Rule 8.3 ("All declarations
of an object or function shall use the same names and type qualifiers").
No functional changes.
Signed-off-b
On Thu, Jul 20, 2023 at 12:48:36PM +0200, Federico Serafini wrote:
> Change parameter types of function declarations to be consistent with
> the ones used in the corresponding definitions,
> thus addressing violations of MISRA C:2012 Rule 8.3 ("All declarations
> of an object or function shall use
After suspending and resuming guest VM, you will get
a black screen, and the display can't come back.
This is because when guest did suspending, it called
into qemu to call virtio_gpu_gl_reset. In function
virtio_gpu_gl_reset, it destroyed resources and reset
renderer, which were used for display.
v4:
Hi all,
Thanks for Gerd Hoffmann's advice. V4 makes below changes:
* Use enum for freeze mode, so this can be extended with more
modes in the future.
* Rename functions and paratemers with "_S3" postfix.
And no functional changes.
latest version on kernel side:
https://lore.kernel.org/lkml/
This patch solves two problem:
First, when we suspended guest VM, it called into Qemu to call
virtio_reset->__virtio_queue_reset, this cleared all virtuqueue
information of virtgpu on Qemu end. As a result, after guest
resumed, guest sended ctrl/cursor requests to Qemu through
virtqueue, but Qemu
v3:
Hi all,
Thanks for Gerd Hoffmann's advice. V3 makes below changes:
* Use enum for freeze mode, so this can be extended with more
modes in the future.
* Rename functions and paratemers with "_S3" postfix.
And no functional changes.
Best regards,
Jiqian Chen.
v2:
Hi all,
Thanks to Marc-Andr
On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
> From: Oleksandr Andrushchenko
>
> A guest would be able to read and write those registers which are not
> emulated and have no respective vPCI handlers, so it will be possible
> for it to access the hardware directly.
> In order
flight 181923 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181923/
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 Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
> From: Oleksandr Andrushchenko
>
> Use a previously introduced per-domain read/write lock to check
> whether vpci is present, so we are sure there are no accesses to the
> contents of the vpci struct if not. This lock can be used
flight 181922 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181922/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b2de9ec5a759aa4a7ac029cda9079dce077bf856
baseline version:
ovmf 6510dcf6f71adbe282bff
On 20/07/2023 8:11 am, Jan Beulich wrote:
> This is to avoid the need for forward declarations, which in turn
> addresses a violation of MISRA C:2012 Rule 8.3 ("All declarations of an
> object or function shall use the same names and type qualifiers").
>
> While doing so,
> - drop inline (leaving t
Change parameter types of function declarations to be consistent with
the ones used in the corresponding definitions,
thus addressing violations of MISRA C:2012 Rule 8.3 ("All declarations
of an object or function shall use the same names and type qualifiers").
No functional changes.
Signed-off-b
(+ Juergen)
On 19/07/2023 17:13, Andrei Cherechesu (OSS) wrote:
Hello,
Hi Andrei,
As we're running Xen 4.17 (with platform-related support added) on NXP S32G
SoCs (ARMv8), with a custom Linux distribution built through Yocto, and we've
set some Xen-based demos up, we encountered some issue
On 20.07.2023 10:28, Oleksii wrote:
> On Thu, 2023-07-20 at 07:58 +0200, Jan Beulich wrote:
>> On 19.07.2023 18:35, Oleksii wrote:
>>> On Tue, 2023-07-18 at 17:03 +0200, Jan Beulich wrote:
> + unsigned long load_end = LINK_TO_LOAD(_end);
> + unsigned long pt_level_size
On 19.07.2023 14:28, Jan Beulich wrote:
> On 19.07.2023 12:04, Andrew Cooper wrote:
>> On 19/07/2023 10:44 am, Jan Beulich wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -118,6 +118,36 @@ config HVM
>>>
>>> If unsure, say Y.
>>>
>>> +choice
>>> + prompt "bas
Hi Jens,
> On 17 Jul 2023, at 09:20, Jens Wiklander wrote:
>
> Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
> Partition in secure world.
>
> This commit brings in only the parts needed to negotiate FF-A version
> number with guest and SPMC.
>
> [1] https://developer.arm.co
On Wed 2023-07-19 18:46:08, Stefano Stabellini wrote:
> On Wed, 19 Jul 2023, Petr Mladek wrote:
> > On Fri 2022-05-13 14:19:38, Stefano Stabellini wrote:
> > > From: Luca Miccio
> > >
> > > When running as dom0less guest (HVM domain on ARM) the xenstore event
> > > channel is available at domain
On 17/07/23 15:40, Julien Grall wrote:
Hi Nicola,
On 17/07/2023 13:08, Nicola Vetrini wrote:
On 14/07/23 15:00, Julien Grall wrote:
Hi Nicola,
On 14/07/2023 12:49, Nicola Vetrini wrote:
This patch aims to fix some occurrences of possibly uninitialized
variables, that may be read before be
On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
> Add per-domain d->pci_lock that protects access to
> d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
> that underlying pdev will not disappear under feet. This is a rw-lock,
> but this patch adds only write_l
On 13-07-23, 14:40, Oleksandr Tyshchenko wrote:
> Viresh, great work!
Thanks Oleksandr.
> Do you perhaps have corresponding users-space (virtio backend) example
> adopted for that feature (I would like to take a look at it if possible)?
This is taken care by the xen-vhost-frontend Rust crate in
Xen provides support for injecting interrupts to the guests via the
HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
device backend implementations, in an inefficient manner currently.
Generally, the Virtio backends are implemented to work with the Eventfd
based mechanism. In ord
Update the definitions in dm_op.h from Xen public header.
Signed-off-by: Viresh Kumar
---
V1->V2:
- New commit.
include/xen/interface/hvm/dm_op.h | 445 ++
1 file changed, 445 insertions(+)
diff --git a/include/xen/interface/hvm/dm_op.h
b/include/xen/interface/hvm/
Hi,
On 18/07/2023 18:35, Stewart Hildebrand wrote:
On 7/13/23 14:40, Julien Grall wrote:
Hi Stewart,
On 07/07/2023 02:47, Stewart Hildebrand wrote:
From: Rahul Singh
Setting CONFIG_PCI_PASSTHROUGH=y will enable PCI passthrough on ARM, even though
the feature is not yet complete in the curre
On Thu, 2023-07-20 at 07:58 +0200, Jan Beulich wrote:
> On 19.07.2023 18:35, Oleksii wrote:
> > On Tue, 2023-07-18 at 17:03 +0200, Jan Beulich wrote:
> > > > + unsigned long load_end = LINK_TO_LOAD(_end);
> > > > + unsigned long pt_level_size = XEN_PT_LEVEL_SIZE(i
> > > > -
>
Introduce support for handling MSR features in
libxl_cpuid_parse_config(). The MSR policies are added to the
libxl_cpuid_policy like the CPUID one, which gets passed to
xc_cpuid_apply_policy().
This allows existing users of libxl to provide MSR related features as
key=value pairs to libxl_cpuid_p
The current implementation in libxl_cpuid_parse_config() requires
keeping a list of cpuid feature bits that should be mostly in sync
with the contents of cpufeatureset.h.
Avoid such duplication by using the automatically generated list of
cpuid features in INIT_FEATURE_NAMES in order to map featur
Move the CPUID value parsers out of libxl_cpuid_parse_config() into a
newly created cpuid_add() local helper. This is in preparation for
also adding MSR feature parsing support.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Anthony PERARD
---
tools/libs/light/libx
Add a new array field to libxl_cpuid_policy in order to store the MSR
policies.
Adding the MSR data in the libxl_cpuid_policy_list type is done so
that existing users can seamlessly pass MSR features as part of the
CPUID data, without requiring the introduction of a separate
domain_build_info fiel
Currently libxl_cpuid_policy_list is an opaque type to the users of
libxl, and internally it's an array of xc_xend_cpuid objects.
Change the type to instead be a structure that contains one array for
CPUID policies, in preparation for it also holding another array for
MSR policies.
Signed-off-by:
Like it's done with CPUID, introduce support for passing MSR values to
xc_cpuid_apply_policy(). The chosen format for expressing MSR policy
data matches the current one used for CPUID. Note that existing
callers of xc_cpuid_apply_policy() can pass NULL as the value for the
newly introduced 'msr'
Hello,
The following series adds support for handling guest MSR features as
defined in arch-x86/cpufeatureset.h.
The end result is the user being able to use such features with the
xl.cfg(5) cpuid option. This also involves adding support to all the
underlying layers, so both libxl and libxc als
On Thu, Jul 20, 2023 at 10:13:20AM +0200, Petr Tesařík wrote:
> Fine with me. I removed it after all my testing showed no performance
> impact as long as the size of the initial SWIOTLB is kept at the
> default value (and sufficient for the workload), but it's OK for me if
> dynamic SWIOTLB allocat
On Thu, Jul 20, 2023 at 10:02:38AM +0200, Petr Tesařík wrote:
> On Thu, 20 Jul 2023 08:47:44 +0200
> Christoph Hellwig wrote:
>
> > Any reason this can't just do a list_empty_careful on the list
> > instead of adding yet another field that grows struct device?
>
> On which list?
dev->dma_io_tlb
1 - 100 of 113 matches
Mail list logo
