>>> On 25.09.18 at 18:22, wrote:
> On 18/09/18 13:44, Jan Beulich wrote:
> On 10.09.18 at 16:02, wrote:
>>> Rather than unconditionally using vCPU 0, use the current vCPU if the
>>> subject domain is the current one.
>>>
>>> Signed-off-by: Jan Beulich
>
> What improvement is this intended t
>>> On 25.09.18 at 18:43, wrote:
> On 18/09/18 13:41, Jan Beulich wrote:
>> Ping?
>
> You're very unlikely to get any reply when I'm
I certainly did realize that I wouldn't get an immediate answer, but I
also didn't want to defer the pings any longer.
> On 11.09.18 at 10:20, wrote:
>>
This run is configured for baseline tests only.
flight 75292 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75292/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
Currently there is a subop for setting the memaccess of a page, but not
for consulting it. The new HVMOP_altp2m_get_mem_access adds this
functionality.
Both altp2m get/set mem access functions use the struct
xen_hvm_altp2m_mem_access which has now dropped the `set' part and has
been renamed from
While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
parsing") claimed to have got rid of the 'parameter "xpti" has invalid
value "", rc=-22!' log message for "xpti" alone on the command line,
this wasn't the case (the option took effect nevertheless).
Fix this there as well as for p
Having noticed that VMLOAD alone is about as fast as a single of the
involved WRMSRs, I thought it might be a reasonable idea to also use it
for PV. Measurements, however, have shown that an actual improvement can
be achieved only with an early prefetch of the VMCB (thanks to Andrew
for suggesting
There was another stdio.h inclusion left in place. Re-order #include-s
altogether in test_x86_emulator.c.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1,10 +1,10 @@
-#include
-#include
-#include
-#include
>>> On 26.09.18 at 00:39, wrote:
> Hi Paul,
>
> I am looking at porting the IOREQ server infrastructure on Arm. I didn't
> need much modification to make it run for Arm. Although, the
> implementation could be simplified over the x86 implementation.
>
> I noticed some issue while trying to imp
On Wed, 2018-07-25 at 04:37 -0600, Jan Beulich wrote:
> > > > On 25.07.18 at 11:25, wrote:
> >
> > On 07/24/2018 01:02 PM, Jan Beulich wrote:
> > > > > > On 24.07.18 at 13:26, wrote:
> > > >
> > > > On 07/24/2018 09:55 AM, Jan Beulich wrote:
> > > > > > > > On 23.07.18 at 15:48, wrote:
> > > >
This patch is causing build failure.
See:
http://logs.test-lab.xenproject.org/osstest/logs/128087/build-amd64/6.ts-xen-build.log
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Wed, Sep 26, 2018 at 09:36:39AM +0100, Wei Liu wrote:
> This patch is causing build failure.
>
> See:
>
> http://logs.test-lab.xenproject.org/osstest/logs/128087/build-amd64/6.ts-xen-build.log
Oh, it appears that Jan already posted a fix.
Wei.
___
flight 128093 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128093/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 127928
Tests which
On Wed, Sep 26, 2018 at 02:03:36AM -0600, Jan Beulich wrote:
> There was another stdio.h inclusion left in place. Re-order #include-s
> altogether in test_x86_emulator.c.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Tested-by: Wei Liu
___
Xen
>>> On 25.09.18 at 19:15, wrote:
> On 10/09/18 11:00, Jan Beulich wrote:
>> Well, I continue to not really agree. First and foremost, as said before,
>> the common (exclusive?) case is going to be that with "x86: use MOV
>> for PFN/PDX conversion when possible" no calls will exist at runtime at
>>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 September 2018 09:09
> To: Julien Grall ; Paul Durrant
>
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel
> Subject: Re: IOREQ server on Arm
>
> >>> On 26.09.18 at 00:39, wrote:
> >
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
Acked-by:
>>> On 25.09.18 at 17:30, wrote:
> On 25/09/18 13:41, Jan Beulich wrote:
> On 20.09.18 at 14:41, wrote:
>>> On 13/09/18 11:12, Jan Beulich wrote:
The function does two translations in one go for a single guest access.
Any failure of the first translation step (guest linear -> guest
On 25/09/2018 14:15, Balbir Singh wrote:
> On Tue, Sep 25, 2018 at 11:14:56AM +0200, David Hildenbrand wrote:
>> Let's perform all checking + offlining + removing under
>> device_hotplug_lock, so nobody can mess with these devices via
>> sysfs concurrently.
>>
>> Cc: Benjamin Herrenschmidt
>> Cc:
On Fri, Sep 21, 2018 at 08:56:45PM +0200, Daniel Kiper wrote:
> On Wed, Sep 19, 2018 at 10:34:47AM +0100, Wei Liu wrote:
> > Hi Daniel,
> >
> > I discovered an out of bounds access issue related to GRUB relocation
> > code path when inspecting early boot code.
> >
> > 9589927e5b changed an EFI only
Hi,
On Thu, Sep 20, 2018 at 12:40:25PM +0200, Roger Pau Monne wrote:
> Fill the from_xenstore libxl_device_type hook for PCI devices so that
> libxl_retrieve_domain_configuration can properly retrieve PCI devices
> from xenstore.
>
> This fixes disappearing pci devices across domain reboots.
>
Hi,
On 09/26/2018 10:14 AM, Paul Durrant wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 26 September 2018 09:09
To: Julien Grall ; Paul Durrant
Cc: Andrew Cooper ; Roger Pau Monne
; Stefano Stabellini ; xen-
devel
Subject: Re: IOREQ server on Arm
On 26.0
>>> On 17.07.18 at 11:48, wrote:
> @@ -62,12 +70,15 @@ int __hwdom_init vpci_add_handlers(struct pci_dev *pdev)
> if ( !has_vpci(pdev->domain) )
> return 0;
>
> +spin_lock(&pdev->vpci_lock);
> pdev->vpci = xzalloc(struct vpci);
Patterns like this should be avoided where p
On 26/09/18 11:32, Julien Grall wrote:
> Hi,
>
> On 09/26/2018 10:14 AM, Paul Durrant wrote:
>>> -Original Message-
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: 26 September 2018 09:09
>>> To: Julien Grall ; Paul Durrant
>>>
>>> Cc: Andrew Cooper ; Roger Pau Monne
>>> ; Stefa
Hi Jan,
On 09/26/2018 09:08 AM, Jan Beulich wrote:
On 26.09.18 at 00:39, wrote:
Hi Paul,
I am looking at porting the IOREQ server infrastructure on Arm. I didn't
need much modification to make it run for Arm. Although, the
implementation could be simplified over the x86 implementation.
I not
>>> On 17.07.18 at 11:48, wrote:
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -148,10 +148,11 @@ static void control_write(const struct pci_dev *pdev,
> unsigned int reg,
> pci_conf_write16(pdev->seg, pdev->bus, slot, func, reg, val);
> }
>
> -static struct vpc
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 26 September 2018 11:33
> To: Paul Durrant ; 'Jan Beulich'
>
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel
> Subject: Re: IOREQ server on Arm
>
> Hi,
>
> On 09/26/2018 10:14 AM,
On Wed, Sep 26, 2018 at 12:18:43PM +0200, Daniel Kiper wrote:
> On Fri, Sep 21, 2018 at 08:56:45PM +0200, Daniel Kiper wrote:
> > On Wed, Sep 19, 2018 at 10:34:47AM +0100, Wei Liu wrote:
> > > Hi Daniel,
> > >
> > > I discovered an out of bounds access issue related to GRUB relocation
> > > code pa
>>> On 17.07.18 at 11:48, wrote:
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -31,14 +31,26 @@ struct vpci_register {
> };
>
> #ifdef __XEN__
> -extern vpci_register_init_t *const __start_vpci_array[];
> -extern vpci_register_init_t *const __end_vpci_array[];
> +extern
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 26 September 2018 11:41
> To: Jan Beulich ; Paul Durrant
>
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel
> Subject: Re: IOREQ server on Arm
>
> Hi Jan,
>
> On 09/26/2018 09:08 A
On 2018-09-25 23:48, Michal Hocko wrote:
On Tue 25-09-18 11:59:09, Vlastimil Babka wrote:
[...]
This seems like almost complete copy of __free_pages_boot_core(),
could
you do some code reuse instead? I think Michal Hocko also suggested
that.
Yes, please try to reuse as much code as possible
>>> On 26.09.18 at 12:51, wrote:
>> -Original Message-
>> From: Julien Grall [mailto:julien.gr...@arm.com]
>> Sent: 26 September 2018 11:41
>> To: Jan Beulich ; Paul Durrant
>>
>> Cc: Andrew Cooper ; Roger Pau Monne
>> ; Stefano Stabellini ; xen-
>> devel
>> Subject: Re: IOREQ server on
George Dunlap writes ("Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU
sandboxing"):
> On 09/25/2018 12:02 PM, Ian Jackson wrote:
> > If you don't say set -e then you need to wrap every everything in your
> > entire script with an error check.
(I have deleted the whole comparative programm
The relocation code in __start_xen requires one extra element in the
MBI structure. By the looks of it the temporary MBI array is already
large enough. Add an assertion to catch any issue in the future.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/pvh-boot.c | 7 +++
1 file changed, 7 inser
Hi Paul,
On 09/26/2018 11:51 AM, Paul Durrant wrote:
-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 26 September 2018 11:41
To: Jan Beulich ; Paul Durrant
Cc: Andrew Cooper ; Roger Pau Monne
; Stefano Stabellini ; xen-
devel
Subject: Re: IOREQ server on Arm
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 September 2018 11:58
> To: Julien Grall ; Paul Durrant
>
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel
> Subject: RE: IOREQ server on Arm
>
> >>> On 26.09.18 at 12:51, wrote:
> >
On 26/09/18 12:00, Wei Liu wrote:
> The relocation code in __start_xen requires one extra element in the
> MBI structure. By the looks of it the temporary MBI array is already
> large enough. Add an assertion to catch any issue in the future.
>
> Signed-off-by: Wei Liu
While this is all well and
On Fri, Sep 21, 2018 at 09:26:27AM -0600, Jan Beulich wrote:
> >>> On 21.09.18 at 15:48, wrote:
> > On Fri, Sep 21, 2018 at 05:47:54AM -0600, Jan Beulich wrote:
> >> >>> On 21.09.18 at 12:49, wrote:
> >> > On Tue, Sep 11, 2018 at 07:32:04AM -0600, Jan Beulich wrote:
> >> >> @@ -218,6 +219,13 @@ v
On Tue, Sep 25, 2018 at 08:25:50AM -0600, Jan Beulich wrote:
> Emulation requiring device model assistance uses a form of instruction
> re-execution, assuming that the second (and any further) pass takes
> exactly the same path. This is a valid assumption as far use of CPU
> registers goes (as thos
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 26 September 2018 12:01
> To: Paul Durrant ; Jan Beulich
>
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel
> Subject: Re: IOREQ server on Arm
>
> Hi Paul,
>
> On 09/26/2018 11:51
flight 128100 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128100/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Julien,
On 25.09.18 20:20, Julien Grall wrote:
Signed-off-by: Julien Grall
Reviewed-by: Volodymyr Babchuk
---
Changes in v2:
- Invert the condition
- Add missing includes
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
On 9/26/18 10:34 AM, Razvan Cojocaru wrote:
> Currently there is a subop for setting the memaccess of a page, but not
> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
> functionality.
>
> Both altp2m get/set mem access functions use the struct
> xen_hvm_altp2m_mem_access which h
>>> On 26.09.18 at 13:02, wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1105,8 +1105,11 @@ static int acquire_resource(
>
> for ( i = 0; !rc && i < xmar.nr_frames; i++ )
> {
> -rc = set_foreign_p2m_entry(currd, gfn_list[i],
> -
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 September 2018 12:57
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Roger Pau Monne ;
> Stefano Stabellini ; xen-devel de...@lists.xenproject.org>
> Subject: RE: IOREQ server on Arm
>
> >>> On 26.09
On 26/09/18 08:40, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") claimed to have got rid of the 'parameter "xpti" has invalid
> value "", rc=-22!' log message for "xpti" alone on the command line,
> this wasn't the case (the option took effect n
>>> On 26.09.18 at 13:00, wrote:
> --- a/xen/arch/x86/guest/pvh-boot.c
> +++ b/xen/arch/x86/guest/pvh-boot.c
> @@ -44,6 +44,13 @@ static void __init convert_pvh_info(void)
>
> ASSERT(pvh_info->magic == XEN_HVM_START_MAGIC_VALUE);
>
> +/*
> + * Temporary MBI array needs to be at le
On 9/26/18 2:39 PM, Razvan Cojocaru wrote:
> On 9/26/18 10:34 AM, Razvan Cojocaru wrote:
>> Currently there is a subop for setting the memaccess of a page, but not
>> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
>> functionality.
>>
>> Both altp2m get/set mem access functions u
On 08/06/18 10:59, Roger Pau Monne wrote:
> @@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
> if ( dom->start_info_seg.pfn )
> bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
>
> +/* Set the MTRR. */
> +bsp_ctx.mtrr_d.typecode = HVM_SAVE_CODE(MT
flight 128054 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128054/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 127753
build-i386-pvop
On 26/09/18 07:33, Jan Beulich wrote:
On 25.09.18 at 18:14, wrote:
>> On 18/09/18 13:28, Jan Beulich wrote:
>>> @@ -1281,11 +1282,35 @@ static void load_segments(struct vcpu *n
>>> struct cpu_user_regs *uregs = &n->arch.user_regs;
>>> int all_segs_okay = 1;
>>> unsigned int dir
...and change the name to amd_iommu_get_address_from_pte() since the
address read is not necessarily a 'next level' page table.
The constants in use prior to this patch relate to device table entries
rather than page table entries. Although they do have the same value, it
makes the code confusing
On 09/26/2018 09:17 AM, Isaila Alexandru wrote:
> On Wed, 2018-07-25 at 04:37 -0600, Jan Beulich wrote:
> On 25.07.18 at 11:25, wrote:
>>>
>>> On 07/24/2018 01:02 PM, Jan Beulich wrote:
>>> On 24.07.18 at 13:26, wrote:
>
> On 07/24/2018 09:55 AM, Jan Beulich wrote:
> On 23
>>> On 26.09.18 at 14:26, wrote:
> To clarify the question, I'll of course do this:
>
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index 67b4a1d..2b5a621 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -489,14 +489,13 @@ long p
On 9/26/18 4:20 PM, Jan Beulich wrote:
On 26.09.18 at 14:26, wrote:
>> To clarify the question, I'll of course do this:
>>
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index 67b4a1d..2b5a621 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/m
>>> On 26.09.18 at 14:56, wrote:
> ...and change the name to amd_iommu_get_address_from_pte() since the
> address read is not necessarily a 'next level' page table.
There was no "level" in the original name. Which isn't meant to be an
objection to the rename.
> --- a/xen/drivers/passthrough/amd/
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 September 2018 14:32
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH] amd-iommu: use correct constants in
> amd_iommu_get
>>> On 26.09.18 at 15:27, wrote:
> On 9/26/18 4:20 PM, Jan Beulich wrote:
> On 26.09.18 at 14:26, wrote:
>>> To clarify the question, I'll of course do this:
>>>
>>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>>> index 67b4a1d..2b5a621 100644
>>> --- a/xen/arch/x
This run is configured for baseline tests only.
flight 75293 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75293/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
...and change the name to amd_iommu_get_address_from_pte() since the
address read is not necessarily the address of a next level page table.
(If the 'next level' field is not 1 - 6 then the address is a page
address).
The constants in use prior to this patch relate to device table entries
rather t
>>> On 26.09.18 at 14:47, wrote:
> On 26/09/18 07:33, Jan Beulich wrote:
> On 25.09.18 at 18:14, wrote:
>>> On 18/09/18 13:28, Jan Beulich wrote:
@@ -1281,11 +1282,35 @@ static void load_segments(struct vcpu *n
struct cpu_user_regs *uregs = &n->arch.user_regs;
int all
On 9/26/18 4:39 PM, Jan Beulich wrote:
On 26.09.18 at 15:27, wrote:
>> On 9/26/18 4:20 PM, Jan Beulich wrote:
>> On 26.09.18 at 14:26, wrote:
To clarify the question, I'll of course do this:
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
inde
On 9/25/18 2:30 PM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series moves Xen special handling of block merges from arch hooks
> into common code. A previous version has been reviewed by Boris.
Applied, thanks.
--
Jens Axboe
___
Xen-devel maili
flight 128055 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128055/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 127761
test-amd64-amd
[Hey, is it me/my mailer, or threading is weird for this series? :-O]
On Tue, 2018-09-18 at 14:57 +0100, George Dunlap wrote:
> On 09/18/2018 02:36 PM, Juergen Gross wrote:
> >
> > The string variant is much more flexible.
> >
> > It is easy possible to e.g. add a per-domain trace parameter to
>
On Tue, 2018-09-18 at 08:02 +0200, Juergen Gross wrote:
> Instead of passing the start and end pointers of the parameter
> definition array to the parsing function use a struct containing that
> information. This will allow to add other parameters to control the
> parsing later.
>
> Signed-off-by:
>>> On 17.07.18 at 11:48, wrote:
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -436,11 +436,6 @@ static int init_msix(struct pci_dev *pdev)
> vpci_msix_arch_init_entry(&pdev->vpci->msix->entries[i]);
> }
>
> -rc = vpci_add_register(pdev->vpci, control_rea
On Tue, 2018-09-18 at 08:02 +0200, Juergen Gross wrote:
> Define macros for filling struct kernel_param when defining
> parameters.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regards,
Dario
--
<> (Raistlin Majere)
>>> On 17.07.18 at 11:48, wrote:
> So that interrupts are properly freed.
>
> Signed-off-by: Roger Pau Monné
Same remarks here as for patch 4.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listin
On Mon, Jul 23, 2018 at 2:48 PM Alexandru Isaila
wrote:
>
> From: Isaila Alexandru
>
> This patch adds access control for NPT mode.
>
> There aren’t enough extra bits to store the access rights in the NPT p2m
> table, so we add a radix tree to store the rights. For efficiency,
> remove entries w
[Resending]
On Wed, Sep 26, 2018 at 5:02 PM George Dunlap
wrote:
>
> On Mon, Jul 23, 2018 at 2:48 PM Alexandru Isaila
> wrote:
> >
> > From: Isaila Alexandru
> >
> > This patch adds access control for NPT mode.
> >
> > There aren’t enough extra bits to store the access rights in the NPT p2m
> >
d54ecf31b2 placed the build dependency in a wrong file. This patch
adds the dependency to the right file. Add a runtime dependency in
libvirt.pm.
Signed-off-by: Wei Liu
---
Cc: Jim Fehlig
---
Osstest/Toolstack/libvirt.pm | 6 +-
ts-xen-build-prep| 3 ++-
2 files changed, 7 inser
flight 75294 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75294/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
The name of the "with_gla" flag is confusing; it has nothing to do
with the existence or lack thereof of a faulting GLA, but rather where
the fault originated. The npfec.kind value is always valid, and
should thus be propagated, regardless of whether gla_valid is set or
not.
In particular, gla_va
From: Isaila Alexandru
This patch adds access control for NPT mode.
There aren’t enough extra bits to store the access rights in the NPT p2m
table, so we add a radix tree to store extra information.
For efficiency:
- Only allocate this radix tree when we first store "non-default"
extra info
On Wed, Sep 26, 2018 at 10:49 AM George Dunlap wrote:
>
> The name of the "with_gla" flag is confusing; it has nothing to do
> with the existence or lack thereof of a faulting GLA, but rather where
> the fault originated. The npfec.kind value is always valid, and
> should thus be propagated, rega
On Tue, 25 Sep 2018, Julien Grall wrote:
> Some capababilities are set right during boot and will never change
> afterwards. At the moment, the function cpu_have_caps will check whether
> the cap is enabled from the memory.
>
> It is possible to avoid the load from the memory by using an
> ALTERNA
I think the subject wants to say "cpupool specific" ?
With this adjusted...
On Tue, 2018-09-18 at 08:03 +0200, Juergen Gross wrote:
> Add the framework for being able to define cpupool specific
> parameters.
> This includes the needed macros for defining a parameter and the
> minimal set of funct
On 26/09/18 17:47, George Dunlap wrote:
> The name of the "with_gla" flag is confusing; it has nothing to do
> with the existence or lack thereof of a faulting GLA, but rather where
> the fault originated. The npfec.kind value is always valid, and
> should thus be propagated, regardless of whether
On Tue, 2018-09-18 at 08:03 +0200, Juergen Gross wrote:
> Add a new domctl for setting domain specific parameters similar to
> XEN_SYSCTL_set_parameter for global hypervisor parameters.
>
> Enhance XEN_SYSCTL_set_parameter to be usable for setting cpupool
> specific parameters, too. For now do onl
On Tue, 2018-09-18 at 08:03 +0200, Juergen Gross wrote:
> Add a new xl command "cpupool-set-parameters" and cpupool config file
> support for setting per-cpupool generic parameters.
>
> Signed-off-by: Juergen Gross
>
Seems good to me. Couple of questions.
Question one: what about getting (and di
On 26/09/18 17:47, George Dunlap wrote:
> From: Isaila Alexandru
>
> This patch adds access control for NPT mode.
>
> There aren’t enough extra bits to store the access rights in the NPT p2m
> table, so we add a radix tree to store extra information.
I'm sorry to re-open this argument, but why?
From: YueHaibing
Date: Wed, 26 Sep 2018 17:18:14 +0800
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, so make sure the implementation in
> this driver has returns 'netdev_tx_t' value, and change the function
> return type to netdev_t
On Fri, 2018-09-21 at 09:52 +0100, Wei Liu wrote:
> On Fri, Sep 21, 2018 at 07:23:23AM +0200, Juergen Gross wrote:
> > On 20/09/18 18:06, Wei Liu wrote:
> > >
> > > It appears that the implementation in patch 10 concatenates the
> > > new
> > > settings to the old ones. It is not very nice imo.
>
flight 128102 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128102/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd a62d8e729c6db95f0c2e1de618be0b0796c0a97a
baseline version:
freebsd e3c2d3a906b
On 26/09/18 07:43, Jan Beulich wrote:
On 25.09.18 at 18:52, wrote:
>> On 29/08/18 17:03, Jan Beulich wrote:
>>> Eliminates a couple of branches in particular from the context switch
>>> path.
>>>
>>> Signed-off-by: Jan Beulich
>> I've already expressed a dis-inclination to this patch, becaus
Hi Stefano,
On 09/26/2018 12:50 AM, Stefano Stabellini wrote:
On Tue, 25 Sep 2018, Julien Grall wrote:
From: Volodymyr Babchuk
Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call t
Hi Stefano,
On 09/26/2018 05:53 PM, Stefano Stabellini wrote:
On Tue, 25 Sep 2018, Julien Grall wrote:
Some capababilities are set right during boot and will never change
afterwards. At the moment, the function cpu_have_caps will check whether
the cap is enabled from the memory.
It is possible
Hi Stefano,
On 09/26/2018 12:57 AM, Stefano Stabellini wrote:
On Tue, 25 Sep 2018, Julien Grall wrote:
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 941eec921b..02737e6caa 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -42,42 +42,53 @@ uint32_t smccc_ver;
stat
This run is configured for baseline tests only.
flight 75295 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75295/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On 9/26/18 4:43 AM, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/xen/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 90d387b50ab747f5..7f42d41f66ee98e3 100644
> --- a/drivers/xen/Kc
flight 128059 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
test-amd
Hi Stefano,
On 09/25/2018 09:45 PM, Stefano Stabellini wrote:
On Tue, 4 Sep 2018, Andrew Cooper wrote:
On 04/09/18 20:35, Julien Grall wrote:
Hi,
On 09/04/2018 08:21 PM, Julien Grall wrote:
A follow-up patch will require to know the number of vCPUs when
initializating the vGICv3 domain struc
flight 128090 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128090/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
Hi Stefano,
On 09/25/2018 09:38 PM, Stefano Stabellini wrote:
On Tue, 4 Sep 2018, Julien Grall wrote:
At the moment, Xen is assuming the hardware domain will have the same
number of re-distributor regions as the host. However, as the
number of CPUs or the stride (e.g on GICv4) may be different
Hi Paul,
On 09/26/2018 01:01 PM, Paul Durrant wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 26 September 2018 12:57
To: Paul Durrant
Cc: Julien Grall ; Andrew Cooper
; Roger Pau Monne ;
Stefano Stabellini ; xen-devel
Subject: RE: IOREQ server on Arm
On
flight 128084 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128084/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-examine 6 xen-installfail pass in 128033
Tests which did not succeed, but
flight 128098 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128098/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 447b08b3d2a3e04a9fccda68c72a2ff62d8197e9
baseline version:
ovmf 2939283f2df3b8a0871e9
Signed-off-by: Geert Uytterhoeven
---
drivers/xen/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 90d387b50ab747f5..7f42d41f66ee98e3 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -86,7 +86,7 @@ config XEN_
On 26/09/18 19:17, Dario Faggioli wrote:
> On Tue, 2018-09-18 at 08:03 +0200, Juergen Gross wrote:
>> Add a new xl command "cpupool-set-parameters" and cpupool config file
>> support for setting per-cpupool generic parameters.
>>
>> Signed-off-by: Juergen Gross
>>
> Seems good to me. Couple of que
This run is configured for baseline tests only.
flight 75299 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75299/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
1 - 100 of 107 matches
Mail list logo
