On 16/09/2020 20.25, Eduardo Habkost wrote:
> One of the goals of having less boilerplate on QOM declarations
> is to avoid human error. Requiring an extra argument that is
> never used is an opportunity for mistakes.
>
> Remove the unused argument from OBJECT_DECLARE_TYPE and
> OBJECT_DECLARE_SI
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:30 PM
>
> From: Paul Durrant
>
> At the moment iommu_map() and iommu_unmap() take a page order rather
> than a
> count, whereas iommu_iotlb_flush() takes a page count rather than an order.
> This patch makes them consistent with each ot
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:29 PM
>
> From: Paul Durrant
>
> This patch converts the VT-d code to use the new IOMMU page table
> allocator
> function. This allows all the free-ing code to be removed (since it is now
> handled by the general x86 code) which reduces
The arinc653 module has function header comment blocks and other comment
inconsistencies not in line with the Xen coding style. This change
cleans up the code to better match the Xen coding style, and has no
functional changes.
Signed-off-by: Jeff Kubascik
---
xen/common/sched/arinc653.c | 229 +
This change is an overhaul of the ARINC653 scheduler to enable CAST-32A
multicore scheduling. CAST-32A specifies that only one partition
(domain) can run during a minor frame, but that domain is now allowed to
have more than one vCPU.
Changes include:
- Each pCPU now has its own private structure.
This patch set adds multicore capability to the ARINC653 scheduler, based on the
guidance presented in the CAST-32A position paper. This approach only allows for
a single domain to run at any given time, but that domain is now able to use
multiple vCPUs running across the available pCPUs.
There ar
Function definitions in the arinc653 module did not follow the Xen
coding style. Furthermore, a few function names used a different prefix.
This change cleans up the definitions to be consistent with the Xen
coding style, and has no functional changes.
Signed-off-by: Jeff Kubascik
---
xen/common
This change is in preperation for an overhaul of the arinc653 module. It
groups functions in a logical order and fills out the sched_arinc653_def
structure. There are no functional changes.
Signed-off-by: Jeff Kubascik
---
xen/common/sched/arinc653.c | 239 +++-
1
The arinc653 module uses typedef struct with post fix tags for internal
structure definitions, which is not consistent with the Xen coding
style. This change cleans up the code to better match the style used
elsewhere in the Xen scheduler code, and has no functional changes.
Signed-off-by: Jeff Ku
flight 154399 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-xl-
On Wed, 16 Sep 2020, Julien Grall wrote:
> On 14/09/2020 15:26, Daniel Wagner2 wrote:
> > Hi Julien,
>
> Hi Daniel,
>
> I am moving the thread to xen-devel and adding a couple of more folks.
>
> > >
> > > >
> > > > this is the full version of the fdt that threw the error:
> > > > https://paste
On Thu, 17 Sep 2020, Oleksandr Tyshchenko wrote:
> On Wed, Sep 16, 2020 at 8:02 PM Julien Grall wrote:
> Hi Oleksandr,
>
>
> Hi Julien
>
> [sorry for the possible format issues]
>
>
> On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
On Wed, 16 Sep 2020, Julien Grall wrote:
> Hi Oleksandr,
>
> On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > And remove dependencies on CONFIG_EXPERT.
>
> In order to help to make the decision, can you provide the following
> information:
>- Is it fun
On Wed, Sep 16, 2020 at 11:34 AM David Hildenbrand wrote:
>
> __putback_isolated_page() already documents that pages will be placed to
> the tail of the freelist - this is, however, not the case for
> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
> the case for all existing
On Wed, Sep 16, 2020 at 11:34 AM David Hildenbrand wrote:
>
> Let's prepare for additional flags and avoid long parameter lists of bools.
> Follow-up patches will also make use of the flags in __free_pages_ok(),
> however, I wasn't able to come up with a better name for the type - should
> be good
On Wed, Sep 16, 2020 at 8:02 PM Julien Grall wrote:
> Hi Oleksandr,
>
Hi Julien
[sorry for the possible format issues]
>
> On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > And remove dependencies on CONFIG_EXPERT.
>
> In order to help to make the decisi
On 9/16/20 6:12 PM, Olaf Hering wrote:
> On Wed, Sep 16, David I wrote:
>
>> So, how did the debian package was compiled ? is this the same source code
>> with
>> different options ?
>
> Xen 4.11 is from 2018. Use also a compiler from that year.
> Using this years compiler will lead to errors...
> Am 16.09.2020 um 20:50 schrieb osalva...@suse.de:
>
> On 2020-09-16 20:34, David Hildenbrand wrote:
>> When adding separate memory blocks via add_memory*() and onlining them
>> immediately, the metadata (especially the memmap) of the next block will be
>> placed onto one of the just added+on
flight 154386 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-xl-
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-libvirt-raw
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbi
On 2020-09-16 20:34, David Hildenbrand wrote:
When adding separate memory blocks via add_memory*() and onlining them
immediately, the metadata (especially the memmap) of the next block
will be
placed onto one of the just added+onlined block. This creates a chain
of unmovable allocations: If the
When adding separate memory blocks via add_memory*() and onlining them
immediately, the metadata (especially the memmap) of the next block will be
placed onto one of the just added+onlined block. This creates a chain
of unmovable allocations: If the last memory block cannot get
offlined+removed() s
Let's prepare for additional flags and avoid long parameter lists of bools.
Follow-up patches will also make use of the flags in __free_pages_ok(),
however, I wasn't able to come up with a better name for the type - should
be good enough for internal purposes.
Cc: Andrew Morton
Cc: Alexander Duyc
__free_pages_core() is used when exposing fresh memory to the buddy
during system boot and when onlining memory in generic_online_page().
generic_online_page() is used in two cases:
1. Direct memory onlining in online_pages().
2. Deferred memory onlining in memory-ballooning-like mechanisms (Hype
Page isolation doesn't actually touch the pages, it simply isolates
pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
We already place pages to the tail of the freelists when undoing
isolation via __putback_isolated_page(), let's do it in any case
(e.g., if order == pageblock_or
__putback_isolated_page() already documents that pages will be placed to
the tail of the freelist - this is, however, not the case for
"order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
the case for all existing users.
This change affects two users:
- free page reporting
- page
One of the goals of having less boilerplate on QOM declarations
is to avoid human error. Requiring an extra argument that is
never used is an opportunity for mistakes.
Remove the unused argument from OBJECT_DECLARE_TYPE and
OBJECT_DECLARE_SIMPLE_TYPE.
Coccinelle patch used to convert all users o
This converts existing DECLARE_OBJ_CHECKERS usage to
OBJECT_DECLARE_TYPE when possible.
$ ./scripts/codeconverter/converter.py -i \
--pattern=AddObjectDeclareType $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
Cc: Peter Maydell
Cc: Andrzej Zaborowski
Cc: Alistair Francis
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several drivers.
>
> What is al
On Wed, Sep 16, 2020 at 03:28:28PM +0200, Jan Beulich wrote:
> On 16.09.2020 15:04, Roger Pau Monné wrote:
> > On Wed, Sep 16, 2020 at 02:55:52PM +0200, Jan Beulich wrote:
> >> On 16.09.2020 12:54, Roger Pau Monne wrote:
> >>> Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
> >>
On 14/09/2020 15:26, Daniel Wagner2 wrote:
Hi Julien,
Hi Daniel,
I am moving the thread to xen-devel and adding a couple of more folks.
this is the full version of the fdt that threw the error:
https://pastebin.com/63TZ9z3k
The problematic memory node appears in line 126
Thanks! The out
On Wed, Sep 16, 2020 at 02:55:52PM +0200, Jan Beulich wrote:
> On 16.09.2020 12:54, Roger Pau Monne wrote:
> > Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
> > and injecting a #GP fault will result in a panic:
> >
> > svm.c:1964:d5v0 RDMSR 0xc001102c unimplemented
> > d5v0 V
Hi Oleksandr,
On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
And remove dependencies on CONFIG_EXPERT.
In order to help to make the decision, can you provide the following
information:
- Is it functionally complete?
- Can it work on all known platforms wi
On 22/07/20 10:25, Philippe Mathieu-Daudé wrote:
> Xen accelerator requires specific changes to a machine to be able
> to use it. See for example the 'Xen PC' machine configure its PCI
> bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine
> declared. This code was probably added while
On Wed, Sep 16, David I wrote:
> So, how did the debian package was compiled ? is this the same source code
> with
> different options ?
Xen 4.11 is from 2018. Use also a compiler from that year.
Using this years compiler will lead to errors...
Olaf
signature.asc
Description: PGP signature
Andrew Cooper writes ("[PATCH] tools: Delete XEN_DOMCTL_disable_migrate"):
> It is conceptually wrong for this information to exist in the hypervisor in
> the first place. Only the toolstack is capable of correctly reasoning about
> the non-migrateability of guests.
>
> This hypercall has only ev
Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
and injecting a #GP fault will result in a panic:
svm.c:1964:d5v0 RDMSR 0xc001102c unimplemented
d5v0 VIRIDIAN CRASH: 7e c096 f8054cbe5ffe fa0837a066e8
fa0837a05f30
Return 0 when trying to read the MSR an
On 15.09.2020 18:17, Paul Durrant wrote:
> +static int load_shared_info(struct domain *d, struct domain_context *c)
> +{
> +struct domain_shared_info_context ctxt;
> +size_t hdr_size = offsetof(typeof(ctxt), buffer);
> +unsigned int i;
> +int rc;
> +
> +rc = DOMAIN_LOAD_BEGIN(SH
On Wed, Sep 16, 2020 at 08:37:44AM +, Trammell Hudson wrote:
> On Wednesday, September 16, 2020 3:32 AM, Roger Pau Monné
> wrote:
> > On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
> > > - s2w(&name_string);
> >
> > Don't you need to check that s2w succeed, so that name_st
Examples of compile bugs for xen-stable-4.11
for make dist-tools:
"include/ipxe/uri.h:178:12: error: taking address of packed member of
‘struct uri’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
178 | ref_get ( &uri->refcnt );"
-> fixed by adding the Cflag "-Wno-ad
On 16.09.2020 15:04, Roger Pau Monné wrote:
> On Wed, Sep 16, 2020 at 02:55:52PM +0200, Jan Beulich wrote:
>> On 16.09.2020 12:54, Roger Pau Monne wrote:
>>> Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
>>> and injecting a #GP fault will result in a panic:
>>>
>>> svm.c:1964:
Hello,
thanks for your infos. it appears the compilation process is not really
straightforward.
I had to patch some header files. then some of the firmwares were bugged.
So I disabled some various checks in the firmwares Makefiles.
I ended up with a:
"no target for make all":
configure passed all
By passing the functions an MFN and flags, only a single instance of
each is needed; they were pretty large for being inline functions
anyway.
While moving the code, also adjust coding style and add const where
sensible / possible.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/mm/s
While there's little point in enabling both, the combination ought to at
least build correctly. Drop the direct PV_SHIM_EXCLUSIVE conditionals
and instead zap PG_log_dirty to zero under the right conditions, and key
other #ifdef-s off of that.
While there also expand on ded576ce07e9 ("x86/shadow:
This combination doesn't really make sense (and there likely are more);
in particular even if the code built with both options set, HVM guests
wouldn't work (and I think one wouldn't be able to create one in the
first place). The alternative here would be some presumably intrusive
#ifdef-ary to get
Just like HVM, defaulting SHADOW_PAGING and TBOOT to Yes in shim-
exclusive mode makes no sense, as the respective code is dead there.
Also adjust the shim default config file: It needs to specifiy values
only for settings where a non-default value is wanted.
Signed-off-by: Jan Beulich
Reviewed-
The first change is simply addressing a build issue noticed by
Andrew. The build breakage goes beyond this specific combination
though - PV_SHIM_EXCLUSIVE plus HVM is similarly an issue. This
is what the last patch tries to take care of, in a shape already
on irc noticed to be controversial. I'm su
On 16.09.2020 12:54, Roger Pau Monne wrote:
> Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
> and injecting a #GP fault will result in a panic:
>
> svm.c:1964:d5v0 RDMSR 0xc001102c unimplemented
> d5v0 VIRIDIAN CRASH: 7e c096 f8054cbe5ffe fa0837a066e8
> f
On Fri, Sep 11, 2020 at 12:34:58PM +0200, David Hildenbrand wrote:
>Let's try to merge system ram resources we add, to minimize the number
>of resources in /proc/iomem. We don't care about the boundaries of
>individual chunks we added.
>
>Reviewed-by: Juergen Gross
>Cc: Andrew Morton
>Cc: Michal
On Fri, Sep 11, 2020 at 12:34:59PM +0200, David Hildenbrand wrote:
>Let's try to merge system ram resources we add, to minimize the number
>of resources in /proc/iomem. We don't care about the boundaries of
>individual chunks we added.
>
>Reviewed-by: Wei Liu
>Cc: Andrew Morton
>Cc: Michal Hocko
On Fri, Sep 11, 2020 at 12:34:57PM +0200, David Hildenbrand wrote:
>virtio-mem adds memory in memory block granularity, to be able to
>remove it in the same granularity again later, and to grow slowly on
>demand. This, however, results in quite a lot of resources when
>adding a lot of memory. Resou
On Fri, Sep 11, 2020 at 12:34:56PM +0200, David Hildenbrand wrote:
>Some add_memory*() users add memory in small, contiguous memory blocks.
>Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
>
>This can quickly result in a lot of memory resources, whereby the actual
>resource bound
Kevin, ping?
This patch hasn't changed since v2.
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 11 September 2020 09:20
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Kevin Tian
>
> Subject: [PATCH v8 1/8] x86/iommu: convert VT-d code to use new p
On Wed, Sep 16, 2020 at 02:16:25PM +0200, David Hildenbrand wrote:
>On 16.09.20 14:10, Wei Yang wrote:
>> On Wed, Sep 16, 2020 at 12:03:20PM +0200, David Hildenbrand wrote:
>>> On 16.09.20 12:02, Wei Yang wrote:
On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
> "mem" in
Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
free ebmalloc area at all") was put in place: Make xen_in_range() aware
of the freed range. This is in particular relevant for EFI-enabled
builds not actually running on EFI, as the entire range will be unused
in this case.
Sig
On 16.09.20 14:10, Wei Yang wrote:
> On Wed, Sep 16, 2020 at 12:03:20PM +0200, David Hildenbrand wrote:
>> On 16.09.20 12:02, Wei Yang wrote:
>>> On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
"mem" in the name already indicates the root, similar to
release_mem_region(
On Tue, Sep 15, 2020 at 04:59:58PM +0200, Thomas Zimmermann wrote:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several drivers
On Wed, Sep 16, 2020 at 12:03:20PM +0200, David Hildenbrand wrote:
>On 16.09.20 12:02, Wei Yang wrote:
>> On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
>>> "mem" in the name already indicates the root, similar to
>>> release_mem_region() and devm_request_mem_region(). Make it i
On Tue, Sep 15, 2020 at 04:59:54PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
> function with a per-object function.
>
> Signed-off-by: Thomas Zimmermann
Review
flight 154381 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154381/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, Sep 15, 2020 at 04:59:50PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in rockchip. The only exception is gem_prime_mmap,
> which is no
On Tue, Sep 15, 2020 at 04:59:46PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in nouveau.
>
> Signed-off-by: Thomas Zimmermann
Hm ttm and g
On Tue, Sep 15, 2020 at 04:59:45PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in msm. The only exception is gem_prime_mmap,
> which is non-tri
On Wed, Sep 16, 2020 at 09:28:47AM +0200, Jan Beulich wrote:
> The passed in domain doesn't get altered and hence can be const. While
> modifying its prototype anyway, also switch to bool.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On Mon, Sep 14, 2020 at 07:50:13AM -0400, Trammell Hudson wrote:
> If secure boot is enabled, the Xen command line arguments are ignored.
> If a unified Xen image is used, then the bundled configuration, dom0
> kernel, and initrd are prefered over the ones listed in the config file.
I understand t
On Tue, Sep 15, 2020 at 04:59:44PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in mediatek. The only exception is gem_prime_mmap,
> which is no
On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
> This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
> configuration file, the Linux kernel and initrd, as well as the XSM,
> and architectural specific files into a single "unified" EFI executable.
> This allows
On Tue, Sep 15, 2020 at 04:59:42PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in gma500.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
On Wed, Sep 16, 2020 at 12:36:28PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> > On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
> >> GEM object functions deprecate several similar callback interfaces in
> >> struct drm_driver. This pat
On Tue, Sep 15, 2020 at 04:59:40PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
> which is non
flight 154371 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-xl-
On Mon, Sep 14, 2020 at 07:50:11AM -0400, Trammell Hudson wrote:
> Add a separate function to display the address ranges used by
> the files and call `efi_arch_handle_module()` on the modules.
>
> Signed-off-by: Trammell Hudson
Reviewed-by: Roger Pau Monné
Thanks!
On Mon, Sep 14, 2020 at 07:50:10AM -0400, Trammell Hudson wrote:
> The config file, kernel, initrd, etc should only be freed if they
> are allocated with the UEFI allocator.
>
> Signed-off-by: Trammell Hudson
Reviewed-by: Roger Pau Monné
> ---
> xen/common/efi/boot.c | 10 ++
> 1 file
Hi
Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in exynos.
flight 154380 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154380/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 51526576219f122ec7ccfd55dea95afbca70d330
baseline version:
xen 6c5f
On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in exynos. The only exception is gem_prime_mmap,
> which is non-
On 16.09.20 12:02, Wei Yang wrote:
> On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
>> "mem" in the name already indicates the root, similar to
>> release_mem_region() and devm_request_mem_region(). Make it implicit.
>> The only single caller always passes iomem_resource, other
On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
>"mem" in the name already indicates the root, similar to
>release_mem_region() and devm_request_mem_region(). Make it implicit.
>The only single caller always passes iomem_resource, other parents are
>not applicable.
>
Looks good
On 16.09.2020 10:50, Trammell Hudson wrote:
> On Wednesday, September 16, 2020 3:45 AM, Roger Pau Monné
> wrote:
>> On Mon, Sep 14, 2020 at 07:50:13AM -0400, Trammell Hudson wrote:
>>> If secure boot is enabled, the Xen command line arguments are ignored.
>>> If a unified Xen image is used, then
On 16.09.2020 10:37, Trammell Hudson wrote:
> On Wednesday, September 16, 2020 3:32 AM, Roger Pau Monné
> wrote:
>> On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
>>> - s2w(&name_string);
>>
>> Don't you need to check that s2w succeed, so that name_string.w is not
>> a random
flight 154378 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154378/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8028b2907e20b21cd7d69639a36ac82a77c81dc1
baseline version:
ovmf 7bcb021a6d54c5775c0fa
On 16/09/2020 10:09, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 16 September 2020 10:07
To: Jan Beulich ; Oleksandr Tyshchenko
Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
; Paul Durrant
; Stefano Stabellini ; Julien Grall
Subject: Re: [PATCH V1 14
> -Original Message-
> From: Julien Grall
> Sent: 16 September 2020 10:07
> To: Jan Beulich ; Oleksandr Tyshchenko
>
> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
> ; Paul Durrant
> ; Stefano Stabellini ; Julien Grall
>
> Subject: Re: [PATCH V1 14/16] xen/ioreq: Use guest
> -Original Message-
> From: Jan Beulich
> Sent: 16 September 2020 10:04
> To: Oleksandr Tyshchenko
> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
> ; Paul Durrant
> ; Julien Grall ; Stefano Stabellini
> ; Julien
> Grall
> Subject: Re: [PATCH V1 14/16] xen/ioreq: Use guest_
On 16/09/2020 10:04, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
@@ -1325,7 +1327,7 @@ static int hvm_send_buffered_ioreq(struct
hvm_ioreq_server *s, ioreq_t *p)
new.read_pointer = old.read_pointer - n * IOREQ_BUFFER_SLOT_NUM;
new.write_pointer
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> @@ -1325,7 +1327,7 @@ static int hvm_send_buffered_ioreq(struct
> hvm_ioreq_server *s, ioreq_t *p)
>
> new.read_pointer = old.read_pointer - n * IOREQ_BUFFER_SLOT_NUM;
> new.write_pointer = old.write_pointer - n * IOREQ_BUFFER_
On 16/09/2020 09:52, Jan Beulich wrote:
On 16.09.2020 10:50, Julien Grall wrote:
On 16/09/2020 08:17, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
for ( i = 0; !rc && i < xmar.nr_frames; i++ )
{
-rc = set_foreign_p2m_entry(currd, gfn_
On 16.09.2020 10:50, Julien Grall wrote:
> On 16/09/2020 08:17, Jan Beulich wrote:
>> On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
>>> for ( i = 0; !rc && i < xmar.nr_frames; i++ )
>>> {
>>> -rc = set_foreign_p2m_entry(currd, gfn_list[i],
>>> +rc = se
Hi,
On 16/09/2020 08:17, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1155,6 +1155,7 @@ static int acquire_resource(
xen_pfn_t gfn_list[ARRAY_SIZE(mfn_list)];
unsigned int i;
+#ifndef CONFIG_AR
On Wednesday, September 16, 2020 3:45 AM, Roger Pau Monné
wrote:
> On Mon, Sep 14, 2020 at 07:50:13AM -0400, Trammell Hudson wrote:
> > If secure boot is enabled, the Xen command line arguments are ignored.
> > If a unified Xen image is used, then the bundled configuration, dom0
> > kernel, and i
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1490,6 +1490,12 @@ static void do_trap_hypercall(struct cpu_user_regs
> *regs, register_t *nr,
> /* Ensure the hypercall trap instruction is re-executed. */
> if ( current->hc
> -Original Message-
> From: Julien Grall
> Sent: 16 September 2020 09:39
> To: p...@xen.org; 'Jan Beulich' ; 'Oleksandr Tyshchenko'
>
> Cc: xen-devel@lists.xenproject.org; 'Oleksandr Tyshchenko'
> ; 'Stefano
> Stabellini' ; 'Volodymyr Babchuk'
> ; 'Andrew
> Cooper' ; 'Wei Liu' ; 'Roge
On 16/09/2020 09:13, Paul Durrant wrote:
-Original Message-
From: Jan Beulich
Sent: 16 September 2020 09:05
To: Oleksandr Tyshchenko ; Paul Durrant
Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
; Stefano
Stabellini ; Julien Grall ; Volodymyr
Babchuk
; Andrew Cooper ; Wei
On Wednesday, September 16, 2020 3:32 AM, Roger Pau Monné
wrote:
> On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
> > - s2w(&name_string);
>
> Don't you need to check that s2w succeed, so that name_string.w is not
> a random pointer from stack garbage?
Maybe? I don't see anyw
> -Original Message-
> From: Jan Beulich
> Sent: 16 September 2020 09:05
> To: Oleksandr Tyshchenko ; Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
> ; Stefano
> Stabellini ; Julien Grall ; Volodymyr
> Babchuk
> ; Andrew Cooper ; Wei
> Liu ; Roger
> Pau Monné
Hi Paul,
On 15/09/2020 09:29, Paul Durrant wrote:
From: Paul Durrant
This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and
instead calls iommu_iotlb_flush_all() at the end of a batch. This should mean
non-singleton map/unmap operations perform better.
NOTE: A batch is
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -635,7 +635,8 @@ int p2m_is_logdirty_range(struct p2m_domain *, unsigned
> long start,
>unsigned long end);
>
> /* Set foreign entry in the p2m t
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch introduces a helper the main purpose of which is to check
> if a domain is using IOREQ server(s).
>
> On Arm the benefit is to avoid calling handle_hvm_io_completion()
> (which implies iterating over all
Hi Paul,
On 15/09/2020 09:29, Paul Durrant wrote:
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
the per-CPU 'iommu_dont_flush_iotlb' global and the o
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> @@ -2277,8 +2299,10 @@ void leave_hypervisor_to_guest(void)
> {
> local_irq_disable();
>
> -check_for_vcpu_work();
> -check_for_pcpu_work();
> +do
> +{
> +check_for_pcpu_work();
> +} while ( check_for_vcpu_work()
1 - 100 of 106 matches
Mail list logo