flight 128276 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 128170
flight 128296 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128296/
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
Hi Stefano,
On 10/01/2018 09:52 PM, Stefano Stabellini wrote:
On Mon, 1 Oct 2018, Stefano Stabellini wrote:
On Mon, 1 Oct 2018, Julien Grall wrote:
call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
do SMCCC call, replace all call to the former by the later.
On Mon, 1 Oct 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 we end up
> exposing regions which does not contain any
On Mon, 1 Oct 2018, Stefano Stabellini wrote:
> On Mon, 1 Oct 2018, Julien Grall wrote:
> > call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
> > do SMCCC call, replace all call to the former by the later.
> >
> > Signed-off-by: Julien Grall
>
> Reviewed-by: Stefano
On Mon, 1 Oct 2018, Julien Grall wrote:
> call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
> do SMCCC call, replace all call to the former by the later.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
(you might want to make sure the double [[ is removed
On Mon, 1 Oct 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
>
flight 128288 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128288/
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
Hi,
I forgot to remove patch from the previous series before sending the new
one.
Please ignore that patch. Sorry for the noise.
Cheers,
On 10/01/2018 07:57 PM, Julien Grall wrote:
At the moment, Xen is assuming the hardware domain will have the same
number of re-distributor regions as
Hi,
I forgot to remove patch from the previous series before sending the new
one.
Please ignore that patch. Sorry for the noise.
Cheers,
On 10/01/2018 07:57 PM, Julien Grall wrote:
A follow-up patch will require to know the number of vCPUs when
initializating the vGICv3 domain structure.
The PV fields kernel, ramdisk, cmdline are only there for compatibility
with old toolstack. Instead of manually copying them over to there new
field, use the deprecated_by attribute in the IDL.
Suggested-by: Roger Pau Monné
Signed-off-by: Julien Grall
---
Changes in v3:
- Patch
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 we end up
exposing regions which does not contain any re-distributors.
When booting, Linux will go
libxl__arch_domain_build_info_setdefault
A follow-up will require to modify default of multiple fields of
build_info. So rename the function accordingly.
No functional change.
Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Changes in v3:
- Add
A follow-up patch will require to know the number of vCPUs when
initializating the vGICv3 domain structure. However this information is
not available at domain creation. This is only known once
XEN_DOMCTL_max_vpus is called for that domain.
In order to get the max vCPUs around, delay the domain
Hi all,
This small patch series adds switch Arm guest type to PVH in libxl. See
patch #2 for the rationale.
Cheers,
Julien Grall (3):
tools/libxl: Rename libxl__arch_domain_build_info_acpi_setdefault
to...
tools/libxl: Deprecate PV fields kernel, ramdisk, cmdline
tools/libxl: Switch
Currently, the toolstack is considering Arm guest always PV. However,
they are very similar to PVH because HW virtualization extension are used
and QEMU is not started. So switch Arm guest type to PVH.
To keep compatibility with toolstack creating Arm guest with PV type
(e.g libvirt), libxl will
On Mon, 2018-10-01 at 16:35 +0100, Wei Liu wrote:
> On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
> > Wait, the migration code reads the scheduler parameters -- even if
> > these
> > have not been explicitly set by the admin -- and sends them along
> > with
> > the migration
On Mon, 2018-10-01 at 18:07 +0200, Juergen Gross wrote:
> On 01/10/2018 17:48, George Dunlap wrote:
> > On 10/01/2018 04:40 PM, Andrew Cooper wrote:
> > > On 01/10/18 16:35, Wei Liu wrote:
> > > > > Wait, the migration code reads the scheduler parameters --
> > > > > even if these
> > > > > have
flight 128274 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128274/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 128215
Tests which did
Hi Roger,
On 10/01/2018 05:37 PM, Roger Pau Monné wrote:
On Mon, Oct 01, 2018 at 04:33:45PM +0100, Julien Grall wrote:
Hi,
On 10/01/2018 04:27 PM, Roger Pau Monné wrote:
On Tue, Sep 25, 2018 at 08:36:36PM +0100, Julien Grall wrote:
Hi Roger,
Sorry for the late reply.
On 09/03/2018 03:40
A follow-up patch will require to know the number of vCPUs when
initializating the vGICv3 domain structure. However this information is
not available at domain creation. This is only known once
XEN_DOMCTL_max_vpus is called for that domain.
In order to get the max vCPUs around, delay the domain
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 we end up
exposing regions which does not contain any re-distributors.
When booting, Linux will go
Hi all,
This series is meant to address Dom0 boot failure when running on GICv4
platforms as well as when the number of vCPUs is not equal to the numbers of
pCPUs. They should be backported up Xen 4.8.
Cheers,
Julien Grall (2):
xen/arm: vgic-v3: Delay the initialization of the domain
On Mon, Oct 01, 2018 at 04:33:45PM +0100, Julien Grall wrote:
> Hi,
>
> On 10/01/2018 04:27 PM, Roger Pau Monné wrote:
> > On Tue, Sep 25, 2018 at 08:36:36PM +0100, Julien Grall wrote:
> > > Hi Roger,
> > >
> > > Sorry for the late reply.
> > >
> > > On 09/03/2018 03:40 PM, Roger Pau Monné
Which, on x86, requires fiddling with the INTx bit in PCI config space,
since for internally used MSI we can't delegate this to Dom0.
ns16550_init_postirq() also needs (benign) re-ordering of its
operations.
Signed-off-by: Jan Beulich
---
v2: Re-base.
--- a/docs/misc/xen-command-line.markdown
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.
This patch seems to be committed now. Please backport this to Xen 4.10
stable
In order for a Xen internal PCI device driver to enable MSI on the
device, we need another hook which the driver can use to create the IRQ
(doing this in the init_preirq hook is too early, since IRQ code hasn't
got initialized at that time yet, and doing it in init_postirq is too
late because at
> How should a policy in user space look like when new memory gets added
> - on s390x? Not onlining paravirtualized memory is very wrong.
Because we're going to balloon it away in a moment anyway?
We have auto-onlining. Why isn't that being used on s390?
> So the type of memory is very
On 01/10/2018 17:48, George Dunlap wrote:
> On 10/01/2018 04:40 PM, Andrew Cooper wrote:
>> On 01/10/18 16:35, Wei Liu wrote:
>>> On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
On 10/01/2018 04:17 PM, Wei Liu wrote:
> On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich
Patch 2 is no longer RFC, now that I have a device where MSI actually
works (suggesting that it was really the other device's fault that things
didn't work).
1: console: adjust IRQ initialization
2: ns16550: enable use of PCI MSI
Jan
___
Xen-devel
On Mon, Oct 01, 2018 at 03:25:36PM +0100, George Dunlap wrote:
> On 10/01/2018 03:00 PM, Jan Beulich wrote:
> On 01.10.18 at 15:38, wrote:
> >> On 10/01/2018 12:25 PM, Jan Beulich wrote:
> >>> I think the main concern
> >>> was with the way migration of the new value was implemented. But I
>
On 01/10/18 16:52, Roger Pau Monné wrote:
> On Wed, Sep 26, 2018 at 01:29:27PM +0100, Andrew Cooper wrote:
>> 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 =
Selecting between single/multiple BAR mode should happen after checking
whether to skip the present device, or else multi-BAR devices won't be
skipped correctly, due to port_idx getting set to zero in that case.
Signed-off-by: Jan Beulich
--- a/xen/drivers/char/ns16550.c
+++
On Wed, Sep 26, 2018 at 11:32:38AM +0100, 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
On Wed, Sep 26, 2018 at 01:29:27PM +0100, Andrew Cooper wrote:
> 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;
> >
>
On 10/01/2018 04:40 PM, Andrew Cooper wrote:
> On 01/10/18 16:35, Wei Liu wrote:
>> On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
>>> On 10/01/2018 04:17 PM, Wei Liu wrote:
On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
On 01.10.18 at 16:33, wrote:
On 09/28/2018 05:19 PM, Razvan Cojocaru wrote:
> On 9/28/18 6:55 PM, Jan Beulich wrote:
> On 28.09.18 at 17:25, wrote:
>>> On 9/28/18 5:52 PM, Jan Beulich wrote:
>>> On 28.09.18 at 13:55, wrote:
> @@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
>
On 01/10/18 16:35, Wei Liu wrote:
> On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
>> On 10/01/2018 04:17 PM, Wei Liu wrote:
>>> On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
>>> On 01.10.18 at 16:33, wrote:
> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan
On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
> On 10/01/2018 04:17 PM, Wei Liu wrote:
> > On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
> > On 01.10.18 at 16:33, wrote:
> >>> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
> >>> On 30.09.18 at
Hi,
On 10/01/2018 04:27 PM, Roger Pau Monné wrote:
On Tue, Sep 25, 2018 at 08:36:36PM +0100, Julien Grall wrote:
Hi Roger,
Sorry for the late reply.
On 09/03/2018 03:40 PM, Roger Pau Monné wrote:
On Mon, Sep 03, 2018 at 12:15:16PM +0100, Julien Grall wrote:
On 03/09/18 12:09, Julien Grall
Can I please get an Ack or otherwise from the AMD maintainers?
Thanks, Roger.
On Fri, Sep 21, 2018 at 05:20:47PM +0200, Roger Pau Monne wrote:
> And just rely on arch_iommu_hwdom_init to setup the correct inclusive
> mappings as it's done for Intel.
>
> AMD has code in amd_iommu_hwdom_init to
>>> On 01.10.18 at 17:17, wrote:
> On 01/10/18 14:29, Jan Beulich wrote:
> On 01.10.18 at 14:39, wrote:
>>> On 07/06/18 14:08, Olaf Hering wrote:
Add an option to control when vTSC emulation will be activated for a
domU with tsc_mode=default. Without such option each TSC access
On Tue, Sep 25, 2018 at 08:36:36PM +0100, Julien Grall wrote:
> Hi Roger,
>
> Sorry for the late reply.
>
> On 09/03/2018 03:40 PM, Roger Pau Monné wrote:
> > On Mon, Sep 03, 2018 at 12:15:16PM +0100, Julien Grall wrote:
> > > On 03/09/18 12:09, Julien Grall wrote:
> > > >
> > > >
> > > > On
>
> When SILO is enabled, there would be no page-sharing or event notifications
> between unprivileged VMs (no grant tables or event channels).
>
> Signed-off-by: Xin Li
>
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
On 10/01/2018 04:17 PM, Wei Liu wrote:
> On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
> On 01.10.18 at 16:33, wrote:
>>> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
>>> On 30.09.18 at 23:59, wrote:
> flight 128240 xen-unstable real [real]
>
On 01/10/18 14:29, Jan Beulich wrote:
On 01.10.18 at 14:39, wrote:
>> On 07/06/18 14:08, Olaf Hering wrote:
>>> Add an option to control when vTSC emulation will be activated for a
>>> domU with tsc_mode=default. Without such option each TSC access from
>>> domU will be emulated, which
>
> Introduce new boot parameter xsm to choose which xsm module is enabled,
> and set default to dummy.
>
> Signed-off-by: Xin Li
Acked-by: Daniel De Graaf
It might be useful for the commit message to also reference the new Kconfig
option; thanks for adding it.
On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
> >>> On 01.10.18 at 16:33, wrote:
> > On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
> >> >>> On 30.09.18 at 23:59, wrote:
> >> > flight 128240 xen-unstable real [real]
> >> >
>>> On 01.10.18 at 16:28, wrote:
> On Mon, 2018-10-01 at 14:54 +0100, George Dunlap wrote:
>> Right, the whole point of idle loop scrubbing is that you *don't*
>> syncronously wait for *all* the memory to finish scrubbing before you
>> can use part of it. So why is this an issue for you guys --
>>> On 01.10.18 at 16:40, wrote:
> On 01/10/18 12:13, Jan Beulich wrote:
> On 01.10.18 at 11:58, wrote:
>>> After this patch, alloc_heap_pages() is guaranteed to return scrubbed
>>> pages to a caller unless MEMF_no_scrub flag was provided.
>>
>> I also don't understand the point of this:
>>> On 01.10.18 at 16:11, wrote:
> I think this is the main argument here: what to do about those security
> sensitive use cases? Scrubbing everything unconditionally might be a too
> radical approach. Would inroducing a new cmdline param be appropriate?
Yes, I'm surely fine with this being an
>>> On 01.10.18 at 16:33, wrote:
> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
>> >>> On 30.09.18 at 23:59, wrote:
>> > flight 128240 xen-unstable real [real]
>> > http://logs.test-lab.xenproject.org/osstest/logs/128240/
>> >
>> > Regressions :-(
>> >
>> > Tests which did not
flight 128283 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128283/
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
On 01/10/18 14:57, Boris Ostrovsky wrote:
> On 10/1/18 9:50 AM, George Dunlap wrote:
>> On 10/01/2018 02:44 PM, Boris Ostrovsky wrote:
>>> On 10/1/18 9:12 AM, Andrew Cooper wrote:
On 01/10/18 12:13, Jan Beulich wrote:
On 01.10.18 at 11:58, wrote:
>> Having the allocator return
On 01/10/18 12:13, Jan Beulich wrote:
On 01.10.18 at 11:58, wrote:
>> Having the allocator return unscrubbed pages is a potential security
>> concern: some domain can be given pages with memory contents of another
>> domain. This may happen, for example, if a domain voluntarily releases
>>
On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
> >>> On 30.09.18 at 23:59, wrote:
> > flight 128240 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/128240/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including
On Mon, 2018-10-01 at 14:54 +0100, George Dunlap wrote:
> On 10/01/2018 02:44 PM, Sergey Dyasli wrote:
> > On Mon, 2018-10-01 at 07:38 -0600, Jan Beulich wrote:
> > > > > > On 01.10.18 at 15:12, wrote:
> > > >
> > > > On 01/10/18 12:13, Jan Beulich wrote:
> > > > > > > > On 01.10.18 at 11:58,
flight 128277 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128277/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 04d432fdc0c15f2da76dac4a9a5caf1aeb051ef0
baseline version:
freebsd
On 10/01/2018 03:00 PM, Jan Beulich wrote:
On 01.10.18 at 15:38, wrote:
>> On 10/01/2018 12:25 PM, Jan Beulich wrote:
>>> I think the main concern
>>> was with the way migration of the new value was implemented. But I
>>> really have to defer to Andrew for that, irrespective of him not
>>>
On Mon, 2018-10-01 at 07:38 -0600, Jan Beulich wrote:
> > > > On 01.10.18 at 15:12, wrote:
> >
> > On 01/10/18 12:13, Jan Beulich wrote:
> > > > > > On 01.10.18 at 11:58, wrote:
> > > >
> > > > Having the allocator return unscrubbed pages is a potential security
> > > > concern: some domain
>>> On 01.10.18 at 15:55, wrote:
> On 01/10/18 11:25, Jan Beulich wrote:
> On 01.10.18 at 12:23, wrote:
>>> On 01/10/18 11:14, Jan Beulich wrote:
>>> On 01.10.18 at 12:02, wrote:
> On 01/10/18 10:08, Jan Beulich wrote:
> On 28.09.18 at 19:22, wrote:
>>> +static char
>>> On 01.10.18 at 15:38, wrote:
> On 10/01/2018 12:25 PM, Jan Beulich wrote:
>> I think the main concern
>> was with the way migration of the new value was implemented. But I
>> really have to defer to Andrew for that, irrespective of him not
>> having responded (on the list) to prior pings.
>
On 01/10/18 14:24, Ian Jackson wrote:
>
>>> handle_tsc_info has no code to verify that padding is indeed zero. Due
>>> to the lack of a version field it is impossible to know if the sender
>>> already has the newly introduced vtsc_tolerance field. In the worst
>>> case the receiving domU will get
On 10/1/18 9:50 AM, George Dunlap wrote:
> On 10/01/2018 02:44 PM, Boris Ostrovsky wrote:
>> On 10/1/18 9:12 AM, Andrew Cooper wrote:
>>> On 01/10/18 12:13, Jan Beulich wrote:
>>> On 01.10.18 at 11:58, wrote:
> Having the allocator return unscrubbed pages is a potential security
>
On 01/10/18 14:50, George Dunlap wrote:
> On 10/01/2018 02:44 PM, Boris Ostrovsky wrote:
>> On 10/1/18 9:12 AM, Andrew Cooper wrote:
>>> On 01/10/18 12:13, Jan Beulich wrote:
>>> On 01.10.18 at 11:58, wrote:
> Having the allocator return unscrubbed pages is a potential security
>
On 01/10/18 11:25, Jan Beulich wrote:
On 01.10.18 at 12:23, wrote:
>> On 01/10/18 11:14, Jan Beulich wrote:
>> On 01.10.18 at 12:02, wrote:
On 01/10/18 10:08, Jan Beulich wrote:
On 28.09.18 at 19:22, wrote:
>> +static char *print_domain(char *str, char *end, const
On 10/01/2018 02:44 PM, Sergey Dyasli wrote:
> On Mon, 2018-10-01 at 07:38 -0600, Jan Beulich wrote:
> On 01.10.18 at 15:12, wrote:
>>>
>>> On 01/10/18 12:13, Jan Beulich wrote:
>>> On 01.10.18 at 11:58, wrote:
>
> Having the allocator return unscrubbed pages is a potential
On 10/01/2018 02:44 PM, Boris Ostrovsky wrote:
> On 10/1/18 9:12 AM, Andrew Cooper wrote:
>> On 01/10/18 12:13, Jan Beulich wrote:
>> On 01.10.18 at 11:58, wrote:
Having the allocator return unscrubbed pages is a potential security
concern: some domain can be given pages with memory
On 10/1/18 9:12 AM, Andrew Cooper wrote:
> On 01/10/18 12:13, Jan Beulich wrote:
> On 01.10.18 at 11:58, wrote:
>>> Having the allocator return unscrubbed pages is a potential security
>>> concern: some domain can be given pages with memory contents of another
>>> domain. This may happen, for
On Mon, 2018-10-01 at 07:38 -0600, Jan Beulich wrote:
> > > > On 01.10.18 at 15:12, wrote:
> >
> > On 01/10/18 12:13, Jan Beulich wrote:
> > > > > > On 01.10.18 at 11:58, wrote:
> > > >
> > > > Having the allocator return unscrubbed pages is a potential security
> > > > concern: some domain
The system Intel have handed me for AVX512 emulator work ("Gigabyte
Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3
Pro-CF, BIOS F3 12/28/2017") would not come up under Xen - it hung in
the middle of Dom0 PCI initialization. As it turned out, Xen's time
management did not work
>>> On 01.10.18 at 15:12, wrote:
> On 01/10/18 12:13, Jan Beulich wrote:
> On 01.10.18 at 11:58, wrote:
>>> Having the allocator return unscrubbed pages is a potential security
>>> concern: some domain can be given pages with memory contents of another
>>> domain. This may happen, for
On 10/01/2018 12:25 PM, Jan Beulich wrote:
On 01.10.18 at 12:52, wrote:
>> Olaf Hering writes ("Re: [PATCH v9] new config option vtsc_tolerance_khz to
>> avoid TSC emulation"):
>>> Am Thu, 13 Sep 2018 09:39:13 +0200
>>> schrieb Olaf Hering :
this patch was not applied yet, even after a
Hi Andrew,
On 10/01/2018 02:11 PM, Andrew Cooper wrote:
On 01/10/18 13:46, Julien Grall wrote:
call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
do SMCCC call, replace all call to the former by the later.
Signed-off-by: Julien Grall
---
Changes in v3:
-
>>> On 01.10.18 at 14:39, wrote:
> On 07/06/18 14:08, Olaf Hering wrote:
>> Add an option to control when vTSC emulation will be activated for a
>> domU with tsc_mode=default. Without such option each TSC access from
>> domU will be emulated, which causes a significant perfomance drop for
>>
On 10/01/2018 02:12 PM, Andrew Cooper wrote:
> On 01/10/18 12:13, Jan Beulich wrote:
> On 01.10.18 at 11:58, wrote:
>>> Having the allocator return unscrubbed pages is a potential security
>>> concern: some domain can be given pages with memory contents of another
>>> domain. This may happen,
Jan Beulich writes ("Re: [PATCH v9] new config option vtsc_tolerance_khz to
avoid TSC emulation"):
> Problem is - discussion around this was (iirc) happening not only on
> the list, but also on irc (including perhaps private chats).
Hrm. Well, if it didn't happen on the list, it didn't happen.
Hi,
On 10/01/2018 01:46 PM, Julien Grall wrote:
PLATFORM_START(seattle, "SEATTLE")
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 941eec921b..4ae6504f3e 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -42,42 +42,53 @@ uint32_t smccc_ver;
static uint32_t
On 01/10/18 12:13, Jan Beulich wrote:
On 01.10.18 at 11:58, wrote:
>> Having the allocator return unscrubbed pages is a potential security
>> concern: some domain can be given pages with memory contents of another
>> domain. This may happen, for example, if a domain voluntarily releases
>>
On 01/10/18 13:46, Julien Grall wrote:
> call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
> do SMCCC call, replace all call to the former by the later.
>
> Signed-off-by: Julien Grall
>
> ---
>
> Changes in v3:
> - Use PSCI_RET where needed
> ---
>
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 that is
fully compatible with ARM SMCCC v1.0.
This patch adds a wrapper for both arm32 and arm64. In the
flight 128279 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128279/
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
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
ALTERNATIVE. With that the check is just reduced to 1
call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
do SMCCC call, replace all call to the former by the later.
Signed-off-by: Julien Grall
---
Changes in v3:
- Use PSCI_RET where needed
---
xen/arch/arm/Makefile| 1 -
Hi all,
This patch series contains fixup and improvement for the SMCCC subsystem.
Cheers,
Julien Grall (3):
xen/arm: cpufeature: Add helper to check constant caps
xen/arm: smccc: Add wrapper to automatically select the calling
convention
xen/arm: Replace call_smc with arm_smccc_smc
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
Reviewed-by: Volodymyr Babchuk
---
Changes in v3:
- Add Stefano's and Volodymyr's reviewed-by
Changes in v2:
- Invert the condition
- Add missing includes
---
xen/arch/arm/psci.c | 4
On 07/06/18 14:08, Olaf Hering wrote:
> Add an option to control when vTSC emulation will be activated for a
> domU with tsc_mode=default. Without such option each TSC access from
> domU will be emulated, which causes a significant perfomance drop for
> workloads that make use of rdtsc.
>
> One
flight 128267 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128267/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
128084
Just like the otherwise similar "xpti=" allows for, to revert back to
built-in defaults.
Signed-off-by: Jan Beulich
---
v2: Split out into separate patch.
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1604,7 +1604,7 @@ certain you don't plan on having
While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
this then became equivalent to "xpti=no". In particular, the presence
of "xpti=" alone on the command line means nothing as to which default
is to be overridden;
Use separate tracking variables for the hardware domain and DomU-s.
No functional change intended, but adjust the comment in
init_speculation_mitigations() to match prior as well as resulting code.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/spec_ctrl.c
+++
Use separate tracking variables for the hardware domain and DomU-s.
No functional change intended.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -182,7 +182,7 @@ unsigned int flush_area_local(const void
*/
On 10/1/18 2:23 PM, George Dunlap wrote:
> On 10/01/2018 12:11 PM, Razvan Cojocaru wrote:
>>
>>
>> On 10/1/18 1:39 PM, Jan Beulich wrote:
>> On 01.10.18 at 11:58, wrote:
Changes since V1:
- Removed unnecessary p2m_lock() in p2m_init_altp2m_ept().
>>>
>>> This was a step in the
On 09/27/2018 06:06 PM, Dario Faggioli wrote:
On Thu, 2018-09-27 at 16:09 +0100, Julien Grall wrote:
Hi,
Hi Dario,
On 09/27/2018 03:32 PM, Dario Faggioli wrote:
On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote:
In one of your e-mail, you wrote:
"Well, our implementation of RCU
The original patch under this title as well as the involved variables
were split up for v2, hopefully addressing the main (yet vague)
review concerns on v1.
1: split opt_xpti
2: split opt_pv_l1tf
3: fix "xpti=" and "pv-l1tf=" yet again
4: support "pv-l1tf=default"
Jan
flight 75332 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75332/
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
Hi Andrew,
On 10/01/2018 10:53 AM, Andrew Cooper wrote:
On 01/10/18 10:43, Julien Grall wrote:
Hi,
On 09/29/2018 12:48 AM, Andrew Cooper wrote:
On 29/09/18 00:45, Stefano Stabellini wrote:
On Sat, 29 Sep 2018, Andrew Cooper wrote:
On 28/09/18 21:35, Julien Grall wrote:
On 09/28/2018
>>> On 01.10.18 at 12:52, wrote:
> Olaf Hering writes ("Re: [PATCH v9] new config option vtsc_tolerance_khz to
> avoid TSC emulation"):
>> Am Thu, 13 Sep 2018 09:39:13 +0200
>> schrieb Olaf Hering :
>> > this patch was not applied yet, even after a few "pings".
>>
>> No reaction since months.
On 10/01/2018 12:11 PM, Razvan Cojocaru wrote:
>
>
> On 10/1/18 1:39 PM, Jan Beulich wrote:
> On 01.10.18 at 11:58, wrote:
>>> Changes since V1:
>>> - Removed unnecessary p2m_lock() in p2m_init_altp2m_ept().
>>
>> This was a step in the right direction, but ...
>>
>>> static void
Hi Paul,
On 10/01/2018 11:51 AM, Paul Durrant wrote:
-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 01 October 2018 11:37
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Jun Nakajima ; George Dunlap
; Jan Beulich ; Andrew Cooper
; Stefano Stabellini
1 - 100 of 139 matches
Mail list logo
