Re: [Xen-devel] [PATCH SpectreV1+L1TF v4 03/11] config: introduce L1TF_LFENCE option
>>> On 31.01.19 at 23:39, wrote:
> On 25/01/2019 10:14, Jan Beulich wrote:
> On 24.01.19 at 22:29, wrote:
>>> Worse is the "evaluate condition, stash result, fence, use variable"
>>> option, which is almost completely useless. If you work out the
>>> resulting instruction stream, you'll have a conditional expression
>>> calculated down into a register, then a fence, then a test register and
>>> conditional jump into one of two basic blocks. This takes the perf hit,
>>> and doesn't protect either of the basic blocks for speculative
>>> mis-execution.
>> How does it not protect anything? It shrinks the speculation window
>> to just the register test and conditional branch,
>
> A speculation window starts at a number of arbitrary points, and persist
> until the processor has confirmed the speculation precondition was true
> or false. There can be multiple overlapping speculative windows open at
> a single time.
>
>> which ought to be
>> far smaller than that behind a memory access which fails to hit any
>> of the caches (and perhaps even any of the TLBs). This is the more
>> that LFENCE does specifically not prevent insn fetching from
>> continuing.
>
> I'm afraid that isn't relevant.
>
> For the attack described in this series, the speculation window which
> matters starts with a conditional jump. In this scenario, the fact that
> you have stashed the value and issued a fence doesn't stop an attacker
> from controlling the conditional jump.
>
> The lfence doesn't interact with the branch predictor. Any poisoned
> predictions will survive.
>
> As a result, the only safe course of action is to let the processor
> follow the prediction, *then* wait for speculation to catch up with
> reality and see whether the prediction was correct. As such, code is
> only safe when the fence is at the head of both basic blocks.
>
>> That said I agree that the LFENCE would better sit between the
>> register test and the conditional branch, but as we've said so many
>> times before - this can't be achieved without compiler support.
>
> It also doesn't fix the problem.
>
> Both of these examples do narrow the speculation to just having each
> basic block entered with each others legitimate entry condition, but the
> following code sample is still vulnerable to leakage under these two
> related strategies.
>
> int foo(int a, int b, int c)
> {
> if ( eval_nospec(a) )
> return array_b[b];
> else
> return array_c[c];
> }
All fine, but as you say, speculation starts at the conditional
branch. If the LFENCE sits immediately ahead of it, how far can
speculation actually make it before it gets canceled? I'm not
putting under question that the best we can do is adding one
fence on each side, but as we're anyway debating how to
balance added security vs lost performance, I remain not fully
convinced that this isn't an option someone may want to pick.
>> Then again, following an earlier reply of mine on another sub-
>> thread, nothing really prevents the compiler from moving ahead
>> and folding the two LFENCEs of the "both branches" model into
>> one. It just so happens that apparently right now this never
>> occurs (assuming Norbert has done full generated code analysis
>> to confirm the intended placement).
>
> Following on from that other thread, eval_nospec() is only useful if we
> can guarantee that it places fences at the head of each basic block,
> rather than elsewhere.
We clearly agree on this aspect. The questionable point though
isn't what is useful, but what the compiler might possibly do with
the constructs we add.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 3/9] x86/hvm: block speculative out-of-bound accesses
>>> On 31.01.19 at 21:02, wrote:
> On 31/01/2019 16:19, Jan Beulich wrote:
>>
>>> @@ -4104,6 +4108,12 @@ static int hvmop_set_param(
>>> if ( a.index >= HVM_NR_PARAMS )
>>> return -EINVAL;
>>>
>>> +/*
>>> + * Make sure the guest controlled value a.index is bounded even during
>>> + * speculative execution.
>>> + */
>>> +a.index = array_index_nospec(a.index, HVM_NR_PARAMS);
>> I'd like to come back to this model of updating local variables:
>> Is this really safe to do? If such a variable lives in memory
>> (which here it quite likely does), does speculation always
>> recognize the update to the value? Wouldn't it rather read
>> what's currently in that slot, and re-do the calculation in case
>> a subsequent write happens? (I know I did suggest doing so
>> earlier on, so I apologize if this results in you having to go
>> back to some earlier used model.)
>
> I'm afraid that is a very complicated set of questions to answer.
>
> The processor needs to track write=>read dependencies to avoid wasting a
> large quantity of time doing erroneous speculation, therefore it does.
> Pending writes which have happened under speculation are forwarded to
> dependant instructions.
>
> This behaviour is what gives rise to Bounds Check Bypass Store - a half
> spectre-v1 gadget but with a store rather than a write. You can e.g.
> speculatively modify the return address on the stack, and hijack
> speculation to an attacker controlled address for a brief period of
> time. If the speculation window is long enough, the processor first
> follows the RSB/RAS (correctly), then later notices that the real value
> on the stack was different, discards the speculation from the RSB/RAS
> and uses the attacker controlled value instead, then eventually notices
> that all of this was bogus and rewinds back to the original branch.
>
> Another corner case is Speculative Store Bypass, where memory
> disambiguation speculation can miss the fact that there is a real
> write=>read dependency, and cause speculation using the older stale
> value for a period of time.
>
>
> As to overall safety, array_index_nospec() only works as intended when
> the index remains in a register between the cmp/sbb which bounds it
> under speculation, and the array access. There is no way to guarantee
> this property, as the compiler can spill any value if it thinks it needs to.
>
> The general safety of the construct relies on the fact that an
> optimising compiler will do its very best to avoid spilling variable to
> the stack.
"Its very best" may be extremely limited with enough variables.
Even if we were to annotate them with the "register" keyword,
that still wouldn't help, as that's only a hint. We simply have no
way to control which variables the compiler wants to hold in
registers. I dare to guess that in the particular example above
it's rather unlikely to be put in a register.
In any event it looks like you support my suspicion that earlier
comments of mine may have driven things into a less safe
direction, and we instead need to accept the more heavy
clutter of scattering around array_{access,index}_nospec()
at all use sites instead of latching the result of
array_index_nospec() into whatever shape of local variable.
Which raises another interesting question: Can't CSE and
alike get in the way here? OPTIMIZER_HIDE_VAR() expands
to a non-volatile asm() (and as per remarks elsewhere I'm
unconvinced adding volatile would actually help), so the
compiler recognizing the same multiple times (perhaps in a
loop) could make it decide to calculate the thing just once.
array_index_mask_nospec() in effect is a pure (and actually
even const) function, and the lack of a respective attribute
doesn't make the compiler not treat it as such if it recognized
the fact. (In effect what I had asked Norbert to do to limit
the clutter was just CSE which the compiler may or may not
have recognized anyway. IOW I'm not convinced going back
would actually buy us anything.)
> As with all of these issues, you can only confirm whether
> you are no longer vulnerable by inspecting the eventual compiled code.
Which is nothing one can sensibly do, because any change (to
code or the tool chain) would immediately invalidate all of the
previously accumulated results.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] xen/mem-reservation API and out-of-tree kernel modules
On Thu, Jan 31, 2019 at 01:44:15PM -0800, Stefano Stabellini wrote: > The alternative would be to turn xenmem_reservation_scrub_page into a > regular function (not a static inline)? All that is a moot point until said currently out of tree module gets submitted for inclusion anyway. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] xen/mem-reservation API and out-of-tree kernel modules
On 2/1/19 10:27 AM, Christoph Hellwig wrote: > On Thu, Jan 31, 2019 at 01:44:15PM -0800, Stefano Stabellini wrote: >> The alternative would be to turn xenmem_reservation_scrub_page into a >> regular function (not a static inline)? > All that is a moot point until said currently out of tree module gets > submitted for inclusion anyway. Indeed this is a moot point, so I can't argue here. But this is how it is and unfortunately we have to live with those modules and depend on 3rd parties willing or not to disclose their sources to public... ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] xen/mem-reservation API and out-of-tree kernel modules
On 1/31/19 11:44 PM, Stefano Stabellini wrote:
> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>> Hello,
>>
>> I am working on porting an out-of-tree kernel driver to the kernel
>> 5.0 and that driver uses functionality provided by
>> drivers/xen/mem-reservation.c
>> module. Since commit [1] it is not possible to build a kernel module
>> which uses mem-reservation API as xen_scrub_pages variable, which is
>> checked in
>> xenmem_reservation_scrub_page, became a kernel module parameter and is
>> now only
>> accessible for built-in modules:
>>
>> static inline void xenmem_reservation_scrub_page(struct page *page)
>> ^
>> {
>> if (xen_scrub_pages)
>> ^^^
>> clear_highpage(page);
>> }
>>
>> This results in link-time warning:
>>
>> WARNING: "xen_scrub_pages" [yourmodule.ko] undefined!
>>
>> and thus not allowing the module to run. At the moment I can only see a
>> possible fix
>> for this by making the following change:
>>
>> diff --git a/drivers/xen/mem-reservation.c b/drivers/xen/mem-reservation.c
>> index 3782cf070338..85fecfec50e1 100644
>> --- a/drivers/xen/mem-reservation.c
>> +++ b/drivers/xen/mem-reservation.c
>> @@ -18,6 +18,7 @@
>>
>> bool __read_mostly xen_scrub_pages =
>> IS_ENABLED(CONFIG_XEN_SCRUB_PAGES_DEFAULT);
>> core_param(xen_scrub_pages, xen_scrub_pages, bool, 0);
>> +EXPORT_SYMBOL(xen_scrub_pages);
>>
>> but this looks a bit unusual for the kernel?
>>
>> I am looking for community advice here and help
>>
>> Thank you,
>> Oleksandr
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197ecb3802c04499d8ff4f8cb28f6efa008067db
> The alternative would be to turn xenmem_reservation_scrub_page into a
> regular function (not a static inline)?
Yes, it seems there is no other reasonable solution to this, but
a regular function. I'll send a patch for that
Thank you,
Oleksandr
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] xen/mem-reservation API and out-of-tree kernel modules
On Fri, Feb 01, 2019 at 08:38:43AM +, Oleksandr Andrushchenko wrote: > On 2/1/19 10:27 AM, Christoph Hellwig wrote: > > On Thu, Jan 31, 2019 at 01:44:15PM -0800, Stefano Stabellini wrote: > >> The alternative would be to turn xenmem_reservation_scrub_page into a > >> regular function (not a static inline)? > > All that is a moot point until said currently out of tree module gets > > submitted for inclusion anyway. > Indeed this is a moot point, so I can't argue here. > But this is how it is and unfortunately we have to live > with those modules and depend on 3rd parties willing or not > to disclose their sources to public... The point is that the kernel does generally not export interfaces not used by in-tree modules. So there is no reason to change anything here. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH -next] drm/xen-front: Drop pointless static qualifier in fb_destroy()
On 1/28/19 8:36 AM, Oleksandr Andrushchenko wrote:
> On 1/26/19 2:05 PM, YueHaibing wrote:
>> There is no need to have the 'struct drm_framebuffer *fb' variable
>> static since new value always be assigned before use it.
>>
>> Signed-off-by: YueHaibing
> Good catch, thank you!
> Reviewed-by: Oleksandr Andrushchenko
If nobody objects I'll apply this to drm-misc-fixes next Monday
>> ---
>> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
>> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
>> index 860da05..c2955d3 100644
>> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
>> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
>> @@ -54,7 +54,7 @@ static void fb_destroy(struct drm_framebuffer *fb)
>> const struct drm_mode_fb_cmd2 *mode_cmd)
>> {
>> struct xen_drm_front_drm_info *drm_info = dev->dev_private;
>> - static struct drm_framebuffer *fb;
>> + struct drm_framebuffer *fb;
>> struct drm_gem_object *gem_obj;
>> int ret;
>>
>>
>>
>>
>>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] drm/xen-front: Fix mmap attributes for display buffers
On 1/30/19 11:09 AM, Oleksandr Andrushchenko wrote:
> On 1/29/19 9:07 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> When GEM backing storage is allocated those are normal pages,
>>> so there is no point using pgprot_writecombine while mmaping.
>>> This fixes mismatch of buffer pages' memory attributes between
>>> the frontend and backend which may cause screen artifacts.
>>>
>>> Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
>>> frontend")
>>>
>>> Signed-off-by: Oleksandr Andrushchenko
>>>
>>> Suggested-by: Julien Grall
>>> ---
>>> drivers/gpu/drm/xen/xen_drm_front_gem.c | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
>>> b/drivers/gpu/drm/xen/xen_drm_front_gem.c
>>> index d303a2e17f5e..9d5c03d7668d 100644
>>> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
>>> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
>>> @@ -235,8 +235,7 @@ static int gem_mmap_obj(struct xen_gem_object
>>> *xen_obj,
>>> vma->vm_flags &= ~VM_PFNMAP;
>>> vma->vm_flags |= VM_MIXEDMAP;
>>> vma->vm_pgoff = 0;
>>> - vma->vm_page_prot =
>>> - pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
>>> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>>
>> The patch looks good to me. It would be worth expanding the comment a
>> bit before to explain that we overwrite vm_page_prot to use cacheable
>> attribute as required by the Xen ABI.
>>
> Ok, then I'll put:
>
> + /*
> + * According to Xen on ARM ABI (xen/include/public/arch-arm.h):
> + * all memory which is shared with other entities in the system
> + * (including the hypervisor and other guests) must reside in
> memory
> + * which is mapped as Normal Inner Write-Back Outer Write-Back
> + * Inner-Shareable.
> + */
> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> Please let me know if this is not what you want
>> With the comment updated:
>>
>> Acked-by: Julien Grall
>>
If nobody objects I'll apply this to drm-misc-fixes next Monday
>> Cheers,
>>
> Thank you,
> Oleksandr
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH SpectreV1+L1TF v4 04/11] x86/hvm: block speculative out-of-bound accesses
>>> On 31.01.19 at 20:31, wrote: > On 23/01/2019 11:51, Norbert Manthey wrote: >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -37,6 +37,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -2102,7 +2103,7 @@ int hvm_mov_from_cr(unsigned int cr, unsigned int gpr) >> case 2: >> case 3: >> case 4: >> -val = curr->arch.hvm.guest_cr[cr]; >> +val = array_access_nospec(curr->arch.hvm.guest_cr, cr); > > This is an interesting case - we don't actually need protection here. > > This path is called exclusively from intercepts, so cr is strictly one > of 0, 2, 3, 4, 8 even under adversarial speculation. However, as > guest_cr[] is only 5 entries long, the 8 case can still result in an OoB > read. > > However, given that the 8 index is in the hw_cr[] array and guaranteed > to be in the cache by this point, an attacker can't gain any additional > information by poisoning the switch logic. Question though is - do we want to make the safety of our code dependent on such (easily and un-noticeably changeable) layout considerations? I'm not opposed (and I've used similar arguments for overruns by 1 elsewhere, albeit in cases where the layout wasn't as far away from the code in question as it is here, and where the two fields were adjacent), but perhaps we'd then want a BUILD_BUG_ON() with a suitable comment (and carefully coded to avoid potential array-index-out-of- bounds diagnostics)? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] xen/mem-reservation API and out-of-tree kernel modules
On 01/02/2019 09:39, Oleksandr Andrushchenko wrote:
> On 1/31/19 11:44 PM, Stefano Stabellini wrote:
>> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>>> Hello,
>>>
>>> I am working on porting an out-of-tree kernel driver to the kernel
>>> 5.0 and that driver uses functionality provided by
>>> drivers/xen/mem-reservation.c
>>> module. Since commit [1] it is not possible to build a kernel module
>>> which uses mem-reservation API as xen_scrub_pages variable, which is
>>> checked in
>>> xenmem_reservation_scrub_page, became a kernel module parameter and is
>>> now only
>>> accessible for built-in modules:
>>>
>>> static inline void xenmem_reservation_scrub_page(struct page *page)
>>> ^
>>> {
>>> if (xen_scrub_pages)
>>> ^^^
>>> clear_highpage(page);
>>> }
>>>
>>> This results in link-time warning:
>>>
>>> WARNING: "xen_scrub_pages" [yourmodule.ko] undefined!
>>>
>>> and thus not allowing the module to run. At the moment I can only see a
>>> possible fix
>>> for this by making the following change:
>>>
>>> diff --git a/drivers/xen/mem-reservation.c b/drivers/xen/mem-reservation.c
>>> index 3782cf070338..85fecfec50e1 100644
>>> --- a/drivers/xen/mem-reservation.c
>>> +++ b/drivers/xen/mem-reservation.c
>>> @@ -18,6 +18,7 @@
>>>
>>> bool __read_mostly xen_scrub_pages =
>>> IS_ENABLED(CONFIG_XEN_SCRUB_PAGES_DEFAULT);
>>> core_param(xen_scrub_pages, xen_scrub_pages, bool, 0);
>>> +EXPORT_SYMBOL(xen_scrub_pages);
>>>
>>> but this looks a bit unusual for the kernel?
>>>
>>> I am looking for community advice here and help
>>>
>>> Thank you,
>>> Oleksandr
>>>
>>> [1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197ecb3802c04499d8ff4f8cb28f6efa008067db
>> The alternative would be to turn xenmem_reservation_scrub_page into a
>> regular function (not a static inline)?
> Yes, it seems there is no other reasonable solution to this, but
> a regular function. I'll send a patch for that
What would you gain? This function would need to be exported.
So its either the variable or the function.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.10-testing test] 132630: tolerable FAIL - PUSHED
>>> On 01.02.19 at 00:45, wrote: > flight 132630 xen-4.10-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/132630/ > > Failures :-/ but no regressions. > > Tests which are failing intermittently (not blocking): > test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in > 132577 pass in 132630 > test-xtf-amd64-amd64-2 69 xtf/test-hvm64-xsa-278 fail pass in > 132577 > test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail pass in > 132577 > test-xtf-amd64-amd64-4 69 xtf/test-hvm64-xsa-278 fail pass in > 132577 Could you help me with some confusion this causes to me: As per http://logs.test-lab.xenproject.org/osstest/results/history/test-xtf-amd64-amd64-1/xen-4.10-testing.html etc this flight passed, whereas http://logs.test-lab.xenproject.org/osstest/logs/132630/test-xtf-amd64-amd64-1/info.html etc indeed show a failure for the particular step. Why is the overall test status "(pass)" in this case? This seems to be particularly unhelpful for older flights, where the details page is no longer available. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12 v4 2/3] x86/svm: Drop enum instruction_index and simplify svm_get_insn_len()
>>> On 31.01.19 at 19:24, wrote: > Passing a 32-bit integer index into an array with entries containing less > than > 32 bits of data is wasteful, and creates an unnecessary error condition of > passing an out-of-range index. > > The width of the X86EMUL_OPC() encoding is currently 20 bits for the > instructions used, which leaves room for a modrm byte. Drop opc_tab[] > entirely, and encode the expected opcode/modrm information directly. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] xen/mem-reservation API and out-of-tree kernel modules
On 2/1/19 11:14 AM, Juergen Gross wrote:
> On 01/02/2019 09:39, Oleksandr Andrushchenko wrote:
>> On 1/31/19 11:44 PM, Stefano Stabellini wrote:
>>> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
Hello,
I am working on porting an out-of-tree kernel driver to the kernel
5.0 and that driver uses functionality provided by
drivers/xen/mem-reservation.c
module. Since commit [1] it is not possible to build a kernel module
which uses mem-reservation API as xen_scrub_pages variable, which is
checked in
xenmem_reservation_scrub_page, became a kernel module parameter and is
now only
accessible for built-in modules:
static inline void xenmem_reservation_scrub_page(struct page *page)
^
{
if (xen_scrub_pages)
^^^
clear_highpage(page);
}
This results in link-time warning:
WARNING: "xen_scrub_pages" [yourmodule.ko] undefined!
and thus not allowing the module to run. At the moment I can only see a
possible fix
for this by making the following change:
diff --git a/drivers/xen/mem-reservation.c b/drivers/xen/mem-reservation.c
index 3782cf070338..85fecfec50e1 100644
--- a/drivers/xen/mem-reservation.c
+++ b/drivers/xen/mem-reservation.c
@@ -18,6 +18,7 @@
bool __read_mostly xen_scrub_pages =
IS_ENABLED(CONFIG_XEN_SCRUB_PAGES_DEFAULT);
core_param(xen_scrub_pages, xen_scrub_pages, bool, 0);
+EXPORT_SYMBOL(xen_scrub_pages);
but this looks a bit unusual for the kernel?
I am looking for community advice here and help
Thank you,
Oleksandr
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197ecb3802c04499d8ff4f8cb28f6efa008067db
>>> The alternative would be to turn xenmem_reservation_scrub_page into a
>>> regular function (not a static inline)?
>> Yes, it seems there is no other reasonable solution to this, but
>> a regular function. I'll send a patch for that
> What would you gain? This function would need to be exported.
Yes, this is true, the function should be exported then
> So its either the variable or the function.
I am a bit confused with this because I'll have to export
module parameter in this case, e.g.
core_param(xen_scrub_pages, xen_scrub_pages, bool, 0);
EXPORT_SYMBOL(xen_scrub_pages);
which looks a bit unusual to me
>
> Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Scheduling and the periodic timer
On 01/02/2019 07:26, Juergen Gross wrote: > While working on my core scheduling series I stumbled over the periodic > timer. Could it be this timer never worked correctly? > > When the vcpu with an active periodic timer is running everything seems > to be fine. But when not running the timer is stopped in schedule(). So > a vcpu going to idle relying to be woken up by the periodic timer will > remain sleeping until another event is happening. The periodic timer > won't fire as it is stopped. > > The periodic timer is used via VCPUOP_set_periodic_timer only, and > today's Linux kernel isn't using it at all. So I guess this timer not > really working as it should is no big issue. > > I just wanted to mention that fact, maybe someone is keen repairing > this issue. Do you mean to say that, after the next schedule(), any configured periodic timer ceases to provide further interrupts? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Scheduling and the periodic timer
>>> On 01.02.19 at 08:26, wrote: > While working on my core scheduling series I stumbled over the periodic > timer. Could it be this timer never worked correctly? > > When the vcpu with an active periodic timer is running everything seems > to be fine. But when not running the timer is stopped in schedule(). So > a vcpu going to idle relying to be woken up by the periodic timer will > remain sleeping until another event is happening. The periodic timer > won't fire as it is stopped. > > The periodic timer is used via VCPUOP_set_periodic_timer only, and > today's Linux kernel isn't using it at all. So I guess this timer not > really working as it should is no big issue. Interesting. Our kernels have been using it until SLE11 SP1, as did the old 2.6.18 one that all of our old kernels were derived from. Yet the same code is present already in 3.2.0's schedule(). Are you sure this timer is meant to wake the vCPU at the set rate, rather than just surfacing events if the vCPU is running? Looking at vcpu_periodic_timer_work()'s calculation of the next event time also suggests to me that there's no guarantee that the event will indeed surface at the set rate. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Scheduling and the periodic timer
On 01/02/2019 10:40, Andrew Cooper wrote: > On 01/02/2019 07:26, Juergen Gross wrote: >> While working on my core scheduling series I stumbled over the periodic >> timer. Could it be this timer never worked correctly? >> >> When the vcpu with an active periodic timer is running everything seems >> to be fine. But when not running the timer is stopped in schedule(). So >> a vcpu going to idle relying to be woken up by the periodic timer will >> remain sleeping until another event is happening. The periodic timer >> won't fire as it is stopped. >> >> The periodic timer is used via VCPUOP_set_periodic_timer only, and >> today's Linux kernel isn't using it at all. So I guess this timer not >> really working as it should is no big issue. >> >> I just wanted to mention that fact, maybe someone is keen repairing >> this issue. > > Do you mean to say that, after the next schedule(), any configured > periodic timer ceases to provide further interrupts? No, it just won't wake the vcpu up. As soon as the vcpu is running the timer will run again and it will provide interrupts again. In case an interrupt was due during the vcpu was not running that interrupt will be delivered as soon as the vcpu starts running again. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Scheduling and the periodic timer
On 01/02/2019 10:50, Jan Beulich wrote: On 01.02.19 at 08:26, wrote: >> While working on my core scheduling series I stumbled over the periodic >> timer. Could it be this timer never worked correctly? >> >> When the vcpu with an active periodic timer is running everything seems >> to be fine. But when not running the timer is stopped in schedule(). So >> a vcpu going to idle relying to be woken up by the periodic timer will >> remain sleeping until another event is happening. The periodic timer >> won't fire as it is stopped. >> >> The periodic timer is used via VCPUOP_set_periodic_timer only, and >> today's Linux kernel isn't using it at all. So I guess this timer not >> really working as it should is no big issue. > > Interesting. Our kernels have been using it until SLE11 SP1, as > did the old 2.6.18 one that all of our old kernels were derived > from. Yet the same code is present already in 3.2.0's schedule(). > Are you sure this timer is meant to wake the vCPU at the set > rate, rather than just surfacing events if the vCPU is running? > Looking at vcpu_periodic_timer_work()'s calculation of the > next event time also suggests to me that there's no guarantee > that the event will indeed surface at the set rate. That's correct. The set rate just is the minimum time between two interrupts. The usability of such a timer is questionable in the best case IMO. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
On 01.02.19 01:14, Julien Grall wrote: With the current interface workaround, we are still playing with devil (see [2]). So it would be nice to get a new interface that does not use virtual address. I'm sorry for my ignorance, I know nearly nothing about runstate areas implementation, but why not to setup a shared page(s) for the purpose? [2] <9fa77816-a25c-c19b-cc26-e0d28cc2e...@citrix.com> Could you please suggest how to follow that link? -- Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
On 31.01.19 23:56, Stefano Stabellini wrote: I ran into this problem as well not too long ago too. It is very annoying and it is basically impossible to work-around, the only thing possible would be to suppress the warning, but that doesn't even count as a work-around :-) Well, yet it is adopted for non-debug builds de facto :\ -- Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
Hi, On 2/1/19 10:02 AM, Andrii Anisov wrote: On 01.02.19 01:14, Julien Grall wrote: With the current interface workaround, we are still playing with devil (see [2]). So it would be nice to get a new interface that does not use virtual address. I'm sorry for my ignorance, I know nearly nothing about runstate areas implementation, but why not to setup a shared page(s) for the purpose? This is actually a shared page, the page is allocated by the domain and shared with Xen. So what do you mean? [2] <9fa77816-a25c-c19b-cc26-e0d28cc2e...@citrix.com> Could you please suggest how to follow that link? That's not a link but a Message-ID. You can either use your favorite client for looking the e-mail or use http://marc.info?i=. For instance: http://marc.info?i=<9fa77816-a25c-c19b-cc26-e0d28cc2e...@citrix.com> Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
On 2/1/19 10:07 AM, Andrii Anisov wrote: On 31.01.19 23:56, Stefano Stabellini wrote: I ran into this problem as well not too long ago too. It is very annoying and it is basically impossible to work-around, the only thing possible would be to suppress the warning, but that doesn't even count as a work-around :-) Well, yet it is adopted for non-debug builds de facto :\ The thing is the presence of the printk is not the real problem. It only tells you the mapping is inexistent. The problem is if in debug build you don't see at all this message (assuming you have kpti enabled). This would mean you would overwrite a random page. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
On 01.02.19 12:16, Julien Grall wrote: The thing is the presence of the printk is not the real problem. It is the problem when the intention is to play in a sandbox with different things. It only tells you the mapping is inexistent. The problem is if in debug build you don't see at all this message (assuming you have kpti enabled). This would mean you would overwrite a random page. I already have that understanding ;) But curious if XEN 4.12 is going to be released with such the issue remains? -- Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
Hello, On 01.02.19 12:12, Julien Grall wrote: This is actually a shared page, the page is allocated by the domain and shared with Xen. So what do you mean? I'm curious if it can be allocated on hypervisor side. That's not a link but a Message-ID. You can either use your favorite client for looking the e-mail It only works if you have it in the current mailbox, I guess. or use http://marc.info?i=. For instance: http://marc.info?i=<9fa77816-a25c-c19b-cc26-e0d28cc2e...@citrix.com> Good hint! -- Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12 v2] arm: gic-v3: deactivate SGI/PPI during initialization
Hi, We spoke about SPIs in the previous version. Why aren't they de-activated here? On 1/30/19 2:00 PM, Peng Fan wrote: On i.MX8, we implemented partition reboot which means Cortex-A reboot will not impact M4 cores and System control Unit core. However GICv3 is not reset because we also need to support A72 Cluster reboot without affecting A53 Cluster. The gic-v3 controller is configured with EOImode to 1, so during xen reboot, there is a function call "smp_call_function(halt_this_cpu, NULL, 0);" , but halt_this_cpu never return, that means other CPUs have no chance to deactivate the SGI interrupt, because the deactivate_irq operation is at the end of do_sgi. During the next boot of Xen, CPU0 will issue GIC_SGI_CALL_FUNCTION to other CPUs. As the Active state for SGI is left untouched during the reboot, the GIC_SGI_CALL_FUNCTION will still be active on the non-boot CPUs. This means the interrupt cannot be triggered again until it get deactivated. And according to IHI0069D_gic_architecture_specification, chapter "8.11.3 GICR_ICACTIVER0, Interrupt Clear-Active Register 0", the RW field of GICR_ICACTIVER0 resets to a value that is architecturally UNKNOWN. So set a fixed value during gic-v3 initialization to make sure interrupts are in deactivated state. It is a bit unclear what you mean by "fixed value" here. The only thing you do is clearing active state. So a better wording is "So make sure all interrupts are deactivated at during initialization by clearing the state". How about SPIs? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
Hi Andrii, On 2/1/19 10:35 AM, Andrii Anisov wrote: On 01.02.19 12:16, Julien Grall wrote: The thing is the presence of the printk is not the real problem. It is the problem when the intention is to play in a sandbox with different things. I don't consider polluting your log a real problem. It is just an annoyance that could be fixed by using "ack -v" It only tells you the mapping is inexistent. The problem is if in debug build you don't see at all this message (assuming you have kpti enabled). This would mean you would overwrite a random page. I already have that understanding ;) But curious if XEN 4.12 is going to be released with such the issue remains? I don't consider it as a critical issue because of the type of guest we currently support, so it is not in my queue for Xen 4.12 fixes. Feel free to suggest it as a blocker if you think it is. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
On 2/1/19 10:35 AM, Andrii Anisov wrote: Hello, Hi, On 01.02.19 12:12, Julien Grall wrote: This is actually a shared page, the page is allocated by the domain and shared with Xen. So what do you mean? I'm curious if it can be allocated on hypervisor side. There are very limited case where the hypervisor is allocating memory to share with the guest. In general, we want to account the memory to the guest, so the best way is to let the guest provide the buffer. In that case this will not help because the hypercall is taking a virtual address (not a guest virtual frame, nor guest physical frame!). So the buffer can span across the page-boundary or even have the mapping changed. We can possibly add a restriction on the mapping not changing (pending investigation). But I think requesting the address to be page-aligned is going to be hard because the runstate is not filling a page. For instance, Linux is using a per-cpu variable for that. I am not entirely sure whether it promise the structure will never cross a page-boundary. That's not a link but a Message-ID. You can either use your favorite client for looking the e-mail It only works if you have it in the current mailbox, I guess. That's correct. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] preparations for 4.10.3 and 4.9.4
All, both releases would have been due last week. Please point out backports you find missing from their respective staging branches, but which you consider relevant. Please note that 4.9.4 is expected to be the last xenproject.org managed release from its branch. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] preparations for 4.10.3 and 4.9.4
On 01/02/2019 12:14, Jan Beulich wrote: > All, > > both releases would have been due last week. Please point out > backports you find missing from their respective staging branches, > but which you consider relevant. For 4.10.3: https://lists.xen.org/archives/html/xen-devel/2019-01/msg01451.html Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] preparations for 4.10.3 and 4.9.4
>>> On 01.02.19 at 12:23, wrote: > On 01/02/2019 12:14, Jan Beulich wrote: >> All, >> >> both releases would have been due last week. Please point out >> backports you find missing from their respective staging branches, >> but which you consider relevant. > > For 4.10.3: > > https://lists.xen.org/archives/html/xen-devel/2019-01/msg01451.html Ian, this looks to be one for you. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH V2 2/3] xen/arm: Clarify usage of earlyprintk for Lager board
From: Oleksandr Tyshchenko Current sentence is not entirely correct. Since SCIF0 interface is applicable for Lager board, but is not applicable for all R-Car H2 based boards. For example, Stout board uses SCIFA0 interface. Signed-off-by: Oleksandr Tyshchenko --- docs/misc/arm/early-printk.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt index f765f59..b23c54f 100644 --- a/docs/misc/arm/early-printk.txt +++ b/docs/misc/arm/early-printk.txt @@ -39,7 +39,7 @@ the name of the machine: - fastmodel: printk on ARM Fastmodel software emulators - hikey960: printk with pl011 with Hikey 960 - juno: printk with pl011 on Juno platform - - lager: printk with SCIF0 on Renesas R-Car H2 processors + - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor) - midway: printk with the pl011 on Calxeda Midway processors - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs - omap5432: printk with UART3 on TI OMAP5432 processors -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
On Thu, Jan 31, 2019 at 6:04 PM Heiko Stuebner wrote: > > Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder: > > On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote: > > > > > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder: > > > > Previouly drivers have their own way of mapping range of > > > > kernel pages/memory into user vma and this was done by > > > > invoking vm_insert_page() within a loop. > > > > > > > > As this pattern is common across different drivers, it can > > > > be generalized by creating new functions and use it across > > > > the drivers. > > > > > > > > vm_insert_range() is the API which could be used to mapped > > > > kernel memory/pages in drivers which has considered vm_pgoff > > > > > > > > vm_insert_range_buggy() is the API which could be used to map > > > > range of kernel memory/pages in drivers which has not considered > > > > vm_pgoff. vm_pgoff is passed default as 0 for those drivers. > > > > > > > > We _could_ then at a later "fix" these drivers which are using > > > > vm_insert_range_buggy() to behave according to the normal vm_pgoff > > > > offsetting simply by removing the _buggy suffix on the function > > > > name and if that causes regressions, it gives us an easy way to revert. > > > > > > > > Signed-off-by: Souptick Joarder > > > > Suggested-by: Russell King > > > > Suggested-by: Matthew Wilcox > > > > > > hmm, I'm missing a changelog here between v1 and v2. > > > Nevertheless I managed to test v1 on Rockchip hardware > > > and display is still working, including talking to Lima via prime. > > > > > > So if there aren't any big changes for v2, on Rockchip > > > Tested-by: Heiko Stuebner > > > > Change log is available in [0/9]. > > Patch [1/9] & [4/9] have no changes between v1 -> v2. > > I never seem to get your cover-letters, so didn't see that, sorry. I added you in sender list for all cover-letters but it didn't reach your inbox :-) Thanks for reviewing and validating the patch. > > But great that there weren't changes then :-) > > Heiko > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH V2 1/3] xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
From: Oleksandr Tyshchenko
Extend existing driver to be able to handle SCIFA interface as well.
SCIF and SCIFA have lot in common, though SCIFA has different
offsets and bits for some registers.
The "data" field in struct dt_device_match is used for recognizing
what interface is present on a target board.
Signed-off-by: Oleksandr Tyshchenko
---
Changes in v2:
- Name a enum for describing interfaces this driver supports
- Use local variable for "params" where appropriate
- Use "data" field in struct dt_device_match instead of calling
dt_device_is_compatible()
- Don't check for "overrun_reg != status_reg" condition during
initialization
---
xen/drivers/char/scif-uart.c| 139 ++--
xen/include/asm-arm/scif-uart.h | 44 +++--
2 files changed, 142 insertions(+), 41 deletions(-)
diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 465fb34..9d2b08d 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -1,7 +1,7 @@
/*
* xen/drivers/char/scif-uart.c
*
- * Driver for SCIF (Serial communication interface with FIFO)
+ * Driver for SCIF(A) (Serial communication interface with FIFO (A))
* compatible UART.
*
* Oleksandr Tyshchenko
@@ -40,16 +40,66 @@ static struct scif_uart {
char __iomem *regs;
struct irqaction irqaction;
struct vuart_info vuart;
+const struct port_params *params;
} scif_com = {0};
+enum port_types
+{
+SCIF_PORT,
+SCIFA_PORT,
+NR_PORTS,
+};
+
+struct port_params
+{
+unsigned int status_reg;
+unsigned int tx_fifo_reg;
+unsigned int rx_fifo_reg;
+unsigned int overrun_reg;
+unsigned int overrun_mask;
+unsigned int error_mask;
+unsigned int irq_flags;
+unsigned int fifo_size;
+};
+
+static const struct port_params port_params[NR_PORTS] =
+{
+[SCIF_PORT] =
+{
+.status_reg = SCIF_SCFSR,
+.tx_fifo_reg = SCIF_SCFTDR,
+.rx_fifo_reg = SCIF_SCFRDR,
+.overrun_reg = SCIF_SCLSR,
+.overrun_mask = SCLSR_ORER,
+.error_mask = SCFSR_PER | SCFSR_FER | SCFSR_BRK | SCFSR_ER,
+.irq_flags= SCSCR_RIE | SCSCR_TIE | SCSCR_REIE,
+.fifo_size= 16,
+},
+
+[SCIFA_PORT] =
+{
+.status_reg = SCIFA_SCASSR,
+.tx_fifo_reg = SCIFA_SCAFTDR,
+.rx_fifo_reg = SCIFA_SCAFRDR,
+.overrun_reg = SCIFA_SCASSR,
+.overrun_mask = SCASSR_ORER,
+.error_mask = SCASSR_PER | SCASSR_FER | SCASSR_BRK | SCASSR_ER |
+SCASSR_ORER,
+.irq_flags= SCASCR_RIE | SCASCR_TIE | SCASCR_DRIE | SCASCR_ERIE |
+SCASCR_BRIE,
+.fifo_size= 64,
+},
+};
+
static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs
*regs)
{
struct serial_port *port = data;
struct scif_uart *uart = port->uart;
+const struct port_params *params = uart->params;
uint16_t status, ctrl;
ctrl = scif_readw(uart, SCIF_SCSCR);
-status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+status = scif_readw(uart, params->status_reg) & ~SCFSR_TEND;
/* Ignore next flag if TX Interrupt is disabled */
if ( !(ctrl & SCSCR_TIE) )
status &= ~SCFSR_TDFE;
@@ -65,13 +115,16 @@ static void scif_uart_interrupt(int irq, void *data,
struct cpu_user_regs *regs)
serial_rx_interrupt(port, regs);
/* Error Interrupt */
-if ( status & SCIF_ERRORS )
-scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
-if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
-scif_writew(uart, SCIF_SCLSR, 0);
+if ( status & params->error_mask )
+scif_writew(uart, params->status_reg, ~params->error_mask);
+if ( params->overrun_reg != params->status_reg )
+{
+if ( scif_readw(uart, params->overrun_reg) & params->overrun_mask )
+scif_writew(uart, params->overrun_reg, ~params->overrun_mask);
+}
ctrl = scif_readw(uart, SCIF_SCSCR);
-status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+status = scif_readw(uart, params->status_reg) & ~SCFSR_TEND;
/* Ignore next flag if TX Interrupt is disabled */
if ( !(ctrl & SCSCR_TIE) )
status &= ~SCFSR_TDFE;
@@ -81,12 +134,13 @@ static void scif_uart_interrupt(int irq, void *data,
struct cpu_user_regs *regs)
static void __init scif_uart_init_preirq(struct serial_port *port)
{
struct scif_uart *uart = port->uart;
+const struct port_params *params = uart->params;
/*
* Wait until last bit has been transmitted. This is needed for a smooth
* transition when we come from early printk
*/
-while ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
+while ( !(scif_readw(uart, params->status_reg) & SCFSR_TEND) );
/* Disable TX/RX parts and all interrupts */
scif_writew(uart
[Xen-devel] [PATCH V2 0/3] Renesas Stout board support (R-Car Gen2)
From: Oleksandr Tyshchenko Hi, all. The purpose of this patch series is to add required support to be able to run Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console interface. Actually Xen already has support for SCIF compatible UARTs which are used on Renesas Lager (R-Car Gen2), Salvator-X, H3ULCB/M3ULCB (R-Car Gen3) and other development boards. So this patch series extends existing support to be able to handle both interfaces. -- Current patch series is based on the following commit 3389a8dc8c5753a3c84744923cd0193395e3f2a9 and tested on Stout (ARM32) and H3ULCB (ARM64) boards. You can find current patch series here: repo: https://github.com/otyshchenko1/xen.git branch: stout_upstream You can find previous discussion here: https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21058.html Please note, that current patch series doesn’t have the following patches: - xen/arm: drivers: scif: Remove unused #define-s (already upstreamed) - xen/arm: Reuse R-Car Gen2 platform code for Stout board (was dropped) but has new one: - xen/arm: Clarify usage of earlyprintk for Lager board -- In order to run Xen on Stout board you need "PSCI-enabled" U-Boot (not upsteamed yet). You can find corresponding patches for U-Boot here: http://u-boot.10912.n7.nabble.com/PATCH-0-3-PSCI-support-for-r8a7790-SoC-Lager-Stout-boards-td357352.html Have a plan to update Xen Wiki regarding this board. [1] https://elinux.org/R-Car/Boards/Stout -- Oleksandr Tyshchenko (3): xen/arm: drivers: scif: Add support for SCIFA compatible UARTs xen/arm: Clarify usage of earlyprintk for Lager board xen/arm: Add SCIFA UART support for early printk docs/misc/arm/early-printk.txt | 2 +- xen/arch/arm/arm32/debug-scifa.inc | 51 ++ xen/drivers/char/scif-uart.c | 139 +++-- xen/include/asm-arm/scif-uart.h| 44 ++-- 4 files changed, 194 insertions(+), 42 deletions(-) create mode 100644 xen/arch/arm/arm32/debug-scifa.inc -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH V2 3/3] xen/arm: Add SCIFA UART support for early printk
From: Oleksandr Tyshchenko Add support for Renesas "Stout" development board based on R-Car H2 SoC which has SCIFA compatible UART. Actually existing SCIF UART support (debug-scif.inc) and newly added SCIFA UART support (debug-scifa.inc) differ only in registers offsets. Signed-off-by: Oleksandr Tyshchenko --- Changes in v2: - Move clarification regarding Lager board to separate patch - Drop changes in early-printk.txt and Rules.mk, earlyprink usage for Stout board should be documented on a Xen wiki --- xen/arch/arm/arm32/debug-scifa.inc | 51 ++ 1 file changed, 51 insertions(+) create mode 100644 xen/arch/arm/arm32/debug-scifa.inc diff --git a/xen/arch/arm/arm32/debug-scifa.inc b/xen/arch/arm/arm32/debug-scifa.inc new file mode 100644 index 000..b5e60db --- /dev/null +++ b/xen/arch/arm/arm32/debug-scifa.inc @@ -0,0 +1,51 @@ +/* + * xen/arch/arm/arm32/debug-scifa.inc + * + * SCIFA specific debug code + * + * Oleksandr Tyshchenko + * Copyright (C) 2018 EPAM Systems Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include + +/* + * SCIFA UART wait UART to be ready to transmit + * rb: register which contains the UART base address + * rc: scratch register + */ +.macro early_uart_ready rb rc +1: +ldrh \rc, [\rb, #SCIFA_SCASSR] /* <- SCASSR (status register) */ +tst\rc, #SCASSR_TDFE /* Check TDFE bit */ +beq1b /* Wait for the UART to be ready */ +.endm + +/* + * SCIFA UART transmit character + * rb: register which contains the UART base address + * rt: register which contains the character to transmit + */ +.macro early_uart_transmit rb rt +strb \rt, [\rb, #SCIFA_SCAFTDR] /* -> SCAFTDR (data register) */ +ldrh \rt, [\rb, #SCIFA_SCASSR] /* <- SCASSR (status register) */ +and\rt, \rt, #(~(SCASSR_TEND | SCASSR_TDFE)) /* Clear TEND and TDFE bits */ +strh \rt, [\rb, #SCIFA_SCASSR] /* -> SCASSR (status register) */ +.endm + +/* + * Local variables: + * mode: ASM + * indent-tabs-mode: nil + * End: + */ -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] automation: introduce a QEMU smoke test for PVH Dom0
On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote: > Make qemu-smoke-x86-64.sh take a variant argument. Make two new tests > in test.yaml. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein This is a good improvement to increase our test coverage. Thanks for doing this Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 1/9] xen/evtchn: block speculative out-of-bound accesses
On 1/31/19 16:05, Jan Beulich wrote: On 29.01.19 at 15:43, wrote: >> --- a/xen/common/event_channel.c >> +++ b/xen/common/event_channel.c >> @@ -365,11 +365,16 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, >> evtchn_port_t port) >> if ( (virq < 0) || (virq >= ARRAY_SIZE(v->virq_to_evtchn)) ) >> return -EINVAL; >> >> + /* >> +* Make sure the guest controlled value virq is bounded even during >> +* speculative execution. >> +*/ >> +virq = array_index_nospec(virq, ARRAY_SIZE(v->virq_to_evtchn)); >> + >> if ( virq_is_global(virq) && (vcpu != 0) ) >> return -EINVAL; >> >> -if ( (vcpu < 0) || (vcpu >= d->max_vcpus) || >> - ((v = d->vcpu[vcpu]) == NULL) ) >> +if ( (vcpu < 0) || ((v = domain_vcpu(d, vcpu)) == NULL) ) >> return -ENOENT; > Is there a reason for the less-than-zero check to survive? Yes, domain_vcpu uses unsigned integers, and I want to return the proper error code, in case somebody comes with a vcpu number that would overflow into the valid range. > >> @@ -418,8 +423,7 @@ static long evtchn_bind_ipi(evtchn_bind_ipi_t *bind) >> intport, vcpu = bind->vcpu; >> long rc = 0; >> >> -if ( (vcpu < 0) || (vcpu >= d->max_vcpus) || >> - (d->vcpu[vcpu] == NULL) ) >> +if ( (vcpu < 0) || domain_vcpu(d, vcpu) == NULL ) >> return -ENOENT; > I'm not sure about this one: We're not after the struct vcpu pointer > here. Right now subsequent code looks fine, but what if the actual > "vcpu" local variable was used again in a risky way further down? I > think here and elsewhere it would be best to eliminate that local > variable, and use v->vcpu_id only for subsequent consumers (or > alternatively latch the local variable's value only _after_ the call to > domain_vcpu(), which might be better especially in cases like). I agree with getting rid of using the local variable. As discussed elsewhere, updating such a variable might not fix the problem. However, in this commit I want to avoid speculative out-of-bound accesses using a guest controlled variable (vcpu). Hence, I add protection to the locations where it is used as index. As the domain_vcpu function comes with protection, I prefer this function over explicitly using array_index_nospec, if possible. > >> @@ -969,8 +980,8 @@ long evtchn_bind_vcpu(unsigned int port, unsigned int >> vcpu_id) >> unlink_pirq_port(chn, d->vcpu[chn->notify_vcpu_id]); >> chn->notify_vcpu_id = vcpu_id; >> pirq_set_affinity(d, chn->u.pirq.irq, >> - cpumask_of(d->vcpu[vcpu_id]->processor)); >> -link_pirq_port(port, chn, d->vcpu[vcpu_id]); >> + cpumask_of(domain_vcpu(d, vcpu_id)->processor)); >> +link_pirq_port(port, chn, domain_vcpu(d, vcpu_id)); > ... this one, where you then wouldn't need to alter code other than > that actually checking the vCPU ID. Instead, I will introduce a struct vcpu variable, assign it in the first check of the function, and continue using this variable instead of performing array accesses again in this function. > >> @@ -516,14 +517,22 @@ int evtchn_fifo_init_control(struct >> evtchn_init_control >> *init_control) >> gfn = init_control->control_gfn; >> offset = init_control->offset; >> >> -if ( vcpu_id >= d->max_vcpus || !d->vcpu[vcpu_id] ) >> +if ( !domain_vcpu(d, vcpu_id) ) >> return -ENOENT; >> -v = d->vcpu[vcpu_id]; >> + >> +v = domain_vcpu(d, vcpu_id); > Please don't call the function twice. I will assign the variable as part of the if statement. Best, Norbert > > Jan > > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 01/28] linkage: new macros for assembler symbols
On 31. 01. 19, 17:00, Borislav Petkov wrote: >> Documentation/asm-annotations.rst | 217 ++ > > I guess you wanna integrate that into the doc hierarchy. Hunk ontop: > > --- > diff --git a/Documentation/index.rst b/Documentation/index.rst > index c858c2e66e36..754055d9565c 100644 > --- a/Documentation/index.rst > +++ b/Documentation/index.rst > @@ -91,6 +91,14 @@ needed). > vm/index > bpf/index > > +Architecture-agnostic documentation > +--- > + > +.. toctree:: > + :maxdepth: 2 > + > + asm-annotations > + > Architecture-specific documentation > --- Thanks, all comments applied. I will wait for a couple of days for more feedback, if any, and respin. Perhaps for the last time as these patches are slowly starting bother me after two years of inability to get them upstream (without having NACK or serious objections either) and the constant need of rebasing (spectre/meltdown changes were the ugliest to this series). thanks, -- js suse labs ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 2/9] x86/vioapic: block speculative out-of-bound accesses
On 1/31/19 17:05, Jan Beulich wrote: On 29.01.19 at 15:43, wrote: >> When interacting with io apic, a guest can specify values that are used >> as index to structures, and whose values are not compared against >> upper bounds to prevent speculative out-of-bound accesses. This change >> prevents these speculative accesses. >> >> Furthermore, two variables are initialized and the compiler is asked to >> not optimized these initializations, as the uninitialized, potentially >> guest controlled, variables might be used in a speculative out-of-bound >> access. As the two problematic variables are both used in the common >> function gsi_vioapic, the mitigation is implemented there. Currently, >> the problematic callers are the functions vioapic_irq_positive_edge and >> vioapic_get_trigger_mode. > I would have wished for you to say why the other two are _not_ > a problem. Afaict in both cases the functions only ever get > internal data passed. > > Then again I'm not convinced it's worth taking the risk that a > problematic caller gets added down the road. How about you add > initializers everywhere, clarifying in the description that it's "just > in case" for the two currently safe ones? I will add the other initialization and update the commit message. > >> This commit is part of the SpectreV1+L1TF mitigation patch series. >> >> Signed-off-by: Norbert Manthey >> >> --- > Btw., could you please get used to the habit of adding a brief > summary of changes for at least the most recent version here, > which aids review quite a bit? I will start to do this with the next version. > >> @@ -212,7 +220,15 @@ static void vioapic_write_redirent( >> struct hvm_irq *hvm_irq = hvm_domain_irq(d); >> union vioapic_redir_entry *pent, ent; >> int unmasked = 0; >> -unsigned int gsi = vioapic->base_gsi + idx; >> +unsigned int gsi; >> + >> +/* Callers of this function should make sure idx is bounded >> appropriately*/ > Missing blank at the end of the comment (which, if this was the > only open point, would be easy enough to adjust while committing). Will fix. Best, Norbert > > Jan > > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 3/9] x86/hvm: block speculative out-of-bound accesses
On 1/31/19 17:19, Jan Beulich wrote: On 29.01.19 at 15:43, wrote: >> There are multiple arrays in the HVM interface that are accessed >> with indices that are provided by the guest. To avoid speculative >> out-of-bound accesses, we use the array_index_nospec macro. >> >> When blocking speculative out-of-bound accesses, we can classify arrays >> into dynamic arrays and static arrays. Where the former are allocated >> during run time, the size of the latter is known during compile time. >> On static arrays, compiler might be able to block speculative accesses >> in the future. >> >> We introduce another macro that uses the ARRAY_SIZE macro to block >> speculative accesses. For arrays that are statically accessed, this macro >> can be used instead of the usual macro. Using this macro results in more >> readable code, and allows to modify the way this case is handled in a >> single place. > I think this paragraph is stale now. I will drop the paragraph. > >> @@ -3453,7 +3456,8 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t >> *msr_content) >> if ( (index / 2) >= >> MASK_EXTR(v->arch.hvm.mtrr.mtrr_cap, MTRRcap_VCNT) ) >> goto gp_fault; >> -*msr_content = var_range_base[index]; >> +*msr_content = var_range_base[array_index_nospec(index, >> + MASK_EXTR(v->arch.hvm.mtrr.mtrr_cap, >> MTRRcap_VCNT))]; >> break; > I clearly should have noticed this earlier on - the bound passed into > the macro is not in line with the if() condition. I think you're funneling > half the number of entries into array slot 0. I will fix the bound that's used in the array_index_nospec macro. > >> @@ -4104,6 +4108,12 @@ static int hvmop_set_param( >> if ( a.index >= HVM_NR_PARAMS ) >> return -EINVAL; >> >> +/* >> + * Make sure the guest controlled value a.index is bounded even during >> + * speculative execution. >> + */ >> +a.index = array_index_nospec(a.index, HVM_NR_PARAMS); > I'd like to come back to this model of updating local variables: > Is this really safe to do? If such a variable lives in memory > (which here it quite likely does), does speculation always > recognize the update to the value? Wouldn't it rather read > what's currently in that slot, and re-do the calculation in case > a subsequent write happens? (I know I did suggest doing so > earlier on, so I apologize if this results in you having to go > back to some earlier used model.) I will reply to this on the thread that evolved. Best, Norbert > > Jan > > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 3/9] x86/hvm: block speculative out-of-bound accesses
On 2/1/19 09:23, Jan Beulich wrote:
On 31.01.19 at 21:02, wrote:
>> On 31/01/2019 16:19, Jan Beulich wrote:
@@ -4104,6 +4108,12 @@ static int hvmop_set_param(
if ( a.index >= HVM_NR_PARAMS )
return -EINVAL;
+/*
+ * Make sure the guest controlled value a.index is bounded even during
+ * speculative execution.
+ */
+a.index = array_index_nospec(a.index, HVM_NR_PARAMS);
>>> I'd like to come back to this model of updating local variables:
>>> Is this really safe to do? If such a variable lives in memory
>>> (which here it quite likely does), does speculation always
>>> recognize the update to the value? Wouldn't it rather read
>>> what's currently in that slot, and re-do the calculation in case
>>> a subsequent write happens? (I know I did suggest doing so
>>> earlier on, so I apologize if this results in you having to go
>>> back to some earlier used model.)
>> I'm afraid that is a very complicated set of questions to answer.
>>
>> The processor needs to track write=>read dependencies to avoid wasting a
>> large quantity of time doing erroneous speculation, therefore it does.
>> Pending writes which have happened under speculation are forwarded to
>> dependant instructions.
>>
>> This behaviour is what gives rise to Bounds Check Bypass Store - a half
>> spectre-v1 gadget but with a store rather than a write. You can e.g.
>> speculatively modify the return address on the stack, and hijack
>> speculation to an attacker controlled address for a brief period of
>> time. If the speculation window is long enough, the processor first
>> follows the RSB/RAS (correctly), then later notices that the real value
>> on the stack was different, discards the speculation from the RSB/RAS
>> and uses the attacker controlled value instead, then eventually notices
>> that all of this was bogus and rewinds back to the original branch.
>>
>> Another corner case is Speculative Store Bypass, where memory
>> disambiguation speculation can miss the fact that there is a real
>> write=>read dependency, and cause speculation using the older stale
>> value for a period of time.
>>
>>
>> As to overall safety, array_index_nospec() only works as intended when
>> the index remains in a register between the cmp/sbb which bounds it
>> under speculation, and the array access. There is no way to guarantee
>> this property, as the compiler can spill any value if it thinks it needs to.
>>
>> The general safety of the construct relies on the fact that an
>> optimising compiler will do its very best to avoid spilling variable to
>> the stack.
> "Its very best" may be extremely limited with enough variables.
> Even if we were to annotate them with the "register" keyword,
> that still wouldn't help, as that's only a hint. We simply have no
> way to control which variables the compiler wants to hold in
> registers. I dare to guess that in the particular example above
> it's rather unlikely to be put in a register.
>
> In any event it looks like you support my suspicion that earlier
> comments of mine may have driven things into a less safe
> direction, and we instead need to accept the more heavy
> clutter of scattering around array_{access,index}_nospec()
> at all use sites instead of latching the result of
> array_index_nospec() into whatever shape of local variable.
>
> Which raises another interesting question: Can't CSE and
> alike get in the way here? OPTIMIZER_HIDE_VAR() expands
> to a non-volatile asm() (and as per remarks elsewhere I'm
> unconvinced adding volatile would actually help), so the
> compiler recognizing the same multiple times (perhaps in a
> loop) could make it decide to calculate the thing just once.
> array_index_mask_nospec() in effect is a pure (and actually
> even const) function, and the lack of a respective attribute
> doesn't make the compiler not treat it as such if it recognized
> the fact. (In effect what I had asked Norbert to do to limit
> the clutter was just CSE which the compiler may or may not
> have recognized anyway. IOW I'm not convinced going back
> would actually buy us anything.)
So this means I should stick to the current approach and continue
updating variables after their bound check with an array_index_nospec
call, correct?
Best,
Norbert
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 1/9] xen/evtchn: block speculative out-of-bound accesses
>>> On 01.02.19 at 14:45, wrote: > On 1/31/19 16:05, Jan Beulich wrote: > On 29.01.19 at 15:43, wrote: >>> --- a/xen/common/event_channel.c >>> +++ b/xen/common/event_channel.c >>> @@ -365,11 +365,16 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, >>> evtchn_port_t port) >>> if ( (virq < 0) || (virq >= ARRAY_SIZE(v->virq_to_evtchn)) ) >>> return -EINVAL; >>> >>> + /* >>> +* Make sure the guest controlled value virq is bounded even during >>> +* speculative execution. >>> +*/ >>> +virq = array_index_nospec(virq, ARRAY_SIZE(v->virq_to_evtchn)); >>> + >>> if ( virq_is_global(virq) && (vcpu != 0) ) >>> return -EINVAL; >>> >>> -if ( (vcpu < 0) || (vcpu >= d->max_vcpus) || >>> - ((v = d->vcpu[vcpu]) == NULL) ) >>> +if ( (vcpu < 0) || ((v = domain_vcpu(d, vcpu)) == NULL) ) >>> return -ENOENT; >> Is there a reason for the less-than-zero check to survive? > Yes, domain_vcpu uses unsigned integers, and I want to return the proper > error code, in case somebody comes with a vcpu number that would > overflow into the valid range. I don't see how an overflow into the valid range could occur: Negative numbers, when converted to unsigned, become large positive numbers. If anything in this regard was to change here, then the type of _both_ local variable (which get initialized from a field of type uint32_t). >>> @@ -418,8 +423,7 @@ static long evtchn_bind_ipi(evtchn_bind_ipi_t *bind) >>> intport, vcpu = bind->vcpu; >>> long rc = 0; >>> >>> -if ( (vcpu < 0) || (vcpu >= d->max_vcpus) || >>> - (d->vcpu[vcpu] == NULL) ) >>> +if ( (vcpu < 0) || domain_vcpu(d, vcpu) == NULL ) >>> return -ENOENT; >> I'm not sure about this one: We're not after the struct vcpu pointer >> here. Right now subsequent code looks fine, but what if the actual >> "vcpu" local variable was used again in a risky way further down? I >> think here and elsewhere it would be best to eliminate that local >> variable, and use v->vcpu_id only for subsequent consumers (or >> alternatively latch the local variable's value only _after_ the call to >> domain_vcpu(), which might be better especially in cases like). > > I agree with getting rid of using the local variable. As discussed > elsewhere, updating such a variable might not fix the problem. However, > in this commit I want to avoid speculative out-of-bound accesses using a > guest controlled variable (vcpu). Hence, I add protection to the > locations where it is used as index. As the domain_vcpu function comes > with protection, I prefer this function over explicitly using > array_index_nospec, if possible. But domain_vcpu() does not alter an out of bounds value passed into it in any way, i.e. subsequent array accesses using that value would still be an issue. IOW in the case here what you do is sufficient because there's no array access in the first place. It's debatable whether any change is needed at all here (there would need to be a speculation path which could observe the result of the speculative write into chn->notify_vcpu_id). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 132702: tolerable all pass - PUSHED
flight 132702 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/132702/ 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 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen b58ddf5ed9deca528fadc4befd07b21b98e040a4 baseline version: xen f5d7d370400613a01ca1c9e38d7ce9b1faea32f3 Last test of basis 132668 2019-01-31 11:02:03 Z1 days Testing same since 132702 2019-02-01 12:00:32 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Brian Woods jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f5d7d37040..b58ddf5ed9 b58ddf5ed9deca528fadc4befd07b21b98e040a4 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 3/9] x86/hvm: block speculative out-of-bound accesses
>>> On 01.02.19 at 15:06, wrote:
> On 2/1/19 09:23, Jan Beulich wrote:
> On 31.01.19 at 21:02, wrote:
>>> On 31/01/2019 16:19, Jan Beulich wrote:
> @@ -4104,6 +4108,12 @@ static int hvmop_set_param(
> if ( a.index >= HVM_NR_PARAMS )
> return -EINVAL;
>
> +/*
> + * Make sure the guest controlled value a.index is bounded even
> during
> + * speculative execution.
> + */
> +a.index = array_index_nospec(a.index, HVM_NR_PARAMS);
I'd like to come back to this model of updating local variables:
Is this really safe to do? If such a variable lives in memory
(which here it quite likely does), does speculation always
recognize the update to the value? Wouldn't it rather read
what's currently in that slot, and re-do the calculation in case
a subsequent write happens? (I know I did suggest doing so
earlier on, so I apologize if this results in you having to go
back to some earlier used model.)
>>> I'm afraid that is a very complicated set of questions to answer.
>>>
>>> The processor needs to track write=>read dependencies to avoid wasting a
>>> large quantity of time doing erroneous speculation, therefore it does.
>>> Pending writes which have happened under speculation are forwarded to
>>> dependant instructions.
>>>
>>> This behaviour is what gives rise to Bounds Check Bypass Store - a half
>>> spectre-v1 gadget but with a store rather than a write. You can e.g.
>>> speculatively modify the return address on the stack, and hijack
>>> speculation to an attacker controlled address for a brief period of
>>> time. If the speculation window is long enough, the processor first
>>> follows the RSB/RAS (correctly), then later notices that the real value
>>> on the stack was different, discards the speculation from the RSB/RAS
>>> and uses the attacker controlled value instead, then eventually notices
>>> that all of this was bogus and rewinds back to the original branch.
>>>
>>> Another corner case is Speculative Store Bypass, where memory
>>> disambiguation speculation can miss the fact that there is a real
>>> write=>read dependency, and cause speculation using the older stale
>>> value for a period of time.
>>>
>>>
>>> As to overall safety, array_index_nospec() only works as intended when
>>> the index remains in a register between the cmp/sbb which bounds it
>>> under speculation, and the array access. There is no way to guarantee
>>> this property, as the compiler can spill any value if it thinks it needs to.
>>>
>>> The general safety of the construct relies on the fact that an
>>> optimising compiler will do its very best to avoid spilling variable to
>>> the stack.
>> "Its very best" may be extremely limited with enough variables.
>> Even if we were to annotate them with the "register" keyword,
>> that still wouldn't help, as that's only a hint. We simply have no
>> way to control which variables the compiler wants to hold in
>> registers. I dare to guess that in the particular example above
>> it's rather unlikely to be put in a register.
>>
>> In any event it looks like you support my suspicion that earlier
>> comments of mine may have driven things into a less safe
>> direction, and we instead need to accept the more heavy
>> clutter of scattering around array_{access,index}_nospec()
>> at all use sites instead of latching the result of
>> array_index_nospec() into whatever shape of local variable.
>>
>> Which raises another interesting question: Can't CSE and
>> alike get in the way here? OPTIMIZER_HIDE_VAR() expands
>> to a non-volatile asm() (and as per remarks elsewhere I'm
>> unconvinced adding volatile would actually help), so the
>> compiler recognizing the same multiple times (perhaps in a
>> loop) could make it decide to calculate the thing just once.
>> array_index_mask_nospec() in effect is a pure (and actually
>> even const) function, and the lack of a respective attribute
>> doesn't make the compiler not treat it as such if it recognized
>> the fact. (In effect what I had asked Norbert to do to limit
>> the clutter was just CSE which the compiler may or may not
>> have recognized anyway. IOW I'm not convinced going back
>> would actually buy us anything.)
>
> So this means I should stick to the current approach and continue
> updating variables after their bound check with an array_index_nospec
> call, correct?
Well, yes, at least for now I'm not convinced going back and
re-introduce the heavier code churn would buy us much. But
we'll have to see whether e.g. Andrew is of a different opinion.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
On 01/02/2019 14:52, Tamas K Lengyel wrote:
> On Fri, Feb 1, 2019 at 7:49 AM Andrew Cooper
> wrote:
>> c/s 9338a37d "x86/svm: implement debug events" added support for
>> introspecting
>> ICEBP debug exceptions, but didn't account for the fact that
>> svm_get_insn_len() (previously __get_instruction_length) can fail and may
>> already raise #GP for the guest.
>>
>> If svm_get_insn_len() fails, return back to guest context rather than
>> continuing and mistaking a trap-style VMExit for a fault-style one.
>>
>> Spotted by Coverity.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Wei Liu
>> CC: Roger Pau Monné
>> CC: Boris Ostrovsky
>> CC: Suravee Suthikulpanit
>> CC: Brian Woods
>> CC: Juergen Gross
>> CC: Razvan Cojocaru
>> CC: Tamas K Lengyel
>>
>> This wants backporting to Xen 4.11
>> ---
>> xen/arch/x86/hvm/svm/svm.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> index 2584b90..e21091c 100644
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2758,6 +2758,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>> {
>> trap_type = X86_EVENTTYPE_PRI_SW_EXCEPTION;
>> inst_len = svm_get_insn_len(v, INSTR_ICEBP);
>> +
>> +if ( !instr_len )
> Should that have been inst_len instead of instr_len?
Bah - serves me right not to refresh my patch before sending it. Yes -
this is a typo.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
ICEBP debug exceptions, but didn't account for the fact that
svm_get_insn_len() (previously __get_instruction_length) can fail and may
already raise #GP for the guest.
If svm_get_insn_len() fails, return back to guest context rather than
continuing and mistaking a trap-style VMExit for a fault-style one.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
CC: Juergen Gross
CC: Razvan Cojocaru
CC: Tamas K Lengyel
This wants backporting to Xen 4.11
---
xen/arch/x86/hvm/svm/svm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 2584b90..e21091c 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2758,6 +2758,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
{
trap_type = X86_EVENTTYPE_PRI_SW_EXCEPTION;
inst_len = svm_get_insn_len(v, INSTR_ICEBP);
+
+if ( !instr_len )
+break;
}
rc = hvm_monitor_debug(regs->rip,
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] automation: introduce a QEMU smoke test for PVH Dom0
On Fri, Feb 01, 2019 at 03:59:58PM +0100, Juergen Gross wrote: > On 01/02/2019 14:42, Doug Goldstein wrote: > > On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote: > >> Make qemu-smoke-x86-64.sh take a variant argument. Make two new tests > >> in test.yaml. > >> > >> Signed-off-by: Wei Liu > > > > Acked-by: Doug Goldstein > > > > This is a good improvement to increase our test coverage. Thanks for > > doing this Wei. > > I'm quite hesitant to accept that in the RC-phase of 4.12. Could you do > some test rounds to ensure this test won't be blocking due to > intermittent failures? This isn't a patch to osstest. It is a patch to Gitlab CI, which doesn't block osstest in any way. I also ran an adhoc pipeline to make sure it worked. Wei. > > > Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] automation: introduce a QEMU smoke test for PVH Dom0
On 01/02/2019 16:02, Wei Liu wrote: > On Fri, Feb 01, 2019 at 03:59:58PM +0100, Juergen Gross wrote: >> On 01/02/2019 14:42, Doug Goldstein wrote: >>> On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote: Make qemu-smoke-x86-64.sh take a variant argument. Make two new tests in test.yaml. Signed-off-by: Wei Liu >>> >>> Acked-by: Doug Goldstein >>> >>> This is a good improvement to increase our test coverage. Thanks for >>> doing this Wei. >> >> I'm quite hesitant to accept that in the RC-phase of 4.12. Could you do >> some test rounds to ensure this test won't be blocking due to >> intermittent failures? > > This isn't a patch to osstest. It is a patch to Gitlab CI, which doesn't > block osstest in any way. > > I also ran an adhoc pipeline to make sure it worked. Ah, okay. Then you can have my: Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
On 01/02/2019 15:49, Andrew Cooper wrote: > c/s 9338a37d "x86/svm: implement debug events" added support for introspecting > ICEBP debug exceptions, but didn't account for the fact that > svm_get_insn_len() (previously __get_instruction_length) can fail and may > already raise #GP for the guest. > > If svm_get_insn_len() fails, return back to guest context rather than > continuing and mistaking a trap-style VMExit for a fault-style one. > > Spotted by Coverity. > > Signed-off-by: Andrew Cooper Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] automation: introduce a QEMU smoke test for PVH Dom0
On Fri, Feb 01, 2019 at 04:06:13PM +0100, Juergen Gross wrote: > On 01/02/2019 16:02, Wei Liu wrote: > > On Fri, Feb 01, 2019 at 03:59:58PM +0100, Juergen Gross wrote: > >> On 01/02/2019 14:42, Doug Goldstein wrote: > >>> On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote: > Make qemu-smoke-x86-64.sh take a variant argument. Make two new tests > in test.yaml. > > Signed-off-by: Wei Liu > >>> > >>> Acked-by: Doug Goldstein > >>> > >>> This is a good improvement to increase our test coverage. Thanks for > >>> doing this Wei. > >> > >> I'm quite hesitant to accept that in the RC-phase of 4.12. Could you do > >> some test rounds to ensure this test won't be blocking due to > >> intermittent failures? > > > > This isn't a patch to osstest. It is a patch to Gitlab CI, which doesn't > > block osstest in any way. > > > > I also ran an adhoc pipeline to make sure it worked. > > Ah, okay. Then you can have my: > > Release-acked-by: Juergen Gross Thank you. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
On 2/1/19 4:49 PM, Andrew Cooper wrote:
c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
ICEBP debug exceptions, but didn't account for the fact that
svm_get_insn_len() (previously __get_instruction_length) can fail and may
already raise #GP for the guest.
If svm_get_insn_len() fails, return back to guest context rather than
continuing and mistaking a trap-style VMExit for a fault-style one.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
CC: Juergen Gross
CC: Razvan Cojocaru
CC: Tamas K Lengyel
This wants backporting to Xen 4.11
---
xen/arch/x86/hvm/svm/svm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 2584b90..e21091c 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2758,6 +2758,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
{
trap_type = X86_EVENTTYPE_PRI_SW_EXCEPTION;
inst_len = svm_get_insn_len(v, INSTR_ICEBP);
+
+if ( !instr_len )
+break;
}
rc = hvm_monitor_debug(regs->rip,
Reviewed-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] automation: introduce a QEMU smoke test for PVH Dom0
On 01/02/2019 14:42, Doug Goldstein wrote: > On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote: >> Make qemu-smoke-x86-64.sh take a variant argument. Make two new tests >> in test.yaml. >> >> Signed-off-by: Wei Liu > > Acked-by: Doug Goldstein > > This is a good improvement to increase our test coverage. Thanks for > doing this Wei. I'm quite hesitant to accept that in the RC-phase of 4.12. Could you do some test rounds to ensure this test won't be blocking due to intermittent failures? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
On Fri, Feb 1, 2019 at 7:49 AM Andrew Cooper wrote:
>
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for the guest.
>
> If svm_get_insn_len() fails, return back to guest context rather than
> continuing and mistaking a trap-style VMExit for a fault-style one.
>
> Spotted by Coverity.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
> CC: Juergen Gross
> CC: Razvan Cojocaru
> CC: Tamas K Lengyel
>
> This wants backporting to Xen 4.11
> ---
> xen/arch/x86/hvm/svm/svm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 2584b90..e21091c 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2758,6 +2758,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
> {
> trap_type = X86_EVENTTYPE_PRI_SW_EXCEPTION;
> inst_len = svm_get_insn_len(v, INSTR_ICEBP);
> +
> +if ( !instr_len )
Should that have been inst_len instead of instr_len?
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.12] xen/iommu: fix iommu_ops attribute
Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
IOMMU hook accesses") declared the AMD and INTEL variants of struct
iommu_ops as __initconstrel, but those are needed for system resume,
too.
Fix that by modifying them to be not located in the init data segment.
Signed-off-by: Juergen Gross
---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
xen/drivers/passthrough/vtd/iommu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 33a3798f36..99d9755152 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -570,7 +570,7 @@ static void amd_dump_p2m_table(struct domain *d)
amd_dump_p2m_table_level(hd->arch.root_table, hd->arch.paging_mode, 0, 0);
}
-static const struct iommu_ops __initconstrel amd_iommu_ops = {
+static const struct iommu_ops amd_iommu_ops = {
.init = amd_iommu_domain_init,
.hwdom_init = amd_iommu_hwdom_init,
.add_device = amd_iommu_add_device,
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 50a0e25224..e8fd0e5e27 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2706,7 +2706,7 @@ static void vtd_dump_p2m_table(struct domain *d)
vtd_dump_p2m_table_level(hd->arch.pgd_maddr, agaw_to_level(hd->arch.agaw),
0, 0);
}
-const struct iommu_ops __initconstrel intel_iommu_ops = {
+const struct iommu_ops intel_iommu_ops = {
.init = intel_iommu_domain_init,
.hwdom_init = intel_iommu_hwdom_init,
.add_device = intel_iommu_add_device,
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] xen/iommu: fix iommu_ops attribute
On 01/02/2019 15:13, Juergen Gross wrote:
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
> IOMMU hook accesses") declared the AMD and INTEL variants of struct
> iommu_ops as __initconstrel, but those are needed for system resume,
> too.
>
> Fix that by modifying them to be not located in the init data segment.
>
> Signed-off-by: Juergen Gross
Huh... That suggests we are re-initialising the IOMMU subsystem from a
scan, rather than from the details we found at boot.
Did you work out which path hit this during resume?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC for-4.12] x86: put CONFIG_{HVM, PV} under EXPERT
Enabling and disabling one of the two isn't tested in OSSTest yet. Signed-off-by: Wei Liu --- We need to sort this out for 4.12 release. On the one hand, exposing them seems risky. On the other hand, if there are bugs which cause xen to wander into a path which hits BUG or ASSERT, they are problems with older releases as well. And we definitely want to make each of the two security supported in the long run. --- xen/arch/x86/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 5c2d1070b6..3e020dc629 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -37,7 +37,8 @@ source "arch/Kconfig" config PV def_bool y - prompt "PV support" + prompt "PV support" if EXPERT = "y" + default y ---help--- Interfaces to support PV domains. These require guest kernel support to run as a PV guest, but don't require any specific hardware support. @@ -68,7 +69,7 @@ config PV_LINEAR_PT config HVM def_bool !PV_SHIM_EXCLUSIVE - prompt "HVM support" + prompt "HVM support" if EXPERT = "y" ---help--- Interfaces to support HVM domains. HVM domains require hardware virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boot -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] xen/iommu: fix iommu_ops attribute
>>> On 01.02.19 at 16:13, wrote:
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -570,7 +570,7 @@ static void amd_dump_p2m_table(struct domain *d)
> amd_dump_p2m_table_level(hd->arch.root_table, hd->arch.paging_mode, 0,
> 0);
> }
>
> -static const struct iommu_ops __initconstrel amd_iommu_ops = {
> +static const struct iommu_ops amd_iommu_ops = {
This one's not needed - there's only an __init function referencing
this structure.
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2706,7 +2706,7 @@ static void vtd_dump_p2m_table(struct domain *d)
> vtd_dump_p2m_table_level(hd->arch.pgd_maddr,
> agaw_to_level(hd->arch.agaw), 0, 0);
> }
>
> -const struct iommu_ops __initconstrel intel_iommu_ops = {
> +const struct iommu_ops intel_iommu_ops = {
This one's indeed referenced by a non-__init function, but the
fix is imo to avoid that reference from iommu_enable_x2apic_IR():
We should not overwrite the previously established (and
potentially subsequently adjusted) hook pointers. So I think
the assignment wants to go in a system_state dependent
conditional (and there is one a few lines up, so it could move
just there).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
>>> On 01.02.19 at 15:49, wrote: > c/s 9338a37d "x86/svm: implement debug events" added support for introspecting > ICEBP debug exceptions, but didn't account for the fact that > svm_get_insn_len() (previously __get_instruction_length) can fail and may > already raise #GP for the guest. > > If svm_get_insn_len() fails, return back to guest context rather than > continuing and mistaking a trap-style VMExit for a fault-style one. My reading of the last part of this sentence is that the exit in question is a trap-style one. Is my English failing me here? Because if so, why would there be any call to svm_get_insn_len() in the first place? For a trap-style exit guest RIP should already point past the insn, and hence the debug mode checking ought to never succeed (unless there's a second ICEBP following the first one immediately). If, otoh, it really is a fault-style exit (which was my understanding so far), how is exiting back to guest context going to do any good, if svm_get_insn_len() did _not_ raise #GP(0)? We'd just see the same exit right away. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC for-4.12] x86: put CONFIG_{HVM, PV} under EXPERT
>>> On 01.02.19 at 16:43, wrote: > Enabling and disabling one of the two isn't tested in OSSTest yet. While I'm not opposed to the addition, I intentionally didn't ask for doing so when the options got introduced, not the least because of ... > @@ -68,7 +69,7 @@ config PV_LINEAR_PT > > config HVM > def_bool !PV_SHIM_EXCLUSIVE ... this, i.e. us already wanting a supported configuration to be built and run in that mode. IOW personally I think no change is needed, and disabling either (but not both) ought to be security supported right away. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC for-4.12] x86: put CONFIG_{HVM, PV} under EXPERT
On Fri, Feb 01, 2019 at 09:01:57AM -0700, Jan Beulich wrote: > >>> On 01.02.19 at 16:43, wrote: > > Enabling and disabling one of the two isn't tested in OSSTest yet. > > While I'm not opposed to the addition, I intentionally didn't ask > for doing so when the options got introduced, not the least > because of ... > > > @@ -68,7 +69,7 @@ config PV_LINEAR_PT > > > > config HVM > > def_bool !PV_SHIM_EXCLUSIVE > > ... this, i.e. us already wanting a supported configuration to > be built and run in that mode. IOW personally I think no > change is needed, and disabling either (but not both) ought > to be security supported right away. This is fine. Andrew also said more or less the same thing on IRC. I just want to be sure this gets properly discussed. This patch can be dropped now. Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] xen/iommu: fix iommu_ops attribute
On 01/02/2019 16:44, Jan Beulich wrote:
On 01.02.19 at 16:13, wrote:
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -570,7 +570,7 @@ static void amd_dump_p2m_table(struct domain *d)
>> amd_dump_p2m_table_level(hd->arch.root_table, hd->arch.paging_mode, 0,
>> 0);
>> }
>>
>> -static const struct iommu_ops __initconstrel amd_iommu_ops = {
>> +static const struct iommu_ops amd_iommu_ops = {
>
> This one's not needed - there's only an __init function referencing
> this structure.
>
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -2706,7 +2706,7 @@ static void vtd_dump_p2m_table(struct domain *d)
>> vtd_dump_p2m_table_level(hd->arch.pgd_maddr,
>> agaw_to_level(hd->arch.agaw), 0, 0);
>> }
>>
>> -const struct iommu_ops __initconstrel intel_iommu_ops = {
>> +const struct iommu_ops intel_iommu_ops = {
>
> This one's indeed referenced by a non-__init function, but the
> fix is imo to avoid that reference from iommu_enable_x2apic_IR():
> We should not overwrite the previously established (and
> potentially subsequently adjusted) hook pointers. So I think
> the assignment wants to go in a system_state dependent
> conditional (and there is one a few lines up, so it could move
> just there).
Okay, I'll try that.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
On 01/02/2019 15:58, Jan Beulich wrote: On 01.02.19 at 15:49, wrote: >> c/s 9338a37d "x86/svm: implement debug events" added support for >> introspecting >> ICEBP debug exceptions, but didn't account for the fact that >> svm_get_insn_len() (previously __get_instruction_length) can fail and may >> already raise #GP for the guest. >> >> If svm_get_insn_len() fails, return back to guest context rather than >> continuing and mistaking a trap-style VMExit for a fault-style one. > My reading of the last part of this sentence is that the exit in > question is a trap-style one. Is my English failing me here? Your reading of my sentence is correct, but I was confused when writing it. ICEBP is a fault-style intercept. However, when svm_get_insn_len() fails, it will inject #GP and return 0. This then gets passed into hvm_monitor_debug() or the #DB re-injected as-was. If it were just getting insn_len incorrectly as 0, then the guest would livelock as we wouldn't inject the #DB with trap semantics it requires, but as the #GP is already raised, this will combine to #DF. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC for-4.12] x86: put CONFIG_{HVM, PV} under EXPERT
On 01/02/2019 16:04, Wei Liu wrote: > On Fri, Feb 01, 2019 at 09:01:57AM -0700, Jan Beulich wrote: > On 01.02.19 at 16:43, wrote: >>> Enabling and disabling one of the two isn't tested in OSSTest yet. >> While I'm not opposed to the addition, I intentionally didn't ask >> for doing so when the options got introduced, not the least >> because of ... >> >>> @@ -68,7 +69,7 @@ config PV_LINEAR_PT >>> >>> config HVM >>> def_bool !PV_SHIM_EXCLUSIVE >> ... this, i.e. us already wanting a supported configuration to >> be built and run in that mode. IOW personally I think no >> change is needed, and disabling either (but not both) ought >> to be security supported right away. > This is fine. Andrew also said more or less the same thing on IRC. > > I just want to be sure this gets properly discussed. I think the risk of there being an XSA hidden in here which is only applicable to Xen 4.12+ is very slim. I expect that any breakage from this would be around domaincreate and therefore a control-plain operation. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.12 v2] xen/iommu: fix iommu_ops initialization
Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
IOMMU hook accesses") introduced iommu_ops initialized at boot time
with data declared as __initconstrel.
On Intel systems there is another path where iommu_ops is initialized
and this path is relevant on resume after returning from system suspend.
As the initialization data is no longer accessible in this case that
second initialization must be dropped in case the system isn't just
booting.
Signed-off-by: Juergen Gross
---
xen/drivers/passthrough/vtd/intremap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/intremap.c
b/xen/drivers/passthrough/vtd/intremap.c
index a0663ecd22..838268d772 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -893,12 +893,12 @@ int iommu_enable_x2apic_IR(void)
if ( !platform_supports_x2apic() )
return -ENXIO;
+
+iommu_ops = intel_iommu_ops;
}
else if ( !x2apic_enabled )
return -EOPNOTSUPP;
-iommu_ops = intel_iommu_ops;
-
for_each_drhd_unit ( drhd )
{
iommu = drhd->iommu;
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12 v2] xen/iommu: fix iommu_ops initialization
On 01/02/2019 17:29, Juergen Gross wrote:
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
> IOMMU hook accesses") introduced iommu_ops initialized at boot time
> with data declared as __initconstrel.
>
> On Intel systems there is another path where iommu_ops is initialized
> and this path is relevant on resume after returning from system suspend.
> As the initialization data is no longer accessible in this case that
> second initialization must be dropped in case the system isn't just
> booting.
>
> Signed-off-by: Juergen Gross
And of course:
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12 v2] xen/iommu: fix iommu_ops initialization
>>> On 01.02.19 at 17:29, wrote:
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
> IOMMU hook accesses") introduced iommu_ops initialized at boot time
> with data declared as __initconstrel.
>
> On Intel systems there is another path where iommu_ops is initialized
> and this path is relevant on resume after returning from system suspend.
> As the initialization data is no longer accessible in this case that
> second initialization must be dropped in case the system isn't just
> booting.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 132708: tolerable all pass - PUSHED
flight 132708 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/132708/ 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 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen ae29aa0f8fdfbd41d5ea71a1338fc6330562cff3 baseline version: xen b58ddf5ed9deca528fadc4befd07b21b98e040a4 Last test of basis 132702 2019-02-01 12:00:32 Z0 days Testing same since 132708 2019-02-01 15:00:36 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Ian Jackson jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git b58ddf5ed9..ae29aa0f8f ae29aa0f8fdfbd41d5ea71a1338fc6330562cff3 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
> Hi Stefano,
>
> On 1/31/19 9:56 PM, Stefano Stabellini wrote:
> > On Thu, 31 Jan 2019, Julien Grall wrote:
> > > On 31/01/2019 12:00, Andrii Anisov wrote:
> > > > Hello Julien,
> > > >
> > > > On 31.01.19 13:37, Julien Grall wrote:
> > > > > > On my side I just commented out that printk, because it renders a
> > > > > > debug
> > > > > > build unusable.
> > > > >
> > > > > ... if it is unusable, why don't you try to tackle the problem?
> > > > Because of...
> > > >
> > > > > This is in my long ever growing list of things to
> > > >
> > > > ... be done.
> > > >
> > > > Some of things get solutions, some WAs.
> > >
> > > I can't see a good workaround for this. At some point someone would have
> > > to
> > > pick it up rather than building a house of cards.
> >
> > I ran into this problem as well not too long ago too. It is very
> > annoying and it is basically impossible to work-around, the only thing
> > possible would be to suppress the warning, but that doesn't even count
> > as a work-around :-)
>
> I am sure I will regret to have said that, but I will for fairness :).
>
> If security is not a concern within the guest, then you can disable kpti
> (either via Kconfig or command line). All the errors should go away for
> Linux guest.
>
> >
> > The way forward is to modify the existing
> > VCPUOP_register_runstate_memory_area interface. I liked Julien's idea in
> > https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg00227.html:
> > we don't necessarily need to change the parameters of the hypercalls
> > from a guest virtual address to a guest physical address. It should be
> > enough to convert the guest virtual address into a guest physical
> > address in Xen when VCPUOP_register_runstate_memory_area is called
> > (xen/common/domain.c:VCPUOP_register_runstate_memory_area), then store
> > the guest physical address or its mapping in v->runstate_guest (the type
> > of runstate_guest needs to change) and always use the guest physical
> > address for future updates on the runstate memory area.
>
> I would love to say it is that easy :). However, there are some research to
> do regarding how this is used by guests today. The hypercall is taking a
> virtual address, so technically it would be possible for a guest to pass a
> non page-aligned virtual address. So this would span onto two buffers (it
> seems to happen on older Linux).
>
> Furthermore, because this is a virtual address, a guess would be free to
> modify the mapping at any time.
>
> So if we want to use guest physical address in Xen, we need to know if it
> will not break any current guest. This would also probably needs to be
> documented in the interface.
>
> With the current interface workaround, we are still playing with devil (see
> [2]). So it would be nice to get a new interface that does not use virtual
> address.
So, I've got a hacky patch to 'fix' this on x86, by taking a reference
to the mfn behind the virtual address provided when setting up the
hypercall and mapping it in Xen. This however doesn't work on ARM due
to the lack of paging_gva_to_gfn. I guess there's something similar to
translate a guest virtual address into a gfn or a mfn?
I've only tested this very slightly, so there might be dragons...
Anyway, this is what I have so far:
---8<---
commit 9b88c4aba641abd188144c4bad1d69345625678f
Author: Roger Pau Monne
Date: Fri Feb 1 12:13:47 2019 +0100
keep runstate area mapped
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 6dc633ed50..cfd60ed7a7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -277,29 +277,23 @@ static void ctxt_switch_to(struct vcpu *n)
/* Update per-VCPU guest runstate shared memory area (if registered). */
static void update_runstate_area(struct vcpu *v)
{
-void __user *guest_handle = NULL;
-
-if ( guest_handle_is_null(runstate_guest(v)) )
+if ( !v->runstate_guest(v) )
return;
if ( VM_ASSIST(v->domain, runstate_update_flag) )
{
-guest_handle = &v->runstate_guest.p->state_entry_time + 1;
-guest_handle--;
v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
-__raw_copy_to_guest(guest_handle,
-(void *)(&v->runstate.state_entry_time + 1) - 1,
1);
+v->runstate_guest->state_entry_time |= XEN_RUNSTATE_UPDATE;
smp_wmb();
}
-__copy_to_guest(runstate_guest(v), &v->runstate, 1);
+memcpy(v->runstate_guest, &v->runstate, sizeof(v->runstate));
-if ( guest_handle )
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
{
v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
smp_wmb();
-__raw_copy_to_guest(guest_handle,
-(void *)(&v->runstate.state_entry_time + 1) - 1,
1);
+v->runstate_guest->state_entry_time &= ~XEN_RUNSTATE_UPDATE;
}
}
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86
Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
>>> On 01.02.19 at 17:25, wrote: > On 01/02/2019 15:58, Jan Beulich wrote: > On 01.02.19 at 15:49, wrote: >>> c/s 9338a37d "x86/svm: implement debug events" added support for >>> introspecting >>> ICEBP debug exceptions, but didn't account for the fact that >>> svm_get_insn_len() (previously __get_instruction_length) can fail and may >>> already raise #GP for the guest. >>> >>> If svm_get_insn_len() fails, return back to guest context rather than >>> continuing and mistaking a trap-style VMExit for a fault-style one. >> My reading of the last part of this sentence is that the exit in >> question is a trap-style one. Is my English failing me here? > > Your reading of my sentence is correct, but I was confused when writing it. > > ICEBP is a fault-style intercept. > > However, when svm_get_insn_len() fails, it will inject #GP and return s/will/may/ afaict > 0. This then gets passed into hvm_monitor_debug() or the #DB > re-injected as-was. > > If it were just getting insn_len incorrectly as 0, then the guest would > livelock as we wouldn't inject the #DB with trap semantics it requires, I'm confused again: Why trap semantics? The ICEBP has fault semantics as you confirmed above. > but as the #GP is already raised, this will combine to #DF. How that? #DB is a benign exception, so according to the table on the #DF page in the SDM, with #GP it shouldn't combine to #DF. Also, if live-locking the guest is a concern, then (as said before) how can simply re-entering the guest be the right solution? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts
On 01/02/2019 16:55, Jan Beulich wrote: On 01.02.19 at 17:25, wrote: >> On 01/02/2019 15:58, Jan Beulich wrote: >> On 01.02.19 at 15:49, wrote: c/s 9338a37d "x86/svm: implement debug events" added support for introspecting ICEBP debug exceptions, but didn't account for the fact that svm_get_insn_len() (previously __get_instruction_length) can fail and may already raise #GP for the guest. If svm_get_insn_len() fails, return back to guest context rather than continuing and mistaking a trap-style VMExit for a fault-style one. >>> My reading of the last part of this sentence is that the exit in >>> question is a trap-style one. Is my English failing me here? >> Your reading of my sentence is correct, but I was confused when writing it. >> >> ICEBP is a fault-style intercept. >> >> However, when svm_get_insn_len() fails, it will inject #GP and return > s/will/may/ afaict Oh true - this is also problematic for all other cases. I'll need to fix that up as well, > >> 0. This then gets passed into hvm_monitor_debug() or the #DB >> re-injected as-was. >> >> If it were just getting insn_len incorrectly as 0, then the guest would >> livelock as we wouldn't inject the #DB with trap semantics it requires, > I'm confused again: Why trap semantics? The ICEBP has fault > semantics as you confirmed above. The ICEBP intercept has fault semantics. An ICEBP instruction executing in the guest has trap semantics. Xen has to make up the difference as part of re-injecting the #DB (which is extra complicated due to AMD's even injection not handing X86_EVENTTYPE_PRI_SW_EXCEPTION in a sensible way). > >> but as the #GP is already raised, this will combine to #DF. > How that? #DB is a benign exception, so according to the table on the > #DF page in the SDM, with #GP it shouldn't combine to #DF. #GP is raised first. It is contributory. A subsequent #DB getting raised causes #GP to turn into #DF. > Also, if live-locking the guest is a concern, then (as said before) how > can simply re-entering the guest be the right solution? It isn't, given your observation that there is a path out of svm_get_insn_len() which return 0 and don't raise #GP, but that is an orthogonal bug to fix. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
On Thu, Jan 31, 2019 at 6:31 PM Christopher Lameter wrote: > > On Thu, 31 Jan 2019, Thomas Garnier wrote: > > > The per-cpu symbols are in a section that is zero based to create > > offsets. The compiler doesn't see them as offsets but as relative > > symbol and try to relocate them. Given the distance between zero and > > the mapped kernel is much larger than the instruction offset range, it > > fails to do it. > > We switch that off in the linker. If that does not work with your > modifications then you need to figure out how to update the link > configuration. > It didn't work originally but I will revisit to see if I missed something. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
Hi,
On 01/02/2019 16:53, Roger Pau Monné wrote:
On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
On 1/31/19 9:56 PM, Stefano Stabellini wrote:
On Thu, 31 Jan 2019, Julien Grall wrote:
On 31/01/2019 12:00, Andrii Anisov wrote:
On 31.01.19 13:37, Julien Grall wrote:
So, I've got a hacky patch to 'fix' this on x86, by taking a reference
to the mfn behind the virtual address provided when setting up the
hypercall and mapping it in Xen.
That was the idea I had in mind :). Hopefully, no guest is modifying the mapping
(i.e the virtual address point to a different physical address) afterwards.
This however doesn't work on ARM due
to the lack of paging_gva_to_gfn. I guess there's something similar to
translate a guest virtual address into a gfn or a mfn?
get_page_from_gva should to the job for you.
+int map_runstate_area(struct vcpu *v,
+ struct vcpu_register_runstate_memory_area *area)
+{
+unsigned long offset;
+unsigned int i;
+struct domain *d = v->domain;
+size_t size =
+#ifdef CONFIG_COMPAT
+has_32bit_shinfo((v)->domain) ? sizeof(*v->compat_runstate_guest) :
+#endif
+sizeof(*v->runstate_guest);
+
+if ( v->runstate_guest )
+{
+ASSERT_UNREACHABLE();
+return -EBUSY;
+}
+
+offset = area->addr.p & ~PAGE_MASK;
+
+for ( i = 0; i < ARRAY_SIZE(v->runstate_mfn); i++ )
+{
+p2m_type_t t;
+uint32_t pfec = PFEC_page_present;
+gfn_t gfn = _gfn(paging_gva_to_gfn(v, area->addr.p, &pfec));
+struct page_info *pg;
+
+if ( gfn_eq(gfn, INVALID_GFN) )
+return -EFAULT;
+
+v->runstate_mfn[i] = get_gfn(d, gfn_x(gfn), &t);
get_gfn would need to be implemented on Arm.
+if ( t != p2m_ram_rw || mfn_eq(v->runstate_mfn[i], INVALID_MFN) )
+return -EFAULT;
+
+pg = mfn_to_page(v->runstate_mfn[i]);
+if ( !pg || !get_page_type(pg, PGT_writable_page) )
+{
+put_gfn(d, gfn_x(gfn));
+return -EFAULT;
+}
+
+put_gfn(d, gfn_x(gfn));
+
+if ( PFN_DOWN(gfn_x(gfn) + size) == PFN_DOWN(gfn_x(gfn)) )
This looks wrong, you seem to mix address and frame. I think you might want:
if ( gfn_eq(gfn_add(gfn, PFN_DOWN(size)), gfn) )
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
+Juergen On Fri, 1 Feb 2019, Julien Grall wrote: > Hi Andrii, > > On 2/1/19 10:35 AM, Andrii Anisov wrote: > > > > > > On 01.02.19 12:16, Julien Grall wrote: > > > The thing is the presence of the printk is not the real problem. > > It is the problem when the intention is to play in a sandbox with different > > things. > > I don't consider polluting your log a real problem. It is just an annoyance > that could be fixed by using "ack -v" > > > > > > It only tells you the mapping is inexistent. The problem is if in debug > > > build you don't see at all this message (assuming you have kpti enabled). > > > This would mean you would overwrite a random page. > > I already have that understanding ;) But curious if XEN 4.12 is going to be > > released with such the issue remains? > > I don't consider it as a critical issue because of the type of guest we > currently support, so it is not in my queue for Xen 4.12 fixes. > > Feel free to suggest it as a blocker if you think it is. > > Cheers, > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 132710: regressions - FAIL
flight 132710 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/132710/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR. vs. 132708 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 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 755eb6403ec722db37f1b8f8b51e0b0ab661c003 baseline version: xen ae29aa0f8fdfbd41d5ea71a1338fc6330562cff3 Last test of basis 132708 2019-02-01 15:00:36 Z0 days Testing same since 132710 2019-02-01 17:00:42 Z0 days1 attempts People who touched revisions under test: Doug Goldstein Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 fail test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 755eb6403ec722db37f1b8f8b51e0b0ab661c003 Author: Wei Liu Date: Thu Jan 24 14:03:48 2019 + automation: introduce a QEMU smoke test for PVH Dom0 Make qemu-smoke-x86-64.sh take a variant argument. Make two new tests in test.yaml. Signed-off-by: Wei Liu Acked-by: Doug Goldstein Release-acked-by: Juergen Gross (qemu changes not included) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/xen: dont add memory above max allowed allocation
On 1/30/19 3:22 AM, Juergen Gross wrote:
> Don't allow memory to be added above the allowed maximum allocation
> limit set by Xen.
>
> Trying to do so would result in cases like the following:
>
> [ 584.559652] [ cut here ]
> [ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129
> xen_alloc_pte+0x1c7/0x390()
> [ 584.575151] Modules linked in:
> [ 584.578643] Supported: Yes
> [ 584.581750] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
> 4.4.120-92.70-default #1
> [ 584.59] Hardware name: Cisco Systems Inc UCSC-C460-M4/UCSC-C460-M4,
> BIOS C460M4.4.0.1b.0.0629181419 06/29/2018
> [ 584.601862] 813175a0
> 8184777c
> [ 584.610200] 8107f4e1 880487eb7000 8801862b79c0
> 88048608d290
> [ 584.618537] 00487eb7 ea000201 81009de7
> 81068561
> [ 584.626876] Call Trace:
> [ 584.629699] [] dump_trace+0x59/0x340
> [ 584.635645] [] show_stack_log_lvl+0xea/0x170
> [ 584.642391] [] show_stack+0x21/0x40
> [ 584.648238] [] dump_stack+0x5c/0x7c
> [ 584.654085] [] warn_slowpath_common+0x81/0xb0
> [ 584.660932] [] xen_alloc_pte+0x1c7/0x390
> [ 584.667289] [] pmd_populate_kernel.constprop.6+0x40/0x80
> [ 584.675241] [] phys_pmd_init+0x210/0x255
> [ 584.681587] [] phys_pud_init+0x1da/0x247
> [ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4
> [ 584.695682] [] init_memory_mapping+0x18d/0x380
> [ 584.702631] [] arch_add_memory+0x59/0xf0
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/xen/setup.c | 10 ++
> drivers/xen/xen-balloon.c | 6 ++
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index d5f303c0e656..fdb184cadaf5 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -825,6 +826,15 @@ char * __init xen_memory_setup(void)
> xen_max_p2m_pfn = pfn_s + n_pfns;
> } else
> discard = true;
> +#ifdef CONFIG_MEMORY_HOTPLUG
> + /*
> + * Don't allow adding memory not in E820 map while
> + * booting the system. Once the balloon driver is up
> + * it will remove that restriction again.
> + */
> + max_mem_size = xen_e820_table.entries[i].addr +
> +xen_e820_table.entries[i].size;
> +#endif
> }
>
> if (!discard)
> diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
> index 2acbfe104e46..2a960fcc812e 100644
> --- a/drivers/xen/xen-balloon.c
> +++ b/drivers/xen/xen-balloon.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -63,6 +64,11 @@ static void watch_target(struct xenbus_watch *watch,
> static bool watch_fired;
> static long target_diff;
>
> +#ifdef CONFIG_MEMORY_HOTPLUG
> + /* The balloon driver will take care of adding memory now. */
> + max_mem_size = U64_MAX;
> +#endif
I don't think I understand this. Are you saying the guest should ignore
'mem' boot option?
-boris
> +
> err = xenbus_scanf(XBT_NIL, "memory", "target", "%llu", &new_target);
> if (err != 1) {
> /* This is ok (for domain0 at least) - so just return */
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL
On Tue, Jan 22, 2019 at 9:17 AM Jan Beulich wrote: > > >>> On 22.01.19 at 00:41, wrote: > > We haven't managed to reach consensus on this topic. Your view might be > > correct, but it is not necessarily supported by compilers' behavior, > > which depends on the opinion of compilers engineers on the topic, and > > MISRAC compliance, which depends on the opinion of MISRAC specialists on > > the topic. If we take your suggested approach we end up with the code > > most likely to break in case the compilers engineers or the MISRAC > > experts disagree with you. In this case, being right doesn't necessarily > > lead to the code less likely to break. > > > > Regardless, if that is the decision of the Xen community as a whole, > > I'll follow it. My preference remains with approach 3. (var.S), followed > > by approach 2. (SYMBOL_HIDE returns uintptr_t), but I am willing to > > refresh my series to do approach 1. (SYMBOL_HIDE returns pointer type) > > if that is the only way forward. > > > > Let us come to a conclusion so that we can move on. > > How can we come to a conclusion when things remain unclear? I see > only two ways forward - either we settle the dispute (which I'm > afraid would require involvement of someone accepted by all of us > as a "C language lawyer", which would include judgment about the > MISRA-C implications), Well, no, I don't think a "C language lawyer" would help here. You keep making the case for C spec compliance as though we're dealing with zealous but ultimately rational people, who will a) almost never violate the C spec, and b) actually fix their compiler if their language does violate the spec. But it's clear from reading those threads that this is not the case. Over and over people presented clear arguments, from the spec and the spec committee, showing that what gcc was doing was both wrong and impractical; and the compiler people kept coming up with more and more tortuous interpretations to justify the compiler's behavior. The whole thing with supposing that the C standard anticipated a compacting garbage collector was the cherry on the cake. We're not living in a rational world where if we just follow the rules we'll be safe. We have a dictat from the high council in the form of a C spec which is divorced from actual usage and utility, and we have a load of insane fanatics trying to impose their interpretation doctrinal purity on the world, and ready to burn any heretics writing code that doesn't match the view they happen to hold that day. "The compiler can't optimize this because it can't prove they're different objects" is a fine principle, but it's pretty clear that they're willing to continue optimizing things even if you *can* prove they fall inside the rules of pointer comparison. In such a situation, *there is no perfectly safe option*. No matter what position you take, the fanatics may end up deciding that you're a heretic and need to be burned at the stake. Might they decide that they know that extern pointers point to different objects, and therefore can't be compared? Maybe! Might they decide they can pierce the veil of asm to determine the source of unsigned longs they're comparing? Possibly! Could they decide that a uintptr_t received from the heathen lands of assembly is anathema, and therefore casting it to a pointer is undefined behavior? They certainly could! And even if you do convince them their interpretation is wrong and they fix their compiler, the damage is still done: there are still, out in the wild, vulnerable binaries built with buggy compilers and buggy compilers that produce vulnerable binaries, until they all die of old age. *Any* interpretation we choose may be declared at some point by the compiler folks to be heresy. But, there are less safe option and more safe options. Our goal with regard to the C Standard cannot, unfortunately, be "follow the rules". Our goal must be to *minimize the risk* of being caught in the next wave of the compiler optimization purges. MISRA is quirky and often impractical, but ultimately their goal with rules like this is to try to protect you from the fanatics who write compilers (insofar as that is possible). So if we do our best to be as safe as possible from the compiler fanatics, we have a pretty good chance of being considered MISRA compliant as well. It seems to me that anything that involves directly comparing pointers is simply more likely to be come the target of optimization (and thus more dangerous) than comparing unsigned long and uintptr_t. And although I'm not terribly familiar with the "intptr" types, it seems to me that casting from uintptr_t is less likely to ever be considered deviant behavior than casting from unsigned long. As such, I think casting the return value of asm to a pointer is far too dangerous. Using extern pointers seems quite dangerous to me as well. So it seems to me that using asm to generate an unsigned long would be absolute minimum behavior. Using u
Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL
On Fri, 1 Feb 2019, George Dunlap wrote: > On Tue, Jan 22, 2019 at 9:17 AM Jan Beulich wrote: > > > > >>> On 22.01.19 at 00:41, wrote: > > > We haven't managed to reach consensus on this topic. Your view might be > > > correct, but it is not necessarily supported by compilers' behavior, > > > which depends on the opinion of compilers engineers on the topic, and > > > MISRAC compliance, which depends on the opinion of MISRAC specialists on > > > the topic. If we take your suggested approach we end up with the code > > > most likely to break in case the compilers engineers or the MISRAC > > > experts disagree with you. In this case, being right doesn't necessarily > > > lead to the code less likely to break. > > > > > > Regardless, if that is the decision of the Xen community as a whole, > > > I'll follow it. My preference remains with approach 3. (var.S), followed > > > by approach 2. (SYMBOL_HIDE returns uintptr_t), but I am willing to > > > refresh my series to do approach 1. (SYMBOL_HIDE returns pointer type) > > > if that is the only way forward. > > > > > > Let us come to a conclusion so that we can move on. > > > > How can we come to a conclusion when things remain unclear? I see > > only two ways forward - either we settle the dispute (which I'm > > afraid would require involvement of someone accepted by all of us > > as a "C language lawyer", which would include judgment about the > > MISRA-C implications), > > Well, no, I don't think a "C language lawyer" would help here. > > You keep making the case for C spec compliance as though we're dealing > with zealous but ultimately rational people, who will a) almost never > violate the C spec, and b) actually fix their compiler if their > language does violate the spec. > > But it's clear from reading those threads that this is not the case. > Over and over people presented clear arguments, from the spec and the > spec committee, showing that what gcc was doing was both wrong and > impractical; and the compiler people kept coming up with more and more > tortuous interpretations to justify the compiler's behavior. The > whole thing with supposing that the C standard anticipated a > compacting garbage collector was the cherry on the cake. > > We're not living in a rational world where if we just follow the rules > we'll be safe. We have a dictat from the high council in the form of > a C spec which is divorced from actual usage and utility, and we have > a load of insane fanatics trying to impose their interpretation > doctrinal purity on the world, and ready to burn any heretics writing > code that doesn't match the view they happen to hold that day. "The > compiler can't optimize this because it can't prove they're different > objects" is a fine principle, but it's pretty clear that they're > willing to continue optimizing things even if you *can* prove they > fall inside the rules of pointer comparison. That made me laugh very hard :-D in a "sad but true" kind of way. > In such a situation, *there is no perfectly safe option*. No matter > what position you take, the fanatics may end up deciding that you're a > heretic and need to be burned at the stake. Might they decide that > they know that extern pointers point to different objects, and > therefore can't be compared? Maybe! Might they decide they can pierce > the veil of asm to determine the source of unsigned longs they're > comparing? Possibly! Could they decide that a uintptr_t received from > the heathen lands of assembly is anathema, and therefore casting it to > a pointer is undefined behavior? They certainly could! > > And even if you do convince them their interpretation is wrong and > they fix their compiler, the damage is still done: there are still, > out in the wild, vulnerable binaries built with buggy compilers and > buggy compilers that produce vulnerable binaries, until they all die > of old age. > > *Any* interpretation we choose may be declared at some point by the > compiler folks to be heresy. But, there are less safe option and more > safe options. Our goal with regard to the C Standard cannot, > unfortunately, be "follow the rules". Our goal must be to *minimize > the risk* of being caught in the next wave of the compiler > optimization purges. > > MISRA is quirky and often impractical, but ultimately their goal with > rules like this is to try to protect you from the fanatics who write > compilers (insofar as that is possible). So if we do our best to be > as safe as possible from the compiler fanatics, we have a pretty good > chance of being considered MISRA compliant as well. > > It seems to me that anything that involves directly comparing pointers > is simply more likely to be come the target of optimization (and thus > more dangerous) than comparing unsigned long and uintptr_t. And > although I'm not terribly familiar with the "intptr" types, it seems > to me that casting from uintptr_t is less likely to ever be considered > deviant behavior tha
Re: [Xen-devel] [PATCH v3 5/6] xen/x86: add PHYSDEVOP_msi_msix_set_enable
On 1/30/19 8:51 AM, Roger Pau Monné wrote: On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote: Allow device model running in stubdomain to enable/disable MSI(-X), bypassing pciback. While pciback is still used to access config space from within stubdomain, it refuse to write to PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE in non-permissive mode. Which is the right thing to do for PV domain (the main use case for pciback), as PV domain should use XEN_PCI_OP_* commands for that. Unfortunately those commands are not good for stubdomain use, as they configure MSI in dom0's kernel too, which should not happen for HVM domain. This new physdevop is allowed only for stubdomain controlling the domain which own the device. Signed-off-by: Marek Marczykowski-Górecki Thanks! --- Changes in v3: - new patch This is rather RFC. Any suggestions for shorter name? Also, I'm not sure if physdev_msi_msix_set_enable.flag is the best name/idea. I've made some comments below. Should it be plugged into XSM? Any suggestions how exactly? New function with XSM_DM_PRIV default action? Should it get target domain only, or also machine_bdf? You should Cc the XSM maintainer I think, which I've done now. Yes, I think you need to pass both the domain and machine_bdf; the hook sounds like it should be similar to the existing map_domain_irq or assign_device hooks: check that the device model has rights to do this operation on the device, and also check that the device model has rights to modify devices assigned to the device's owner (this check is why the domain is needed). Alternatively, you can hard-code the requirement to be the target domain, but I think this prevents using the same hooks from a dom0 device model. If that's already the case, this is less of an issue. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 132712: tolerable all pass - PUSHED
flight 132712 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/132712/ 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 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 755eb6403ec722db37f1b8f8b51e0b0ab661c003 baseline version: xen ae29aa0f8fdfbd41d5ea71a1338fc6330562cff3 Last test of basis 132708 2019-02-01 15:00:36 Z0 days Testing same since 132710 2019-02-01 17:00:42 Z0 days2 attempts People who touched revisions under test: Doug Goldstein Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git ae29aa0f8f..755eb6403e 755eb6403ec722db37f1b8f8b51e0b0ab661c003 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 132654: all pass - PUSHED
flight 132654 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/132654/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 02021d2ea4f64be3f29d4a0d9707a60889f3f71b baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z 88 days Failing since129526 2018-11-06 20:49:26 Z 87 days 279 attempts Testing same since 132654 2019-01-31 05:48:59 Z1 days1 attempts People who touched revisions under test: Achin Gupta Alex James Ard Biesheuvel Ashish Singhal Bob Feng bob.c.f...@intel.com BobCF Carsey, Jaben Chasel Chiu Chasel, Chiu Chen A Chen Chu, Maggie Dandan Bi David Wei Derek Lin Eric Dong Eugene Cohen Fan, ZhijuX Felix Polyudov Feng, Bob C Fu Siyuan Gary Lin Hao Wu Hsueh, Hong-chihX Jaben Carsey Jagadeesh Ujja Jeff Brasen Jian J Wang Jiaxin Wu Jiewen Yao Julien Grall Krzysztof Koch Laszlo Ersek Leif Lindholm Liming Gao Liu Yu Maggie Chu Marc Zyngier Marcin Wojtas Meenakshi Aggarwal Mike Maslenkin Ming Huang Neo Hsueh Pedroa Liu Ray Ni Ruiyu Ni Sami Mujawar shenglei Shenglei Zhang Siyuan Fu Songpeng Li Star Zeng Sughosh Ganu Sumit Garg Sun, Zailiang Thomas Abraham Thomas Rydman Ting Ye Tomasz Michalec Vijayenthiran Subramaniam Vladimir Olovyannikov Vladimir Olovyannikov via edk2-devel Wang BinX A Wu Jiaxin Ye Ting Yonghong Zhu yuchenlin Zailiang Sun Zhang, Chao B Zhao, ZhiqiangX Zhiju.Fan zhijufan ZhiqiangX Zhao zwei4 jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 5ae3184d8c..02021d2ea4 02021d2ea4f64be3f29d4a0d9707a60889f3f71b -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-xl-credit2
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-credit2 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Bug introduced: 4c35624dcb3bce026bb08eb04085c187bafff863 Bug not present: 7612025fbc7a5ab54bf71f48b99b0b6a15fc7b06 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132724/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-amd64-xl-credit2.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-amd64-xl-credit2.xen-boot --summary-out=tmp/132724.bisection-summary --basis-template=128858 --blessings=real,real-bisect linux-3.18 test-amd64-amd64-xl-credit2 xen-boot Searching for failure / basis pass: 132579 fail [host=debina1] / 132456 [host=italia0] 131535 [host=albana0] 131512 [host=godello1] 131479 [host=godello0] 131442 [host=fiano0] 131420 [host=joubertin0] 131370 [host=baroque1] 131336 [host=huxelrebe1] 131307 [host=rimava1] 131279 [host=italia0] 131231 [host=huxelrebe0] 131192 [host=albana0] 131149 [host=godello1] 131095 [host=godello0] 131035 [host=joubertin0] 130939 [host=fiano0] 130876 [host=rimava1] 130843 [host=albana1] 130367 [host=fiano1] 130203 [host=italia0] 130067 [host=rim\ ava1] 129845 [host=chardonnay0] 129760 [host=baroque0] 128858 [host=pinot0] 128841 [host=pinot1] 128807 [host=baroque0] 128691 [host=italia0] 128258 [host=pinot1] 128232 [host=albana0] 128177 [host=godello0] 128096 [host=albana1] 127486 [host=debina0] 127472 [host=joubertin1] 127455 [host=elbling1] 127296 [host=albana1] 127001 [host=huxelrebe1] 126926 [host=huxelrebe1] 126813 [host=huxelrebe1] 126711 [host=huxelrebe1] 126583 [host=huxelrebe1] 126472 [host=huxelrebe1] 126362 [host=huxelrebe1] 126\ 270 [host=huxelrebe1] 126189 [host=huxelrebe1] 126042 [host=chardonnay0] 125899 [host=pinot1] 125658 [host=debina0] 125649 [host=chardonnay1] 125641 [host=joubertin0] 125561 [host=albana1] 125525 ok. Failure / basis pass flights: 132579 / 125525 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 4c35624dcb3bce026bb08eb04085c187bafff863 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 08b908ba63dee8bc313983c5e412852cbcbcda85 Basis pass 7612025fbc7a5ab54bf71f48b99b0b6a15fc7b06 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#7612025fbc7a5ab54bf71f48b99b0b6a15fc7b06-4c35624dcb3bce026bb08eb04085c187bafff863 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git\ #43139135a8938de44f66333831d3a8655d07663a-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#e3f667bc5f51d0aa44357a64ca134cd952679c81-08b908ba63dee8bc313983c5e412852cbcbcda85 adhoc-revtuple-generator: tree discontiguous: linux-stable adhoc-revtuple-generator: tree discontiguous: qemu-xen Loaded 2006 nodes in revision graph Searching for test results: 125505 [host=godello0] 125525 pass 7612025fbc7a5ab54bf71f48b99b0b6a15fc7b06 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 125561 [host=albana1] 125641 [host=joubertin0] 125649 [host=chardonnay1] 125658 [host=debina0] 125899 [host=pinot1] 126042 [host=chardonnay0] 126189 [host=huxelrebe1] 126270 [host=huxelrebe1] 126362 [host=huxelrebe1] 126472 [host=huxelrebe1] 126583 [host=huxelrebe1] 126738 [host=huxelrebe1] 126721 [host=huxelrebe1] 126708 [host=huxelrebe1] 126726 [host=huxelrebe1] 126693 [host=huxelrebe1] 126713 [host=huxelrebe1] 126697 [host=huxel
[Xen-devel] [linux-4.19 test] 132640: regressions - FAIL
flight 132640 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/132640/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 129313 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 129313 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-xl7 xen-boot fail REGR. vs. 129313 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-examine 8 reboot fail REGR. vs. 129313 test-amd64-amd64-examine 8 reboot fail REGR. vs. 129313 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 129313 Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail in 132578 pass in 132640 test-amd64-amd64-pair 10 xen-boot/src_host fail in 132578 pass in 132640 test-amd64-amd64-pair 11 xen-boot/dst_host fail in 132578 pass in 132640 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail in 132578 pass in 132640 test-amd64-i386-pair10 xen-boot/src_host fail in 132578 pass in 132640 test-amd64-i386-pair11 xen-boot/dst_host fail in 132578 pass in 132640 test-amd64-i386-libvirt-pair 10 xen-boot/src_host fail in 132578 pass in 132640 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host fail in 132578 pass in 132640 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail in 132578 pass in 132640 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 132578 pass in 132640 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 132578 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 1
[Xen-devel] [xen-4.11-testing test] 132647: tolerable FAIL - PUSHED
flight 132647 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/132647/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen df1debf494ac38c95abb602b2b3057613de06b47 baseline version: xen 96cbd0893f783997caaf117e897d5fa8f2dc7b5f Last test of basis 130860 2018-11-29 14:06:50 Z 64 days Failing since132486 2019-01-26 01:36:53 Z7 days3 attempts Testing same since 132588 2019-01-29 20:27:18 Z3 days2 attempts People who touched revisions under test: Julien Grall Marc Zyngie
[Xen-devel] [qemu-mainline test] 132655: regressions - FAIL
flight 132655 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/132655/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 guest-start/debianhvm.repeat fail REGR. vs. 131842 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 131842 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131842 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 131842 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 131842 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 131842 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 131842 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuub4fbe1f65a4769c09e6bf2d79fc84360f840f40e baseline version: qemuu147923b1a901a0370f83a0f4c58ec1baffef22f0 Last test of basis 131842 2019-01-09 00:37:22 Z 24 days Failing since131892 2019-01-09 23:37:00 Z 23 days 20 attempts Testing same since 132591 2019-01-29 21:51:30 Z3 days2 attempts People who touched revisions under test: Aaron Lindsay Aaron Lindsay Aaron Lindsay Aaron Lindsay OS Aleksandar Markovic Alex Bennée Alex Williamson Alexander Graf Alexander Kanavin Alexandro Sanchez Bach Alexey Kardashevskiy Alistair Francis Andrew Jeffery Anthony PERARD BALATON Zoltan Borislav Petkov Christian Borntraeger Christophe Fergeau Cleber Rosa Collin Walling Cornelia Huck Cédric Le G
