Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 35 ---
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 16
1 file
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
drivers/of/address.c| 33 +
Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at
Add the functions, swiotlb_{alloc,free} and is_swiotlb_for_alloc to
support the memory allocation from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
v14: https://lore.kernel.org/patchwork/cover/1448954/
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/iommu/dma-iommu.c | 12
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/base/core.c| 4
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 50
flight 162889 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
flight 162887 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On 18/06/2021 12:48, Jan Beulich wrote:
> On 18.06.2021 12:14, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
>>> patch set is being split into two separate patch sets. This is the first
>>> patch set and
On 18/06/2021 13:26, Jan Beulich wrote:
> On 18.06.2021 01:39, Daniel P. Smith wrote:
>> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
>> and !CONFIG_XSM_FLASK
>> is whether the XSM hooks in dummy.h are called as static inline functions or
>> as function
>>
On 6/18/21 8:26 AM, Jan Beulich wrote:
> On 18.06.2021 01:39, Daniel P. Smith wrote:
>> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
>> and !CONFIG_XSM_FLASK
>> is whether the XSM hooks in dummy.h are called as static inline functions or
>> as function
>> pointers
> On Jun 18, 2021, at 7:28 PM, George Dunlap wrote:
>
>
>
>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>>
>> Add a helper function to wait for domain death events, and then write
>> the events to a provided channel. This handles the enabling/disabling of
>> the event type, freeing
flight 162885 xen-unstable real [real]
flight 162893 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162885/
http://logs.test-lab.xenproject.org/osstest/logs/162893/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add a helper function to wait for domain death events, and then write
> the events to a provided channel. This handles the enabling/disabling of
> the event type, freeing the event, and converting it to a Go type. The
> caller can then
> On Jun 18, 2021, at 6:00 PM, Nick Rosbrook wrote:
>
> On Fri, Jun 18, 2021 at 04:18:44PM +, George Dunlap wrote:
>>
>>
>>> On Jun 18, 2021, at 4:08 PM, Nick Rosbrook wrote:
>>>
>>> On Fri, Jun 18, 2021 at 02:44:15PM +, George Dunlap wrote:
> On May 24, 2021, at
On 18/06/2021 18:15, Igor Druzhinin wrote:
On 18/06/2021 17:00, Jan Beulich wrote:
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
On 18/06/2021 17:00, Jan Beulich wrote:
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
address space, though.
From "Open-Source
On 18/06/2021 14:46, Edwin Torok wrote:
>> On 18 Jun 2021, at 14:17, Andrew Cooper wrote:
>>
>> On 18/06/2021 11:45, Edwin Török wrote:
>>> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
>>> b/tools/ocaml/libs/xc/xenctrl_stubs.c
>>> index d05d7bb30e..4a230de8b7 100644
>>> ---
On Fri, Jun 18, 2021 at 04:18:44PM +, George Dunlap wrote:
>
>
> > On Jun 18, 2021, at 4:08 PM, Nick Rosbrook wrote:
> >
> > On Fri, Jun 18, 2021 at 02:44:15PM +, George Dunlap wrote:
> >>
> >>
> >>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >>>
> >>> Add a ContextOption
flight 162888 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162888/
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
Am Fri, 18 Jun 2021 17:46:47 +0100
schrieb Andrew Cooper :
> On 18/06/2021 17:42, Olaf Hering wrote:
> > Fixes commit fa5afbbc20ef3577c5338f9d0b24dad45cef59cd,
> > due to lack of commit 534519f0514f52007d504e0f2eeb714de7b2468d.
> Presumably you're intending this for Xen 4.13 and older?
On 18/06/2021 17:42, Olaf Hering wrote:
> Fixes commit fa5afbbc20ef3577c5338f9d0b24dad45cef59cd,
> due to lack of commit 534519f0514f52007d504e0f2eeb714de7b2468d.
>
> Signed-off-by: Olaf Hering
Presumably you're intending this for Xen 4.13 and older?
~Andrew
Fixes commit fa5afbbc20ef3577c5338f9d0b24dad45cef59cd,
due to lack of commit 534519f0514f52007d504e0f2eeb714de7b2468d.
Signed-off-by: Olaf Hering
---
xen/include/xen/compiler.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
On 6/18/21 8:44 AM, Jan Beulich wrote:
> On 18.06.2021 14:40, Jan Beulich wrote:
>> On 18.06.2021 14:03, Andrew Cooper wrote:
>>> On 18/06/2021 00:39, Daniel P. Smith wrote:
diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
index 7e2bb09dac..0f8ea163af 100644
--- a/xen/xsm/dummy.h
On 6/18/21 8:03 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
>> index 7e2bb09dac..0f8ea163af 100644
>> --- a/xen/xsm/dummy.h
>> +++ b/xen/xsm/dummy.h
>> @@ -9,7 +9,7 @@
>> *
>> *
>> * Each XSM hook implementing an
On 6/18/21 7:56 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> With the conversion of making XSM always enabled even the dummy XSM module is
>> being invoked through the xsm_ops dispatch which does not use passing of the
>> default privilege. This commit removes the
On 6/18/21 7:53 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
>> and !CONFIG_XSM_FLASK
>> is whether the XSM hooks in dummy.h are called as static inline functions or
>> as function
>>
> On Jun 18, 2021, at 4:17 PM, Nick Rosbrook wrote:
>
> On Fri, Jun 18, 2021 at 01:17:07PM +, George Dunlap wrote:
>> Also, is ‘xenlight’ informative enough? I haven’t looked at the other
>> “context” strings; would “go-xenlight” or something be better?
>>
>
> I believe libxl uses
On 18/06/2021 17:00, Jan Beulich wrote:
> At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
> address range") documentation correctly stated that the range was
> completely fixed. For Fam17 and newer, it lives at the top of physical
> address space, though.
>
> To correctly
> On Jun 18, 2021, at 4:26 PM, Nick Rosbrook wrote:
>
> On Fri, Jun 18, 2021 at 01:21:40PM +, George Dunlap wrote:
>>
>>
>>> On Jun 18, 2021, at 2:17 PM, George Dunlap wrote:
>>>
>>>
>>>
On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
Add some logging methods to
On 6/18/21 7:44 AM, Jan Beulich wrote:
> On 18.06.2021 13:34, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> @@ -197,16 +204,21 @@ bool __init has_xsm_magic(paddr_t start)
>>>
>>> int __init register_xsm(struct xsm_operations *ops)
>>> {
>>> -if ( verify(ops) )
>>>
> On Jun 18, 2021, at 4:08 PM, Nick Rosbrook wrote:
>
> On Fri, Jun 18, 2021 at 02:44:15PM +, George Dunlap wrote:
>>
>>
>>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>>>
>>> Add a ContextOption type to support functional options in NewContext.
>>> Then, add a variadic
On 6/18/21 7:34 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> The assignment and setup of xsm_ops structure was refactored to make it a
>> one-time assignment. The calling of the xsm_ops were refactored to use the
>> alternate_call framework to reduce the need for
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
address space, though.
To correctly determine the top of physical address space, we need to
On 6/18/21 6:14 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
>> patch set is being split into two separate patch sets. This is the first
>> patch set and is focused purely on the clean up and
On 18.06.2021 17:24, Andrew Cooper wrote:
> On 18/06/2021 16:22, Andrew Cooper wrote:
>> On 18/06/2021 16:06, Andrew Cooper wrote:
>>> On 18/06/2021 11:25, Jan Beulich wrote:
libxc generally uses uint32_t to represent domain IDs. This is fine as
long as addresses of such variables aren't
Am Fri, 18 Jun 2021 10:42:58 +0100
schrieb Andrew Cooper :
> This is a Py2 vs Py3 difference.
This script is not ready for python 3.
At a first glance it is the usual type confusion.
It seems the type 'bytearray' exists in both variants.
Perhaps stream_read() should return such an object,
On Fri, Jun 18, 2021 at 03:13:03PM +, George Dunlap wrote:
>
>
> > On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >
> > There are several locations where the return code from calling into C is
> > negated when being converted to Error. This results in error strings
> > like "libxl
On 18.06.2021 17:05, Andrew Cooper wrote:
> On 18/06/2021 11:24, Jan Beulich wrote:
>> Some sub-functions, XENMEM_maximum_gpfn in particular, can return values
>> requiring more than 31 bits to represent. Hence we cannot issue the
>> hypercall directly when the return value of ioctl() is used to
On Fri, Jun 18, 2021 at 01:21:40PM +, George Dunlap wrote:
>
>
> > On Jun 18, 2021, at 2:17 PM, George Dunlap wrote:
> >
> >
> >
> >> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >>
> >> Add some logging methods to Context to provide easy use of the
> >> Contenxt's
On 18/06/2021 16:22, Andrew Cooper wrote:
> On 18/06/2021 16:06, Andrew Cooper wrote:
>> On 18/06/2021 11:25, Jan Beulich wrote:
>>> libxc generally uses uint32_t to represent domain IDs. This is fine as
>>> long as addresses of such variables aren't taken, to then pass into
>>> hypercalls: To the
On 18/06/2021 16:06, Andrew Cooper wrote:
> On 18/06/2021 11:25, Jan Beulich wrote:
>> libxc generally uses uint32_t to represent domain IDs. This is fine as
>> long as addresses of such variables aren't taken, to then pass into
>> hypercalls: To the hypervisor, a domain ID is a 16-bit value. Use
On Fri, Jun 18, 2021 at 01:17:07PM +, George Dunlap wrote:
>
>
> > On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >
> > Add some logging methods to Context to provide easy use of the
> > Contenxt's xentoollog_logger. These are not exported, but the LogLevel
> > type is so that a later
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> There are several locations where the return code from calling into C is
> negated when being converted to Error. This results in error strings
> like "libxl error: ", rather than the correct message. Fix all
> occurrances of this by
On Fri, Jun 18, 2021 at 02:44:15PM +, George Dunlap wrote:
>
>
> > On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >
> > Add a ContextOption type to support functional options in NewContext.
> > Then, add a variadic ContextOption parameter to NewContext, which allows
> > callers to
On 18/06/2021 11:25, Jan Beulich wrote:
> libxc generally uses uint32_t to represent domain IDs. This is fine as
> long as addresses of such variables aren't taken, to then pass into
> hypercalls: To the hypervisor, a domain ID is a 16-bit value. Use an
> intermediate variable to deal with the
On 18/06/2021 11:24, Jan Beulich wrote:
> Some sub-functions, XENMEM_maximum_gpfn in particular, can return values
> requiring more than 31 bits to represent. Hence we cannot issue the
> hypercall directly when the return value of ioctl() is used to propagate
> this value (note that this is not
On 18.06.2021 15:46, Andrew Cooper wrote:
> On 18/06/2021 11:24, Jan Beulich wrote:
>> Some hypercalls, memory-op in particular, can return values requiring
>> more than 31 bits to represent. Hence the underlying layers need to make
>> sure they won't truncate such values.
>>
>> While adding the
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add a warpper around libxl_send_trigger.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add a wrapper around libxl_domain_destroy.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
On 14.05.2021 22:54, Daniel P. Smith wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -169,13 +169,14 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
> static inline struct vcpu *choose_hwdom_vcpu(void)
> {
> unsigned idx;
> +struct domain *hwdom =
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add a ContextOption type to support functional options in NewContext.
> Then, add a variadic ContextOption parameter to NewContext, which allows
> callers to specify 0 or more configuration options.
>
> For now, just add the
On Fri, Jun 18, 2021 at 09:09:17AM -0500, Tom Lendacky wrote:
> > swiotlb_init_with_tbl uses memblock_alloc to allocate the io_tlb_mem
> > and memblock_alloc[1] will do memset in memblock_alloc_try_nid[2], so
> > swiotlb_init_with_tbl is also good.
> > I'm happy to add the memset in
On 14.05.2021 22:54, Daniel P. Smith wrote:
In the title, did you mean just one of "convert" or "rewrite", or
did you omit some punctuation?
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -475,6 +475,12 @@ struct domain
> #define XSM_XENSTORE (1U<<31) /* Xenstore: domain
On 6/18/21 1:25 AM, Claire Chang wrote:
> On Fri, Jun 18, 2021 at 7:30 AM Stefano Stabellini
> wrote:
>>
>> On Thu, 17 Jun 2021, Claire Chang wrote:
>>> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
>>> initialization to make the code reusable.
>>>
>>> Signed-off-by:
On 14.05.2021 22:54, Daniel P. Smith wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -556,6 +556,9 @@ struct domain *domain_create(domid_t domid,
> /* Sort out our idea of is_control_domain(). */
> d->is_privileged = is_priv;
With the change to is_control_domain()
On 14.05.2021 22:54, Daniel P. Smith wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -457,6 +457,24 @@ struct domain
> */
> bool creation_finished;
>
> +/* When SILO or Flask are not in use, a domain may have one or more roles
> + * that
> On 18 Jun 2021, at 14:17, Andrew Cooper wrote:
>
> On 18/06/2021 11:45, Edwin Török wrote:
>> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
>> b/tools/ocaml/libs/xc/xenctrl_stubs.c
>> index d05d7bb30e..4a230de8b7 100644
>> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
>> +++
On 18/06/2021 11:24, Jan Beulich wrote:
> Some hypercalls, memory-op in particular, can return values requiring
> more than 31 bits to represent. Hence the underlying layers need to make
> sure they won't truncate such values.
>
> While adding the new function to the map file, I noticed the stray
> On 18 Jun 2021, at 14:09, Christian Lindig
> wrote:
>
>
>
>> On 18 Jun 2021, at 11:45, Edwin Török wrote:
>>
>> Introduces following functions in Xenctrl and associated types:
>> get_system_cpu_policy
>> cpu_policy_to_featureset,
>> string_of_xen_cpu_policy_index
>>
>> These are
On 18.06.2021 15:26, Andrew Cooper wrote:
> On 18/06/2021 11:23, Jan Beulich wrote:
>> Some hypercalls, memory-op in particular, can return values requiring
>> more than 31 bits to represent. Hence the underlying layers need to make
>> sure they won't truncate such values. (Note that for Solaris
On 18/06/2021 11:23, Jan Beulich wrote:
> Some hypercalls, memory-op in particular, can return values requiring
> more than 31 bits to represent. Hence the underlying layers need to make
> sure they won't truncate such values. (Note that for Solaris the
> function also gets renamed, to match the
> On Jun 18, 2021, at 2:17 PM, George Dunlap wrote:
>
>
>
>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>>
>> Add some logging methods to Context to provide easy use of the
>> Contenxt's xentoollog_logger. These are not exported, but the LogLevel
>> type is so that a later commit
On 18/06/2021 11:45, Edwin Török wrote:
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index d05d7bb30e..4a230de8b7 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -34,6 +34,9 @@
> #include
>
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add some logging methods to Context to provide easy use of the
> Contenxt's xentoollog_logger. These are not exported, but the LogLevel
> type is so that a later commit can allow the Context's log level to be
> configurable.
>
> Becuase
On 18.06.2021 15:02, Andrew Cooper wrote:
> On 18/06/2021 11:23, Jan Beulich wrote:
>> To be able to use them from, in particular, the tool stack, they need to
>> be supported for all guest types. Note that xc_resource_op() already
>> does, so would not work without this on PVH Dom0.
>
> I'm not
On 18 Jun 2021, at 11:45, Edwin Török
mailto:edvin.to...@citrix.com>> wrote:
Introduces following functions in Xenctrl and associated types:
get_system_cpu_policy
cpu_policy_to_featureset,
string_of_xen_cpu_policy_index
These are wrappers around the existing C functions in xenctrl.h,
that
flight 162886 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162886/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 3e800027016ea4eb19887bf626b46f45fc43fa5d
baseline version:
xtf
As to the title, xc_maximum_ram_page() is similarly affected. Plus,
perhaps less worrying, xc_sharing_{freed,used}_pages().
Jan
On 18/06/2021 11:23, Jan Beulich wrote:
> To be able to use them from, in particular, the tool stack, they need to
> be supported for all guest types. Note that xc_resource_op() already
> does, so would not work without this on PVH Dom0.
I'm not a fan of multicalls as a concept - they're mostly a
On 18.06.2021 14:40, Jan Beulich wrote:
> On 18.06.2021 14:03, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
>>> index 7e2bb09dac..0f8ea163af 100644
>>> --- a/xen/xsm/dummy.h
>>> +++ b/xen/xsm/dummy.h
>>> @@ -9,7 +9,7 @@
>>>
On 18.06.2021 14:03, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
>> index 7e2bb09dac..0f8ea163af 100644
>> --- a/xen/xsm/dummy.h
>> +++ b/xen/xsm/dummy.h
>> @@ -9,7 +9,7 @@
>> *
>> *
>> * Each XSM hook implementing an
On 18.06.2021 01:39, Daniel P. Smith wrote:
> With the conversion of making XSM always enabled even the dummy XSM module is
> being invoked through the xsm_ops dispatch which does not use passing of the
> default privilege. This commit removes the xen_default_t parameter from the
> hook
>
On 18.06.2021 01:39, Daniel P. Smith wrote:
> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
> and !CONFIG_XSM_FLASK
> is whether the XSM hooks in dummy.h are called as static inline functions or
> as function
> pointers to static functions. As such this commit,
>
Am Wed, 2 Jun 2021 08:59:13 +0200
schrieb Juergen Gross :
> > @@ -152,9 +152,8 @@ int populate_pfns(struct xc_sr_context *ctx, unsigned
> > int count,
> >
> > for ( i = 0; i < count; ++i )
> > {
> > -if ( (!types || (types &&
> > - (types[i] !=
Hi, all!
What do we need in order to move on on this?
It seems this can be good to have for many use-cases around
Thank you,
Oleksandr
On 20.05.21 19:21, Stefano Stabellini wrote:
On Thu, 20 May 2021, Julien Grall wrote:
On 20/05/2021 00:25, Stefano Stabellini wrote:
On Sat, 15 May 2021,
On 18/06/2021 00:39, Daniel P. Smith wrote:
> diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
> index 7e2bb09dac..0f8ea163af 100644
> --- a/xen/xsm/dummy.h
> +++ b/xen/xsm/dummy.h
> @@ -9,7 +9,7 @@
> *
> *
> * Each XSM hook implementing an access check should have its first
> parameter
> -
On 18/06/2021 00:39, Daniel P. Smith wrote:
> With the conversion of making XSM always enabled even the dummy XSM module is
> being invoked through the xsm_ops dispatch which does not use passing of the
> default privilege. This commit removes the xen_default_t parameter from the
> hook
>
On 18/06/2021 00:39, Daniel P. Smith wrote:
> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
> and !CONFIG_XSM_FLASK
> is whether the XSM hooks in dummy.h are called as static inline functions or
> as function
> pointers to static functions. As such this commit,
>
flight 162884 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162884/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
On 18.06.2021 12:14, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
>> patch set is being split into two separate patch sets. This is the first
>> patch set and is focused purely on the clean up and
On 18/06/2021 12:44, Jan Beulich wrote:
> On 18.06.2021 13:34, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> @@ -197,16 +204,21 @@ bool __init has_xsm_magic(paddr_t start)
>>>
>>> int __init register_xsm(struct xsm_operations *ops)
>>> {
>>> -if ( verify(ops) )
On 18.06.2021 13:34, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> @@ -197,16 +204,21 @@ bool __init has_xsm_magic(paddr_t start)
>>
>> int __init register_xsm(struct xsm_operations *ops)
>> {
>> -if ( verify(ops) )
>> +if ( xsm_ops_registered !=
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> As a matter of style, it is strange to see capitalized receiver names,
> due to the significance of capitalized symbols in Go (although there is
> in fact nothing special about a capitalized receiver name). Fix this in
> xenlight.go by
On 18/06/2021 00:39, Daniel P. Smith wrote:
> The assignment and setup of xsm_ops structure was refactored to make it a
> one-time assignment. The calling of the xsm_ops were refactored to use the
> alternate_call framework to reduce the need for retpolines.
>
> Signed-off-by: Daniel P. Smith
I
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Currently, when marshalig Go types with keyed union fields, we assign the
> value of the struct (e.g. DomainBuildInfoTypeUnionHvm) which implements the
> interface of the keyed union field (e.g. DomainBuildInfoTypeUnion).
> As-is, this
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> For structs that have a keyed union, e.g. DomainBuildInfo, the TypeUnion
> field must be exported so that package users can get/set the fields
> within. This means that users are aware of the existence of the
> interface type used in
flight 162881 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162881/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162547
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> In gengotypes.py, the toC functions only set C string fields when
> the Go strings are non-empty. However, to prevent segfaults in some
> cases, these fields should always at least be set to nil so that the C
> memory is zeroed out.
>
>
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> The current implementation of StringList.toC does not correctly account
> for how libxl_string_list is expected to be laid out in C, which is clear
> when one looks at libxl_string_list_length in libxl.c. In particular,
> StringList.toC
Introduces following functions in Xenctrl and associated types:
get_system_cpu_policy
cpu_policy_to_featureset,
string_of_xen_cpu_policy_index
These are wrappers around the existing C functions in xenctrl.h,
that will be used by xenopsd initially.
-Wno-declaration-after-statement is disabled to
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Re-generate code to reflect changes to libxl_types.idl from the
> following commits:
>
> 0570d7f276 x86/msr: introduce an option for compatible MSR behavior selection
> 7e5cffcd1e viridian: allow vCPU hotplug for Windows VMs
>
1 - 100 of 114 matches
Mail list logo
