In the following situation a vcpu waiting for a lock might not be
woken up from xen_poll_irq():
CPU 1:CPU 2: CPU 3:
takes a spinlock
tries to get lock
-> xen_qlock_wait()
-> xen_clear_irq_pendi
The Xen specific queue spinlock wait function has two issues which
could result in a hanging system.
They have a similar root cause of clearing a pending wakeup of a
waiting vcpu and later going to sleep waiting for the just cleared
wakeup event, which of course won't ever happen.
Juergen Gross (
xen_qlock_wait() isn't safe for nested calls due to interrupts. A call
of xen_qlock_kick() might be ignored in case a deeper nesting level
was active right before the call of xen_poll_irq():
CPU 1: CPU 2:
spin_lock(lock1)
s
Correcting Waiman's mail address
On 01/10/2018 09:16, Juergen Gross wrote:
> The Xen specific queue spinlock wait function has two issues which
> could result in a hanging system.
>
> They have a similar root cause of clearing a pending wakeup of a
> waiting vcpu and later going to sleep waiting
Correcting Waiman's mail address
On 01/10/2018 09:16, Juergen Gross wrote:
> In the following situation a vcpu waiting for a lock might not be
> woken up from xen_poll_irq():
>
> CPU 1:CPU 2: CPU 3:
> takes a spinlock
> tries to get lock
Correcting Waiman's mail address
On 01/10/2018 09:16, Juergen Gross wrote:
> xen_qlock_wait() isn't safe for nested calls due to interrupts. A call
> of xen_qlock_kick() might be ignored in case a deeper nesting level
> was active right before the call of xen_poll_irq():
>
> CPU 1:
On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
[...]
I haven't read the patch itself but I just wanted to note one thing
about this part
> For paravirtualized devices it is relevant that memory is onlined as
> quickly as possible after adding - and that it is added to the NORMAL
> zone. Other
>>> On 01.10.18 at 09:16, wrote:
> In the following situation a vcpu waiting for a lock might not be
> woken up from xen_poll_irq():
>
> CPU 1:CPU 2: CPU 3:
> takes a spinlock
> tries to get lock
> -> xen_qlock_wait(
On 01/10/2018 10:54, Jan Beulich wrote:
On 01.10.18 at 09:16, wrote:
>> In the following situation a vcpu waiting for a lock might not be
>> woken up from xen_poll_irq():
>>
>> CPU 1:CPU 2: CPU 3:
>> takes a spinlock
>> tries to get l
>>> On 01.10.18 at 09:16, wrote:
> xen_qlock_wait() isn't safe for nested calls due to interrupts. A call
> of xen_qlock_kick() might be ignored in case a deeper nesting level
> was active right before the call of xen_poll_irq():
>
> CPU 1: CPU 2:
> spin_lock(loc
On 01/10/2018 10:57, Jan Beulich wrote:
On 01.10.18 at 09:16, wrote:
>> xen_qlock_wait() isn't safe for nested calls due to interrupts. A call
>> of xen_qlock_kick() might be ignored in case a deeper nesting level
>> was active right before the call of xen_poll_irq():
>>
>> CPU 1:
>>> 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 tests which could not be run:
> test-amd64-amd64-migrupgrade 22 guest-migrate/s
>>> On 28.09.18 at 19:22, wrote:
> --- a/xen/common/vsprintf.c
> +++ b/xen/common/vsprintf.c
> @@ -264,6 +264,47 @@ static char *string(char *str, char *end, const char *s,
> return str;
> }
>
> +/* Print a domain id, using names for system domains. (e.g. d0 or d[IDLE])
> */
> +static ch
On 28/09/2018 19:02, Dave Hansen wrote:
> It's really nice if these kinds of things are broken up. First, replace
> the old want_memblock parameter, then add the parameter to the
> __add_page() calls.
Definitely, once we agree that is is not nuts, I will split it up for
the next version :)
>
>>
>>> On 01.10.18 at 11:03, wrote:
> On 01/10/2018 10:57, Jan Beulich wrote:
> On 01.10.18 at 09:16, wrote:
>>> xen_qlock_wait() isn't safe for nested calls due to interrupts. A call
>>> of xen_qlock_kick() might be ignored in case a deeper nesting level
>>> was active right before the call of
On 01/10/2018 10:40, Michal Hocko wrote:
> On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
> [...]
>
> I haven't read the patch itself but I just wanted to note one thing
> about this part
>
>> For paravirtualized devices it is relevant that memory is onlined as
>> quickly as possible after ad
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 12:11 AM, Stefano Stabellini wrote:
On Wed, 26 Sep 2018, Julien Grall wrote:
Hi Stefano,
On 09/25/20
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 12:11 AM, Stefano Stabellini wrote:
>
Ok thanks.
I didn't suspect checkpolicy to be in charge of this. I used the version 2.5 so
far.
-Daniel De Graaf a écrit : -
A : nicolas.poi...@bertin.fr
De : Daniel De Graaf
Date : 28/09/2018 21:13
Cc : George Dunlap , xen-devel
Objet : Re: [Xen-users] XSM/Flask iomem
This is appare
This patch is a pre-requisite for fixing the logdirty VGA issue
(display freezes when switching to a new altp2m view early in a
domain's lifetime), but sent separately for easier review.
The new ept_set_ad_sync() function has been added to update all
active altp2ms' ept.ad. New altp2ms will inherit
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
its own memory (ballooning being the easiest way for doing this).
Change the allocator
Hi Stefano,
On 09/27/2018 11:41 PM, Stefano Stabellini wrote:
On Wed, 26 Sep 2018, Julien Grall wrote:
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 10
On 01/10/18 10:08, Jan Beulich wrote:
On 28.09.18 at 19:22, wrote:
>> --- a/xen/common/vsprintf.c
>> +++ b/xen/common/vsprintf.c
>> @@ -264,6 +264,47 @@ static char *string(char *str, char *end, const char *s,
>> return str;
>> }
>>
>> +/* Print a domain id, using names for system dom
flight 128264 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128264/
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,
On 10/01/2018 10:58 AM, Sergey Dyasli 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
its own memory (ballooning being th
>>> 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 struct domain *d)
>>> +{
>>> +const char *name = NULL;
>>> +
>>> +/* Some debugging may have an optionally-NULL pointer. *
Hi Paul,
On 09/27/2018 03:33 PM, Paul Durrant wrote:
...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU
(rather than the MMU) and hence used for DMA address translation.
This patch is a largely cosmetic change that substitutes the terms 'gfn'
and 'gaddr' for 'dfn' and
Hi Paul,
On 09/27/2018 03:33 PM, Paul Durrant wrote:
This patch modifies the declaration of the entry points to the IOMMU
sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent
patch will similarly modify the methods in the iommu_ops structure.
Signed-off-by: Paul Durrant
Re
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 struct domain *d)
+{
+const char *name = NULL;
+
+/* Some de
Hi Paul,
On 09/27/2018 03:33 PM, Paul Durrant wrote:
This patch removes the implicit domain_crash() from iommu_map(),
unmap_page() and iommu_iotlb_flush() and turns them into straightforward
wrappers that check the existence of the relevant iommu_op and call
through to it. This makes them usable
>>> 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 struct domain *d)
> +{
> +const char
Hi Paul,
On 09/27/2018 03:33 PM, Paul Durrant wrote:
...for some uses of get_page_from_gfn().
There are many occurrences of the following pattern in the code:
q = ? P2M_ALLOC : P2M_UNSHARE;
page = get_page_from_gfn(d, gfn, &p2mt, q);
if ( p2m_is_paging(p2mt) )
{
Hi Paul,
On 09/27/2018 03:33 PM, Paul Durrant wrote:
The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
domain's IOMMU pagetable which, prior to this patch, is not strictly true
since the macro did not test whether the domain actually has IOMMU
mappings.
Well, I think we
>>> 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 ept_enable_pml(struct p2m_domain *p2m)
> {
> +struct domain *d = p2m->domain;
> +
> /* Domain must have been
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 01 October 2018 11:26
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) ; Wei Liu
>
> Subje
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.
> So scrap that patch, just in case it is sti
> -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
> Subject: Re: [PATCH v12 8/9] mm / iommu: inc
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 ept_enable_pml(struct p2m_domain *p2m)
>> {
>> +struct domain
>>> 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
> its own memory (ballooning being the easiest
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
Subj
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 ept_enabl
>>> 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.
>>
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 12:11
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
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
_
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 re
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 right
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
+++ b/xen/arch/x86/spec_ct
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
*/
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; "x
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 PV
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
test-amd64
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 opt
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 instru
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 -
xen/arch/arm/platforms/exynos5.
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
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
Vo
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 1
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 ca
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
> ---
> xen/arch/arm/M
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
>> it
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 psci_cp
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.
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,
>>> 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
>> workl
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:
- Us
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
>>> 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 example
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 beca
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 can
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 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/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 securi
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
> conce
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 stru
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
> conc
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 a
>>> 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 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 *pri
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 can
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
>>> ha
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 a62d8e729c6
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, wr
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 tes
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
>> it
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 un
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 1
>>> 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
>>> 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 op
>>> 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: Xen
>>> 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 -- w
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]
> >> > http://logs.test-lab.xenproject.org/osstest/l
>
> 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 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]
> http://
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 causes
>
> 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
Xen-devel@lists.xenproje
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 23
>>> 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 from
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 se
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 w
1 - 100 of 139 matches
Mail list logo
