flight 154446 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154446/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 32b0a492d505434c6f5e6c3578cd34fee39cd25e
baseline version:
ovmf 5648836987cab28ca988d
On Wed, Sep 16, 2020 at 09:31:21PM +0200, David Hildenbrand wrote:
>
>
>> 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
On Wed, Sep 16, 2020 at 08:34:10PM +0200, David Hildenbrand wrote:
>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_
On Wed, Sep 16, 2020 at 08:34:09PM +0200, 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 existi
On Wed, Sep 16, 2020 at 08:34:09PM +0200, 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 existi
On Wed, Sep 16, 2020 at 08:34:08PM +0200, 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 go
flight 154431 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair broken
test-amd64-i386-qemut-rhel6hvm-intel 7 x
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-vhd
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*
flight 154428 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154428/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 154241
Tests which did not succeed, b
On 17/09/2020 15:57, Stewart Hildebrand wrote:
> On Thursday, September 17, 2020 10:43 AM, Andrew Cooper wrote:
>> On 16/09/2020 19:18, Jeff Kubascik wrote:
>>> +/*
>>> + * A handle with all zeros represents domain 0 if present, otherwise idle
>>> UNIT
>>> + */
>>> +#define DOM0_HANDLE ((const xen
On 16/09/2020 19:18, Jeff Kubascik wrote:
> +/*
> + * A handle with all zeros represents domain 0 if present, otherwise idle
> UNIT
> + */
> +#define DOM0_HANDLE ((const xen_domain_handle_t){0})
This isn't accurate.
There are systems where dom0 doesn't have a zero UUID (XenServer for
one), and i
On Thu, Sep 17, 2020 at 04:12:23PM +0200, Jan Beulich wrote:
> On 10.09.2020 15:35, Roger Pau Monne wrote:
> > arch_init_memory will treat all the gaps on the physical memory map
> > between RAM regions as MMIO and use share_xen_page_with_guest in order
> > to assign them to dom_io. This has the si
update (for Hans and Ian):
I encounter the same issue when compiling the 4.14 branch:
git checkout -b stable-4.14 origin/stable-4.14
./configure && make
make[8]: Entering directory '/root/xen/tools/firmware/etherboot/ipxe/src'
[BUILD] bin/flexboot_nodnic.o
drivers/infiniband/flexboot_nodnic.c
On 17/09/2020 09:12, Jan Beulich wrote:
> On 16.09.2020 20:18, Jeff Kubascik wrote:
>> @@ -517,27 +516,35 @@ static const struct scheduler sched_arinc653_def = {
>> .sched_id = XEN_SCHEDULER_ARINC653,
>> .sched_data = NULL,
>>
>> +.global_init= NULL,
>> .init
Ok, thanks.
So I have done a fresh checkout of the master branch, but unfortunately,
there's a bug in infiniband drivers.
the error is : "drivers/infiniband/flexboot_nodnic.c:368:53: error:
implicit conversion from 'enum ib_queue_pair_type' to
'nodnic_queue_pair_type' [-Werror=enum-conversion]".
th
On Thursday, September 17, 2020 12:19 PM, Andrew Cooper wrote:
>On 17/09/2020 15:57, Stewart Hildebrand wrote:
>> On Thursday, September 17, 2020 10:43 AM, Andrew Cooper wrote:
>>> On 16/09/2020 19:18, Jeff Kubascik wrote:
+/*
+ * A handle with all zeros represents domain 0 if present, ot
flight 154429 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154429/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5648836987cab28ca988dfe5af94413cfa480a92
baseline version:
ovmf 8028b2907e20b21cd7d69
On Thu, 2020-09-17 at 15:59 +, Stewart Hildebrand wrote:
> On Thursday, September 17, 2020 11:20 AM, Dario Faggioli wrote:
> > On Thu, 2020-09-17 at 15:10 +, Stewart Hildebrand wrote:
> > > > It might be worth to consider using just the core scheduling
> > > > framework
> > > > in order to
On 16/09/2020 19:18, Jeff Kubascik wrote:
> -/**
> - * Retrieve the idle UNIT for a given physical CPU
> +/*
> + * Retrieve the idle UNIT for a given pCPU
> */
/** is also acceptable. We've inherited quite a few doxygen-like
comments, and there is currently a plan to move some things formally t
On Tue, Sep 15, 2020 at 09:29:32AM +0100, Paul Durrant wrote:
> 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 other, opti
On Tue, Sep 15, 2020 at 09:29:34AM +0100, 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
On Thu, Sep 17, 2020 at 01:27:12PM +0200, Jan Beulich wrote:
> Inspired by some of Trammell's suggestions, this harvests some low
> hanging fruit, without needing to be concerned about the definitions of
> the EFI interfaces themselves.
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Wei Liu
On 16/09/2020 19:18, Jeff Kubascik wrote:
> diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
> index 7bb75ffe2b..d8a23730c3 100644
> --- a/xen/common/sched/arinc653.c
> +++ b/xen/common/sched/arinc653.c
> @@ -50,38 +50,38 @@
> * Return a pointer to the ARINC 653-specific sch
On Thursday, September 17, 2020 11:20 AM, Dario Faggioli wrote:
>On Thu, 2020-09-17 at 15:10 +, Stewart Hildebrand wrote:
>> On Thursday, September 17, 2020 5:04 AM, Jürgen Groß wrote:
>> > On 16.09.20 20:18, Jeff Kubascik wrote:
>> > > This change is an overhaul of the ARINC653 scheduler to en
On Thursday, September 17, 2020 11:26 AM, Jan Beulich wrote:
> On 17.09.2020 16:05, Trammell Hudson wrote:
> > If we have a way to detect a unified image early enough, then
> > we can avoid the backwards incompatibility if it is not unified.
>
> I was assuming this was easily possible, if necessar
If a unified Xen image is used, then the bundled configuration,
Xen command line, dom0 kernel, and ramdisk are prefered over
any files listed in the config file or provided on the command line.
Unlike the shim based verification, the PE signature on a unified image
covers all of the Xen+config+ker
On Thu, Sep 17, 2020 at 01:27:12PM +0200, Jan Beulich wrote:
> Inspired by some of Trammell's suggestions, this harvests some low
> hanging fruit, without needing to be concerned about the definitions of
> the EFI interfaces themselves.
>
> Signed-off-by: Jan Beulich
This is purely a non-functio
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
---
xen/common/efi/boot.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/xen/common/efi/bo
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 an administrator to update the components independently
without requirin
This patch series 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 an administrator to update the components
independently without
Other than the config file parser that edits the image inplace,
no other users of the file sections requires write access to the
data.
Signed-off-by: Trammell Hudson
---
xen/common/efi/boot.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/xen/common/efi/boot.c b/
The config file, kernel, initrd, etc should only be freed if they
are allocated with the UEFI allocator.
Signed-off-by: Trammell Hudson
---
xen/common/efi/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 157
On 17.09.2020 16:05, Trammell Hudson wrote:
> On Thursday, September 17, 2020 8:51 AM, Jan Beulich
> wrote:
>> On 14.09.2020 13:50, 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,
On 17.09.2020 15:04, Trammell Hudson wrote:
> On Thursday, September 17, 2020 8:33 AM, Jan Beulich
> wrote:
>> On 14.09.2020 13:50, Trammell Hudson wrote:
>> [...]
>>> +For all the examples the `.pad` section ended at 0x82d04100.
>>> +All the sections are optional (`.config`, `.kernel`, `
On Thu, 2020-09-17 at 15:10 +, Stewart Hildebrand wrote:
> On Thursday, September 17, 2020 5:04 AM, Jürgen Groß wrote:
> > On 16.09.20 20:18, Jeff Kubascik wrote:
> > > This change is an overhaul of the ARINC653 scheduler to enable
> > > CAST-32A
> > > multicore scheduling. CAST-32A specifies t
On 17.09.20 17:10, Stewart Hildebrand wrote:
On Thursday, September 17, 2020 5:04 AM, Jürgen Groß wrote:
On 16.09.20 20:18, Jeff Kubascik wrote:
This change is an overhaul of the ARINC653 scheduler to enable CAST-32A
multicore scheduling. CAST-32A specifies that only one partition
(domain) can
On Thu, Sep 17, 2020 at 12:56:41PM +0200, Jan Beulich wrote:
> On 17.09.2020 12:45, Roger Pau Monné wrote:
> > On Wed, Sep 16, 2020 at 02:20:54PM +0200, Jan Beulich wrote:
> >> --- a/xen/arch/x86/efi/stub.c
> >> +++ b/xen/arch/x86/efi/stub.c
> >> @@ -52,6 +52,13 @@ bool efi_enabled(unsigned int fea
On 17.09.2020 15:33, Trammell Hudson wrote:
> On Thursday, September 17, 2020 9:04 AM, Trammell Hudson
> wrote:
>> On Thursday, September 17, 2020 8:33 AM, Jan Beulich jbeul...@suse.com wrote:
>>> [...]
- if ( read_section(image, ".ucode", &ucode, NULL) )
-return;
>>>
On Thursday, September 17, 2020 5:04 AM, Jürgen Groß wrote:
>On 16.09.20 20:18, Jeff Kubascik wrote:
>> 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 doma
On Thursday, September 17, 2020 10:43 AM, Andrew Cooper wrote:
>On 16/09/2020 19:18, Jeff Kubascik wrote:
>> +/*
>> + * A handle with all zeros represents domain 0 if present, otherwise idle
>> UNIT
>> + */
>> +#define DOM0_HANDLE ((const xen_domain_handle_t){0})
>
>This isn't accurate.
>
>There a
On Wed, Sep 16, 2020 at 02:20:54PM +0200, Jan Beulich wrote:
> 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
On Thu, 2020-09-17 at 13:09 +0100, Andrew Cooper wrote:
> On 16/09/2020 19:18, Jeff Kubascik wrote:
> > diff --git a/xen/common/sched/arinc653.c
> > b/xen/common/sched/arinc653.c
> > index 7bb75ffe2b..d8a23730c3 100644
> > --- a/xen/common/sched/arinc653.c
> > +++ b/xen/common/sched/arinc653.c
> >
On Thu, 2020-09-17 at 10:09 +0200, Jan Beulich wrote:
> On 16.09.2020 20:18, Jeff Kubascik wrote:
> > --- a/xen/common/sched/arinc653.c
> > +++ b/xen/common/sched/arinc653.c
> > @@ -119,10 +119,9 @@ static int dom_handle_cmp(const
> > xen_domain_handle_t h1,
> > return memcmp(h1, h2, sizeof(xe
On 17.09.2020 16:28, Roger Pau Monné wrote:
> On Thu, Sep 17, 2020 at 04:12:23PM +0200, Jan Beulich wrote:
>> On 10.09.2020 15:35, Roger Pau Monne wrote:
>>> arch_init_memory will treat all the gaps on the physical memory map
>>> between RAM regions as MMIO and use share_xen_page_with_guest in orde
On Thu, 2020-09-17 at 10:12 +0200, Jan Beulich wrote:
> On 16.09.2020 20:18, Jeff Kubascik wrote:
> > @@ -517,27 +516,35 @@ static const struct scheduler
> > sched_arinc653_def = {
> > .sched_id = XEN_SCHEDULER_ARINC653,
> > .sched_data = NULL,
> >
> > +.global_init= N
On 10.09.2020 15:35, Roger Pau Monne wrote:
> arch_init_memory will treat all the gaps on the physical memory map
> between RAM regions as MMIO and use share_xen_page_with_guest in order
> to assign them to dom_io. This has the side effect of setting the Xen
> heap flag on such pages, and thus is_s
On Thursday, September 17, 2020 8:51 AM, Jan Beulich wrote:
> On 14.09.2020 13:50, 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
Hi Thomas,
On 09/15, 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 vgem. The only exception is gem_prime_mmap,
> which is non-trivial to convert.
>
flight 154421 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154421/
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 Thursday, September 17, 2020 9:04 AM, Trammell Hudson
wrote:
> On Thursday, September 17, 2020 8:33 AM, Jan Beulich jbeul...@suse.com wrote:
> > [...]
> > > - if ( read_section(image, ".ucode", &ucode, NULL) )
> > > -return;
> > >
> > > - name.s = get_value(&cfg, section, "ucod
On Thursday, September 17, 2020 8:33 AM, Jan Beulich wrote:
> On 14.09.2020 13:50, Trammell Hudson wrote:
> [...]
> > +For all the examples the `.pad` section ended at 0x82d04100.
> > +All the sections are optional (`.config`, `.kernel`, `.ramdisk`, `.xsm`,
> > +`.ucode` (x86) and `.dtb` (
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Qinglang Miao
---
v2: based on linux-next(20200917), and can be applied to
mainline cleanly now.
arch/x86/xen/p2m.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/x86/xen/p2m.c b
small conflict
if you apply it against latest linux-next. So I resend a v2 patch
against linux-next(20200917), and it can be applied to mainline cleanly
now.
Thanks.
On 14.09.2020 13:50, 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.
>
> Unlike the shim based verificat
On Wed, Sep 16, 2020 at 03:53:43PM +0200, Roger Pau Monné wrote:
> 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:
> > >
On 14.09.2020 13:50, Trammell Hudson wrote:
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -116,3 +116,52 @@ Filenames must be specified relative to the location of
> the EFI binary.
>
> Extra options to be passed to Xen can also be specified on the command line,
> following a
Hi Thomas,
On 09/15, 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 vkms.
>
> Signed-off-by: Thomas Zimmermann
Thanks! Looks fine.
Reviewed-by: M
On 17.09.2020 13:40, Roger Pau Monné wrote:
> On Thu, Sep 17, 2020 at 01:27:12PM +0200, Jan Beulich wrote:
>> Inspired by some of Trammell's suggestions, this harvests some low
>> hanging fruit, without needing to be concerned about the definitions of
>> the EFI interfaces themselves.
>>
>> Signed-
On 17.09.2020 13:17, Roger Pau Monné wrote:
> On Thu, Sep 17, 2020 at 12:56:41PM +0200, Jan Beulich wrote:
>> On 17.09.2020 12:45, Roger Pau Monné wrote:
>>> On Wed, Sep 16, 2020 at 02:20:54PM +0200, Jan Beulich wrote:
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -5
On 14.09.2020 13:50, Trammell Hudson wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -539,6 +539,22 @@ static char * __init split_string(char *s)
> return NULL;
> }
>
> +static void __init handle_file_info(CHAR16 *name,
> +struct f
Inspired by some of Trammell's suggestions, this harvests some low
hanging fruit, without needing to be concerned about the definitions of
the EFI interfaces themselves.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -420,7 +420,7 @@ static void
> On 16 Sep 2020, at 18:30, 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://pas
On 16.09.2020 08:43, Roger Pau Monné wrote:
> On Mon, Sep 14, 2020 at 07:50:10AM -0400, Trammell Hudson wrote:
>> @@ -279,13 +280,13 @@ void __init noreturn blexit(const CHAR16 *str)
>> if ( !efi_bs )
>> efi_arch_halt();
>>
>> -if ( cfg.addr )
>> +if ( cfg.addr && cfg.need_t
On Tue, Sep 15, 2020 at 04:59:51PM +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 tegra.
>
> Signed-off-by: Thomas Zimmermann
> ---
> driver
On 17.09.2020 12:45, Roger Pau Monné wrote:
> On Wed, Sep 16, 2020 at 02:20:54PM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/efi/stub.c
>> +++ b/xen/arch/x86/efi/stub.c
>> @@ -52,6 +52,13 @@ bool efi_enabled(unsigned int feature)
>>
>> void __init efi_init_memory(void) { }
>>
>> +bool efi_
> -Ursprüngliche Nachricht-
> Von: Stefano Stabellini
> Gesendet: Donnerstag, 17. September 2020 02:31
> An: Julien Grall
> Cc: Daniel Wagner2 ; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Bertrand Marquis ; Andre Przywara
>
> Betreff: Re: DT with memory bank of size 0 (W
On 17/09/2020 01:31, Stefano Stabellini wrote:
Hi,
> 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
On 16.09.20 20:18, Jeff Kubascik wrote:
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.
It might be worth to
> "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.
>
> Suggested-by: Wei Yang
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Da
On 17.09.2020 10:33, Roger Pau Monné wrote:
> On Wed, Sep 16, 2020 at 03:53:43PM +0200, Roger Pau Monné wrote:
>> 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 1
On 16.09.2020 20:18, Jeff Kubascik wrote:
> --- a/xen/common/sched/arinc653.c
> +++ b/xen/common/sched/arinc653.c
> @@ -119,10 +119,9 @@ static int dom_handle_cmp(const xen_domain_handle_t h1,
> return memcmp(h1, h2, sizeof(xen_domain_handle_t));
> }
>
> -static struct sched_unit *find_unit
On 16.09.2020 20:18, Jeff Kubascik wrote:
> @@ -517,27 +516,35 @@ static const struct scheduler sched_arinc653_def = {
> .sched_id = XEN_SCHEDULER_ARINC653,
> .sched_data = NULL,
>
> +.global_init= NULL,
> .init = a653sched_init,
> .deinit =
flight 154410 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154410/
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-
> -Original Message-
> From: Eduardo Habkost
> Sent: 16 September 2020 19:25
> To: qemu-de...@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange
> ; Marc-André Lureau
> ; Gerd Hoffmann ; Michael S.
> Tsirkin ;
> Peter Maydell ; Corey Minyard
> ; Cédric Le Goater
> ; David Gibson ; Corn
> -Original Message-
> From: Eduardo Habkost
> Sent: 16 September 2020 19:25
> To: qemu-de...@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange
> ; Peter Maydell
> ; Andrzej Zaborowski ; Alistair
> Francis
> ; Kevin Wolf ; Max Reitz
> ; Mark Cave-
> Ayland ; David Gibson
> ; Richard
On 9/16/20 8:25 PM, Eduardo Habkost wrote:
> 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
For the as
On Wed, 16 Sep 2020 14:25:17 -0400
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
> O
On 9/16/20 8:25 PM, 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_SIM
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:30 PM
>
> 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
Hi
Am 15.09.20 um 17:05 schrieb Christian König:
> Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in amdgpu. The only exceptio
flight 154415 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154415/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:30 PM
>
> From: Paul Durrant
>
> It's confusing and not consistent with the terminology introduced with
> 'dfn_t'.
> Just call them IOMMU page tables.
>
> Also remove a pointless check of the 'acpi_drhd_units' list in
> vtd_dump_page_
> From: Tian, Kevin
> Sent: Thursday, September 17, 2020 3:20 PM
>
> > From: Paul Durrant
> > Sent: Tuesday, September 15, 2020 4:30 PM
> >
> > From: Paul Durrant
> >
> > Sharing of HAP tables is now VT-d specific so the operation is never defined
> > for AMD IOMMU any more. There's also no need
> From: Paul Durrant
> Sent: Tuesday, September 15, 2020 4:30 PM
>
> From: Paul Durrant
>
> Sharing of HAP tables is now VT-d specific so the operation is never defined
> for AMD IOMMU any more. There's also no need to pro-actively set
> vtd.pgd_maddr
> when using shared EPT as it is straightfo
On Wed, 16 Sep 2020 14:25:17 -0400
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
> O
Hi
Am 15.09.20 um 17:25 schrieb Christian König:
> Added my rb to the amdgpu and radeon patches.
>
> Should we pick those up through the amd branches or do you want to push
> everything to drm-misc-next?
>
> I think the later since this should result in much merge clash.
Yes, preferable, I'd me
86 matches
Mail list logo
