>>> On 12.06.19 at 02:23, wrote:
> On 6/11/19 22:03, Jan Beulich wrote:
> On 11.06.19 at 08:02, wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -240,12 +240,14 @@ SECTIONS
>>> *(.altinstructions)
>>> __alt_instructions_end = .;
>>>
>>> +#
Swap function can be used when calling sort().
or else, the default swap function generic_swap() is used,
which is a little inefficient.
Signed-off-by: Baodong Chen
---
xen/arch/arm/io.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/io.c b/xen/arc
flight 137572 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137572/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 137274
test-amd64-amd64-xl-qemut-win7-amd64
flight 137571 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137571/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
build-i386-prev
On 6/11/19 18:29, Juergen Gross wrote:
On 11.06.19 12:27, Andrew Cooper wrote:
On 11/06/2019 11:25, Juergen Gross wrote:
On 11.06.19 12:18, George Dunlap wrote:
On 6/11/19 10:20 AM, Baodong Chen wrote:
* Remove redundant set 'DOMDYING_dead'
domain_create() will set this when fail, thus no ne
flight 137665 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137665/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 6/11/19 18:53, Andrew Cooper wrote:
On 11/06/2019 11:33, chenbaodong wrote:
On 6/11/19 17:45, Andrew Cooper wrote:
On 11/06/2019 10:20, Baodong Chen wrote:
* Remove redundant set 'DOMDYING_dead'
domain_create() will set this when fail, thus no need
set in arch_domain_create().
Its not red
On 6/11/19 22:03, Jan Beulich wrote:
On 11.06.19 at 08:02, wrote:
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -240,12 +240,14 @@ SECTIONS
*(.altinstructions)
__alt_instructions_end = .;
+#if defined(CONFIG_COVERAGE)
. = ALIGN(8);
__cto
On Tue, 14 May 2019, Julien Grall wrote:
> The code handling Xen PT update has quite a few restrictions on what it
> can do. This is not a bad thing as it keeps the code simple.
>
> There are already a few checks scattered in current page table handling.
> However they are not sufficient as they c
On 6/11/19 18:04, George Dunlap wrote:
On 6/11/19 2:35 AM, Baodong Chen wrote:
'struct scheduler' already has member 'opt_name' and 'sched_id',
thus 'name' is a little redundant, so remove it.
Signed-off-by: Baodong Chen
It's not redundant; one is a longer-form human-readable description,
an
On Tue, Jun 11, 2019 at 2:14 PM Nicholas Tsirakis
wrote:
>
> When a message is requeue'd in Xen's internal queue, the queue
> entry contains the length of the message so that Xen knows to
> send a VIRQ to the respective domain when enough space frees up
> in the ring. Due to a small bug, however,
On Tue, Jun 11, 2019 at 2:14 PM Nicholas Tsirakis
wrote:
>
> In its current state, if the destination ring is full, sendv()
> will requeue the message and return the rc of pending_requeue(),
> which will return 0 on success. This prevents the caller from
> distinguishing the difference between a s
On Tue, 14 May 2019, Julien Grall wrote:
> The enum xenmap_operation is not used anymore. So remove it.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andrii Anisov
Acked-by: Stefano Stabellini
> ---
> Changes in v2:
> - Add Andrii's reviewed-by
> ---
> xen/arch/arm/mm.c | 24 ++
On Tue, 14 May 2019, Julien Grall wrote:
> At the moment, the flags are not enough to describe what kind of update
> will done on the VA range. They need to be used in conjunction with the
> enum xenmap_operation.
>
> It would be more convenient to have all the information for the update
> in a si
flight 137567 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
build-amd64-pre
When a message is requeue'd in Xen's internal queue, the queue
entry contains the length of the message so that Xen knows to
send a VIRQ to the respective domain when enough space frees up
in the ring. Due to a small bug, however, Xen doesn't populate
the length of the msg if a given write fails, s
In its current state, if the destination ring is full, sendv()
will requeue the message and return the rc of pending_requeue(),
which will return 0 on success. This prevents the caller from
distinguishing the difference between a successful write and a
message that needs to be resent at a later tim
flight 137662 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137662/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 11/06/2019 20:56, Julien Grall wrote:
> Hi,
>
> On 11/06/2019 19:37, Stefano Stabellini wrote:
>> On Tue, 14 May 2019, Julien Grall wrote:
>>> Currently, the MFN will be incremented even if it is invalid. This will
>>> result to have a valid MFN after the first iteration.
>>>
>>> While this is n
On Tue, Jun 11, 2019 at 12:55 PM Nicholas Tsirakis
wrote:
>
> On Tue, Jun 11, 2019 at 2:49 PM Christopher Clark
> wrote:
> >
> > On Tue, Jun 11, 2019 at 10:11 AM Nicholas Tsirakis
> > wrote:
> > >
> > > When a message is requeue'd in Xen's internal queue, the queue
> > > entry contains the lengt
Hi,
On 11/06/2019 19:37, Stefano Stabellini wrote:
> On Tue, 14 May 2019, Julien Grall wrote:
>> Currently, the MFN will be incremented even if it is invalid. This will
>> result to have a valid MFN after the first iteration.
>>
>> While this is not a major problem today, this will be in the futur
On Tue, Jun 11, 2019 at 2:49 PM Christopher Clark
wrote:
>
> On Tue, Jun 11, 2019 at 10:11 AM Nicholas Tsirakis
> wrote:
> >
> > When a message is requeue'd in Xen's internal queue, the queue
> > entry contains the length of the message so that Xen knows to
> > send a VIRQ to the respective domai
On 11/06/2019 20:22, Christopher Clark wrote:
> On Tue, Jun 11, 2019 at 12:16 PM Andrew Cooper
> wrote:
>> On 11/06/2019 19:43, Christopher Clark wrote:
>>> On Tue, Jun 11, 2019 at 10:11 AM Nicholas Tsirakis
>>> wrote:
In its current state, if the destination ring is full, sendv()
will
On Tue, Jun 11, 2019 at 12:16 PM Andrew Cooper
wrote:
>
> On 11/06/2019 19:43, Christopher Clark wrote:
> > On Tue, Jun 11, 2019 at 10:11 AM Nicholas Tsirakis
> > wrote:
> >> In its current state, if the destination ring is full, sendv()
> >> will requeue the message and return the rc of pending_
flight 137563 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137563/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-amd64-pre
On 11/06/2019 19:43, Christopher Clark wrote:
> On Tue, Jun 11, 2019 at 10:11 AM Nicholas Tsirakis
> wrote:
>> In its current state, if the destination ring is full, sendv()
>> will requeue the message and return the rc of pending_requeue(),
>> which will return 0 on success. This prevents the cal
Hello Julien, Jan,
Julien Grall writes:
> On 16.05.19 at 15:37, wrote:
>>> As build system now supports *_defconfig rules it is good to be able
>>> to configure minimal XEN image with
>>>
>>> make tiny64_defconfig
>>>
>>> command.
>>>
>>> Signed-off-by: Volodymyr Babchuk
>>
>> you had ob
On Tue, Jun 11, 2019 at 10:11 AM Nicholas Tsirakis
wrote:
>
> When a message is requeue'd in Xen's internal queue, the queue
> entry contains the length of the message so that Xen knows to
> send a VIRQ to the respective domain when enough space frees up
> in the ring. Due to a small bug, however,
OP-TEE can issue multiple RPC requests. We are interested mostly in
request that asks NW to allocate/free shared memory for OP-TEE
needs, because mediator needs to do address translation in the same
way as it was done for shared buffers registered by NW.
OP-TEE can ask NW to allocate multiple buff
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where it can write request. So the first RPC
request it makes is special: it requests NW to allocate shared
buffer for other RPC requests. Usually this buf
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destruction and then return an error
to all calls to the guest.
This code issues two non-preemptible calls to OP-TEE: to create and
to destroy client context. They can't block in OP-TEE, as they are
con
This patch adds handling for the fast SMCs. As name suggests, those
calls can't be preempted and are used for auxiliary tasks such as
information retrieval. Most handlers are quite trivial, with exception
for capabilities information.
Capabilities exchange should be filtered out, so only caps
know
The main way to communicate with OP-TEE is to issue standard SMCCC
call. "Standard" is a SMCCC term and it means that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In contrast with fast calls, where arguments and return values
are passed in registers, stan
Shared memory is widely used by NW (Normal World) to communicate with
TAs (Trusted Applications) in OP-TEE. NW can share part of own memory
with TA or with OP-TEE core, by registering it in OP-TEE, or by
providing a temporal reference. Anyways, information about such memory
buffers are sent to OP-T
If TEE support is enabled with "tee=optee" option in xl.cfg,
then we need to inform guest about available TEE, by creating
corresponding node in the guest's device tree.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Julien Grall
Acked-by: Ian Jackson
---
This patch depends on patches to optee
This enumeration controls TEE type for a domain. Currently there is
two possible options: either 'none' or 'optee'.
'none' is the default value and it basically disables TEE support at
all.
'optee' enables access to the OP-TEE running on a host machine. This
requires special OP-TEE build with vir
This header files describes protocol between OP-TEE OS and OP-TEE
clients, which are running in Normal World. This headers are needed
for upcoming OP-TEE mediator, which is added in the next patch. Reason
to add those headers in separate patch is to ease up review. Those
files were taken from OP-TE
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediator" is a such entity.
This is how it works: user can build XEN with multiple TEE mediators
(see the next patches, where
Hello community,
This is the next version of OP-TEE support series.
In case of any issues with mail (Julien Grall had some troubles with =20
sequences in the patches, thanks to our corporate Exchange, I assume),
this series can be pulled from [4].
Note: I deliberately removed Jan Beulich from CC
On Tue, Jun 11, 2019 at 10:11 AM Nicholas Tsirakis
wrote:
>
> In its current state, if the destination ring is full, sendv()
> will requeue the message and return the rc of pending_requeue(),
> which will return 0 on success. This prevents the caller from
> distinguishing the difference between a
On Tue, 14 May 2019, Julien Grall wrote:
> Currently, the MFN will be incremented even if it is invalid. This will
> result to have a valid MFN after the first iteration.
>
> While this is not a major problem today, this will be in the future if
> the code expect an invalid MFN at every iteration.
On Tue, 14 May 2019, Julien Grall wrote:
> In preparation of rework of the Xen PT, the logic to update an entry
> in moved out in a separate function.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Add Andri
Hi Stefano,
On 11/06/2019 19:21, Stefano Stabellini wrote:
> On Tue, 14 May 2019, Julien Grall wrote:
>> There are few places requiring to generate offsets from an address.
>> Rather than open-coding everywhere, we can introduce a macro to do the
>> job for us.
>>
>> Signed-off-by: Julien Grall
>
On 11/06/2019 19:18, Volodymyr Babchuk wrote:
>
> Hi Julien,
Hi,
> Julien Grall writes:
>
>> On 06/06/2019 17:02, Julien Grall wrote:
>>> Hi Volodymyr,
>>>
>>> On 5/21/19 10:25 PM, Volodymyr Babchuk wrote:
+static inline bool tee_handle_call(struct cpu_user_regs *regs)
+{
+ re
On Tue, 14 May 2019, Julien Grall wrote:
> create_xen_entries() is doing more than creating entries. It can also
> modify and remove entries.
>
> Rename the function to make clear what the function is actually doing.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andrii Anisov
Acked-by: Stefan
On Tue, 14 May 2019, Julien Grall wrote:
> There are few places requiring to generate offsets from an address.
> Rather than open-coding everywhere, we can introduce a macro to do the
> job for us.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andrii Anisov
>
> ---
> Changes in v2:
>
Hi Julien,
Julien Grall writes:
> On 06/06/2019 17:02, Julien Grall wrote:
>> Hi Volodymyr,
>>
>> On 5/21/19 10:25 PM, Volodymyr Babchuk wrote:
>>> +static inline bool tee_handle_call(struct cpu_user_regs *regs)
>>> +{
>>> + return false;
>>> +}
>>> +
>>> +static inline int tee_domain_init(struc
On Mon, 10 Jun 2019, Stefano Stabellini wrote:
> On Mon, 10 Jun 2019, Julien Grall wrote:
> > On 6/10/19 9:40 PM, Stefano Stabellini wrote:
> > > Hi Julien,
> >
> > Hi Stefano,
> >
> > >
> > > I expressed my preference below. We don't agree. Is there anything else
> > > you would like me to add
On Mon, 10 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/10/19 9:51 PM, Stefano Stabellini wrote:
> > On Mon, 20 May 2019, Julien Grall wrote:
> > > On 20/05/2019 22:01, Stefano Stabellini wrote:
> > > > On Fri, 10 May 2019, Julien Grall wrote:
> > > > > Feel free to suggest an in-code comm
flight 137658 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137658/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
When a message is requeue'd in Xen's internal queue, the queue
entry contains the length of the message so that Xen knows to
send a VIRQ to the respective domain when enough space frees up
in the ring. Due to a small bug, however, Xen doesn't populate
the length of the msg if a given write fails, s
In its current state, if the destination ring is full, sendv()
will requeue the message and return the rc of pending_requeue(),
which will return 0 on success. This prevents the caller from
distinguishing the difference between a successful write and a
message that needs to be resent at a later tim
Currently, the time_ref_count enlightened time source maintains an offset
such that time is frozen when the domain paused, but the reference_tsc
enlightened time source does not. After migrate, the reference_tsc source
may become invalidated (e.g. because of host cpu frequency mismatch) which
will
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> Instead of setting the scheduler percpu lock address in each of the
> switch_sched instances of the different schedulers do that in
> schedule_cpu_switch() which is the single caller of that function.
> For that purpose let sched_switch_sche
On Tue, Jun 11, 2019 at 11:56:36AM +0100, Andrew Cooper wrote:
> A recent rebuild of the CI contaniers switched from Fedora 29 to 30 because
> the dockerfile is targetting latest.
>
> Unfortunately, the version of iPXE in master doesn't build with the default
> GCC in Fedora 30, which is blocking
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> Instead of using the SCHED_OP() macro to call the different scheduler
> specific functions add inline wrappers for that purpose.
>
Yep, a cleanup that we were thinking to make since quite some time. :-)
> Signed-off-by: Juergen Gross
>
Re
On 10.06.19 22:45, Julien Grall wrote:
Hi,
Hi Julien
Now applied to my staging branch. It will be committed tonight.
Thank you for the patches.
Thank you for the review.
Cheers,
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing l
Hi,
> Yes I missed that PatchGuard would eventually check those shadow pages anyway.
> I was already happy to see that my breakpoints were working, and I proceeded
> to the tests
> hoping to have a quick reproduction of the bug.
>
> I implemented a basic mem_access event on the restricting to --X
Sorry,
Missed one comment
On 07.06.19 17:23, Jan Beulich wrote:
+static void update_runstate_by_gpaddr(struct vcpu *v)
+{
+struct vcpu_runstate_info *runstate =
+(struct vcpu_runstate_info *)v->runstate_guest.phys;
What's the cast for here?
Seems to be not needed.
--
Sincer
On 11.06.19 18:12, Julien Grall wrote:
Acked-by: Julien Grall
Now committed, thank you!
Thank you.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hello Jan,
On 07.06.19 17:23, Jan Beulich wrote:
On 24.05.19 at 20:12, wrote:
From: Andrii Anisov
Existing interface to register runstate are with its virtual address
is prone to issues which became more obvious with KPTI enablement in
guests. The nature of those issues is the fact that the
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> Some functions of struct scheduler are mandatory. Test those in the
> scheduler initialization loop to be present and drop schedulers not
> complying.
>
> Signed-off-by: Juergen Gross
>
As discussed in the other thread already, I personall
On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
> On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
> >
> >> @@ -307,8 +303,7 @@ static int apply_microcode(const struct
> >> microcode_patch *patch)
> >>
> >> mc_intel = patch->mc_intel;
> >>
> >> -/* serialize acce
Hi Gao, Jan
On Tue, Jun 11, 2019 at 08:36:17PM +0800, Chao Gao wrote:
> On Wed, Jun 05, 2019 at 08:09:43AM -0600, Jan Beulich wrote:
> >
> >There's no comment here and nothing in the description: I don't
> >recall clarification as to whether RDTSC is fine to be issued by a
> >thread when ucode is
On 11/06/2019 15:37, Julien Grall wrote:
Hi Andrii,
Sorry for the late answer.
On 5/30/19 1:02 PM, Andrii Anisov wrote:
From: Oleksandr Tyshchenko
In case iommu_ops have been already set, we should not update it.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Andrii Anisov
Acked-b
Hi Andrii,
Sorry for the late answer.
On 5/30/19 1:02 PM, Andrii Anisov wrote:
From: Oleksandr Tyshchenko
In case iommu_ops have been already set, we should not update it.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Andrii Anisov
Acked-by: Julien Grall
Cheers,
---
This patch
flight 137643 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137643/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 137525 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
127792
test-am
>>> On 11.06.19 at 08:02, wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -240,12 +240,14 @@ SECTIONS
> *(.altinstructions)
> __alt_instructions_end = .;
>
> +#if defined(CONFIG_COVERAGE)
> . = ALIGN(8);
> __ctors_start = .;
> *
Hi George,
On 11/06/2019 11:12, George Dunlap wrote:
On 6/11/19 10:41 AM, Jan Beulich wrote:
On 11.06.19 at 11:27, wrote:
Hi Jan,
On 6/11/19 7:43 AM, Jan Beulich wrote:
On 10.06.19 at 22:03, wrote:
Hi,
On 6/5/19 5:01 PM, Julien Grall wrote:
> On 05/06/2019 16:58, Jan Beulich wrote:
On 11/06/2019 10:41, Jan Beulich wrote:
On 11.06.19 at 11:27, wrote:
Hi Jan,
On 6/11/19 7:43 AM, Jan Beulich wrote:
On 10.06.19 at 22:03, wrote:
Hi,
On 6/5/19 5:01 PM, Julien Grall wrote:
> On 05/06/2019 16:58, Jan Beulich wrote:
Julien,
On 16.05.19 at 15:37, wrote:
As build sys
flight 137539 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137539/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 136484
test-amd64-amd64-xl-qe
On 11/06/2019 01:09, chenbaodong wrote:
On 6/11/19 04:11, Julien Grall wrote:
Hi,
Thank you for the patch. The title should be at max 80 characters. So how
about the following title?
"xen/arm: domain: Remove redundant memset for v->arch.saved_context"
Max 80 characters, roger that.
On
On 11/06/2019 01:06, chenbaodong wrote:
On 6/11/19 04:16, Julien Grall wrote:
Hi,
NIT: I would use "change" instead of "fix". I feel "fix" is more when there
are an actual bug.
Sound good to me.
On 6/10/19 6:07 AM, Baodong Chen wrote:
The original type is int and not used at all so fix
>>> On 11.06.19 at 14:46, wrote:
> On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
> On 27.05.19 at 10:31, wrote:
>>> @@ -307,8 +303,7 @@ static int apply_microcode(const struct microcode_patch
>>> *patch)
>>>
>>> mc_intel = patch->mc_intel;
>>>
>>> -/* serialize ac
On 11/06/2019 11:56, Andrew Cooper wrote:
> A recent rebuild of the CI contaniers switched from Fedora 29 to 30 because
> the dockerfile is targetting latest.
>
> Unfortunately, the version of iPXE in master doesn't build with the default
> GCC in Fedora 30, which is blocking all CI activity.
>
> S
On Wed, Jun 05, 2019 at 04:56:01PM +0200, Roger Pau Monné wrote:
>On Mon, May 27, 2019 at 04:31:31PM +0800, Chao Gao wrote:
>> From: Sergey Dyasli
>>
>> Currently cpu_sig struct is not updated during boot when either:
>>
>> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>>
>>> On 11.06.19 at 14:36, wrote:
> On Wed, Jun 05, 2019 at 08:09:43AM -0600, Jan Beulich wrote:
> On 27.05.19 at 10:31, wrote:
>>On the whole, taking a 256-thread system as example, you
>>allow the whole process to take over 4 min without calling
>>panic().
>>Leaving aside guests, I don't thi
On Wed, Jun 05, 2019 at 09:05:49AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> From: Sergey Dyasli
>>
>> Currently cpu_sig struct is not updated during boot when either:
>>
>> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>> 2. initrd does not contai
>>> On 10.06.19 at 18:54, wrote:
> On 23/05/2019 13:19, Jan Beulich wrote:
>> From: Ross Lagerwall
>>
>> Signed-off-by: Ross Lagerwall
>>
>> Make handling in do_pm_op() more homogeneous: Before interpreting
>> op->cpuid as such, handle all operations not acting on a particular
>> CPU. Also expos
>>> On 10.06.19 at 18:43, wrote:
> On 23/05/2019 13:18, Jan Beulich wrote:
>> From: Ross Lagerwall
>>
>> Allow limiting the max C-state sub-state by appending to the max_cstate
>> command-line parameter. E.g. max_cstate=1,0
>> The limit only applies to the highest legal C-state. For example:
>>
> -Original Message-
> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> Sent: 04 June 2019 12:50
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
> ; w...@xen.org; Roger Pau Monne
> ;
> boris.ostrov...@oracle.com; suravee.suthikulpa
>>> On 10.06.19 at 18:28, wrote:
> On 23/05/2019 13:18, Jan Beulich wrote:
>> At least for more recent CPUs, following what BKDG / PPR suggest for the
>> BIOS to surface via ACPI we can make ourselves independent of Dom0
>> uploading respective data.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> TBD
On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> microcode_update_lock is to prevent logic threads of a same core from
>> updating microcode at the same time. But due to using a global lock, it
>> also prevented parallel microcode updating on differ
On 11.06.19 15:32, Julien Grall wrote:
Did you expect Xen to be fully preemptible?
The function to do the scheduling is schedule(). This is either call from a
softirq or directly in a few places (e.g wait()).
The only place in this path where do_softirq() will be called is on return to
the
On 11/06/2019 13:26, Andrii Anisov wrote:
On 11.06.19 15:12, Julien Grall wrote:
Julien, I'm not sure I understand how work on (p?)CPU could be delayed. We
are here with interrupts enabled, so here guest would just spend his own vcpu
time budget.
Xen only supports only voluntary preempti
Hi Andrew, Tamas,
Le mercredi, mai 29, 2019 2:49 AM, Andrew Cooper a
écrit :
> After a series of tests on 1 or 4 VCPUs, my domain end up in 2 possible
> states: - frozen: the mouse doesn't move: so I would guess the VCPU are
> blocked. I'm calling the xc_(un)pause_domain APIs multiple times w
On Wed, Jun 05, 2019 at 08:09:43AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> This patch ports microcode improvement patches from linux kernel.
>>
>> Before you read any further: the early loading method is still the
>> preferred one and you should always do that. The followin
On 11.06.19 15:12, Julien Grall wrote:
Julien, I'm not sure I understand how work on (p?)CPU could be delayed. We are here with interrupts enabled, so here guest would just spend his own vcpu time budget.
Xen only supports only voluntary preemption.
Oh, really? Let me look into it a bit clo
>>> On 10.06.19 at 17:48, wrote:
> On 23/05/2019 13:16, Jan Beulich wrote:
>> While the MWAIT idle driver already takes it to mean an actual C state,
>> the ACPI idle driver so far used it as a list index. The list index,
>> however, is an implementation detail of Xen and affected by firmware
>> s
Hi,
On 11/06/2019 11:22, Andrii Anisov wrote:
On 11.06.19 12:10, Jan Beulich wrote:
@@ -35,8 +37,16 @@ arch_compat_vcpu_op(
!compat_handle_okay(area.addr.h, 1) )
break;
+ while( xchg(&v->runstate_in_use, 1) == 0);
At the very least such loops want a cpu_r
A recent rebuild of the CI contaniers switched from Fedora 29 to 30 because
the dockerfile is targetting latest.
Unfortunately, the version of iPXE in master doesn't build with the default
GCC in Fedora 30, which is blocking all CI activity.
Switch from latest to an explicit version, to avoid fut
On 11/06/2019 11:33, chenbaodong wrote:
>
> On 6/11/19 17:45, Andrew Cooper wrote:
>> On 11/06/2019 10:20, Baodong Chen wrote:
>>> * Remove redundant set 'DOMDYING_dead'
>>> domain_create() will set this when fail, thus no need
>>> set in arch_domain_create().
>> Its not redundant. It is necessary
On Tue, 2019-06-11 at 12:25 +0200, Juergen Gross wrote:
> On 11.06.19 12:18, George Dunlap wrote:
> > On 6/11/19 10:20 AM, Baodong Chen wrote:
> > > --- a/xen/common/schedule.c
> > > +++ b/xen/common/schedule.c
> > > @@ -1894,9 +1894,11 @@ struct scheduler *scheduler_alloc(unsigned
> > > int sched_
On 6/11/19 17:45, Andrew Cooper wrote:
On 11/06/2019 10:20, Baodong Chen wrote:
* Remove redundant set 'DOMDYING_dead'
domain_create() will set this when fail, thus no need
set in arch_domain_create().
Its not redundant. It is necessary for correct cleanup.
Hello Andrew,
Thanks for your co
On 11.06.19 12:27, Andrew Cooper wrote:
On 11/06/2019 11:25, Juergen Gross wrote:
On 11.06.19 12:18, George Dunlap wrote:
On 6/11/19 10:20 AM, Baodong Chen wrote:
* Remove redundant set 'DOMDYING_dead'
domain_create() will set this when fail, thus no need
set in arch_domain_create().
* Set er
Hello Jan,
On 11.06.19 12:10, Jan Beulich wrote:
Except when there's no need for KPTI in the guest in the first place,
as is the case for x86-64 PV guests. I think this is worthwhile clarifying.
I am not sure what is your point here. At least on Arm, using virtual address is
not safe at all (w
On 11/06/2019 11:25, Juergen Gross wrote:
> On 11.06.19 12:18, George Dunlap wrote:
>> On 6/11/19 10:20 AM, Baodong Chen wrote:
>>> * Remove redundant set 'DOMDYING_dead'
>>> domain_create() will set this when fail, thus no need
>>> set in arch_domain_create().
>>>
>>> * Set error when really happe
On 11.06.19 12:18, George Dunlap wrote:
On 6/11/19 10:20 AM, Baodong Chen wrote:
* Remove redundant set 'DOMDYING_dead'
domain_create() will set this when fail, thus no need
set in arch_domain_create().
* Set error when really happened
diff --git a/xen/common/schedule.c b/xen/common/schedule
Hello Dario
On 11.06.19 13:01, Dario Faggioli wrote:
As per the current code I'd rename the member to `last_sched_time`.
To reflect that it is the time when the vcpu went through scheduling
path.
Ok, yes, this is something I personally can live with. :-)
Good.
I'll send v4 with no comment
1 - 100 of 119 matches
Mail list logo
