flight 125109 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
test-armhf-armhf-xl-credit2 4
On Thu, 12 Jul 2018, Julien Grall wrote:
> Hi,
>
> Would it be possible to provide a branch with the patch applied? It would be
> nice to have that for every version, so I can easily know on which version of
> you are based and avoid spending time trying to apply it :).
Makes sense, I'll do from
>>> On 13.07.18 at 13:19, wrote:
> On Vi, 2018-07-13 at 04:29 -0600, Jan Beulich wrote:
>> >
>> > >
>> > > >
>> > > > On 13.07.18 at 11:04, wrote:
>> > Changes since V10:
>> >- Add memset to 0 for ctxt.
>> Why? What's wrong with ...
>>
>> >
>> > --- a/xen/arch/x86/cpu/mcheck/vmce.c
>> >
flight 125151 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125151/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ae08ea246fe9b4a4e05b7ee6cdbd5b0fa38f3f69
baseline version:
ovmf
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 11 July 2018 14:43
> To: xen-devel
> Cc: Andrew Cooper
> Subject: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through
> hvm_funcs to direct ones
>
> This
On 11/07/18 14:23, Jan Beulich wrote:
> Three of the four hooks are not exposed outside of vmx.c, and all of
> them have only a single possible non-NULL value. So there's no reason to
> use hooks here - a simple set of flag indicators is sufficient (and we
> don't even need a flag for the VM entry
On 11/07/18 14:23, Jan Beulich wrote:
> Instead of checking hvm_tsc_scaling_supported inside the hook function,
> install the hook only when setting state such that said predicate
> becomes true.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 11/07/18 14:25, Jan Beulich wrote:
> Commit a1b1572833 ("VMX: add VMFUNC leaf 0 (EPTP switching) to
> emulator") needlessly introduced it, and no user has appeared since.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel
>>> On 13.07.18 at 13:14, wrote:
> On Vi, 2018-07-13 at 04:34 -0600, Jan Beulich wrote:
>> >
>> > >
>> > > >
>> > > > On 13.07.18 at 11:04, wrote:
>> > --- a/xen/arch/x86/hvm/viridian.c
>> > +++ b/xen/arch/x86/hvm/viridian.c
>> > @@ -1026,20 +1026,26 @@ static int
On Fri, Jul 13, 2018 at 04:04:56AM -0600, Jan Beulich wrote:
> >>> On 13.07.18 at 09:55, wrote:
> > On Fri, Jul 13, 2018 at 01:49:37AM -0600, Jan Beulich wrote:
> >> >>> On 12.07.18 at 18:48, wrote:
> >> > In the x86 test harness and the fuzzer, and instead create a link in
> >> > the
On 11/07/18 14:26, Jan Beulich wrote:
> It's used in quite a few places, and hence doing so eases subsequent
> adjustment to how these (indirect) calls are carried out.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Overall, I'd say that it would be good to have wrappers for all the
On 11/07/18 14:24, Jan Beulich wrote:
> From: Suravee Suthikulpanit
>
> This patch modifies the hvm_funcs.virtual_intr_delivery_enabled()
> to become a bool variable as VMX does and SVM will simply return a
> static value.
>
> Signed-off-by: Suravee Suthikulpanit
> Signed-off-by: Jan Beulich
On 11/07/18 14:27, Jan Beulich wrote:
> Since the generic pattern rules don't match those, explicit rules need
> to be put in place for this to work.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
This run is configured for baseline tests only.
flight 74966 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74966/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 280f49b81170aee9176a47085b168ff3bc9fd3e7
baseline
flight 125086 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125086/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
This run is configured for baseline tests only.
flight 74965 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74965/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0c6f94dae5e3ca57fe6093ce2fa4d78fdd061857
baseline
flight 125149 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125149/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
>>> On 13.07.18 at 11:04, wrote:
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -1026,20 +1026,26 @@ static int viridian_load_domain_ctxt(struct domain
> *d, hvm_domain_context_t *h)
> HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt,
>
flight 125081 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-armhf-xl 4
>>> On 13.07.18 at 09:55, wrote:
> On Fri, Jul 13, 2018 at 01:49:37AM -0600, Jan Beulich wrote:
>> >>> On 12.07.18 at 18:48, wrote:
>> > In the x86 test harness and the fuzzer, and instead create a link in
>> > the tools/include directory that can be used by all the tools.
>> >
>> > No
On Thu, Jul 12, 2018 at 05:26:49PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 12, 2018 at 01:38:21PM +0200, Daniel Kiper wrote:
> > On Wed, Jul 11, 2018 at 05:34:48PM +0200, Roger Pau Monne wrote:
> > > With '|'. The result is the same, and the later works with lld. Fixes
> > > the following
On Thu, Jul 12, 2018 at 06:37:33PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 12, 2018 at 01:35:14PM +0200, Daniel Kiper wrote:
> > On Wed, Jul 11, 2018 at 05:34:50PM +0200, Roger Pau Monne wrote:
> > > This allows removing the DEFINED conditional in the linker script, and
> > > fixes compilation
>>> On 13.07.18 at 11:04, wrote:
> Changes since V10:
> - Add memset to 0 for ctxt.
Why? What's wrong with ...
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -349,6 +349,20 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
> return ret;
> }
>
>
Hi Jan,
On 13/07/18 09:10, Jan Beulich wrote:
On 11.07.18 at 15:15, wrote:
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many
>>> On 13.07.18 at 13:37, wrote:
> On Fri, Jul 13, 2018 at 04:04:56AM -0600, Jan Beulich wrote:
>> >>> On 13.07.18 at 09:55, wrote:
>> > On Fri, Jul 13, 2018 at 01:49:37AM -0600, Jan Beulich wrote:
>> >> >>> On 12.07.18 at 18:48, wrote:
>> >> > In the x86 test harness and the fuzzer, and
>>> On 13.07.18 at 12:06, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> Sent: 11 July 2018 14:43
>> To: xen-devel
>> Cc: Andrew Cooper
>> Subject: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls
>>> On 13.07.18 at 14:19, wrote:
> On 11/07/18 14:26, Jan Beulich wrote:
>> It's used in quite a few places, and hence doing so eases subsequent
>> adjustment to how these (indirect) calls are carried out.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Andrew Cooper
Thanks.
> Overall, I'd
>>> On 13.07.18 at 15:00, wrote:
> Hi Jan,
>
> On 13/07/18 09:10, Jan Beulich wrote:
> On 11.07.18 at 15:15, wrote:
>>> While indirect calls have always been more expensive than direct ones,
>>> their cost has further increased with the Spectre v2 mitigations. In a
>>> number of cases we
On Vi, 2018-07-13 at 05:53 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 13.07.18 at 13:14, wrote:
> > On Vi, 2018-07-13 at 04:34 -0600, Jan Beulich wrote:
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > On 13.07.18 at 11:04, wrote:
> > > > ---
Hi,
On 13/07/18 14:27, Jan Beulich wrote:
On 13.07.18 at 15:00, wrote:
Hi Jan,
On 13/07/18 09:10, Jan Beulich wrote:
On 11.07.18 at 15:15, wrote:
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
flight 125153 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125153/
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
The buildsystem of seabios always includes the current time and the
hostname into the resulting binary. To avoid that, it is required to
have a file '.version' in the toplevel directory of seabios-dir-remote.
And it is required to pass EXTRAVERSION= to make because its toplevel
Makefile does not
On Vi, 2018-07-13 at 04:34 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 13.07.18 at 11:04, wrote:
> > --- a/xen/arch/x86/hvm/viridian.c
> > +++ b/xen/arch/x86/hvm/viridian.c
> > @@ -1026,20 +1026,26 @@ static int viridian_load_domain_ctxt(struct
> > domain *d, hvm_domain_context_t
On Vi, 2018-07-13 at 04:29 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 13.07.18 at 11:04, wrote:
> > Changes since V10:
> > - Add memset to 0 for ctxt.
> Why? What's wrong with ...
>
> >
> > --- a/xen/arch/x86/cpu/mcheck/vmce.c
> > +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> > @@
flight 125145 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125145/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0c6f94dae5e3ca57fe6093ce2fa4d78fdd061857
baseline version:
ovmf
flight 125079 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125079/
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
On Thu, Jul 12, 2018 at 08:14:06PM -0500, Doug Goldstein wrote:
> On Thu, Jul 12, 2018 at 02:33:42PM -0500, Doug Goldstein wrote:
> > On Thu, Jul 12, 2018 at 05:31:27PM +0100, Wei Liu wrote:
> > > We don't need to specify /bin/bash in the entry point rune, otherwise
> > > non-interactive
>>> On 12.07.18 at 18:48, wrote:
> In the x86 test harness and the fuzzer, and instead create a link in
> the tools/include directory that can be used by all the tools.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Ian Jackson
>>> On 12.07.18 at 17:38, wrote:
> On 11/07/18 13:09, Jan Beulich wrote:
>> Reportedly Intel CPUs which can't broadcast #MC to all targeted
>> cores/threads because some have CR4.MCE clear will shut down. Therefore
>> we want to keep CR4.MCE enabled when offlining a CPU, and we need to
>> bring
On Thu, Jul 12, 2018 at 06:48:06PM +0200, Roger Pau Monne wrote:
> In the x86 test harness and the fuzzer, and instead create a link in
> the tools/include directory that can be used by all the tools.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
> ---
Acked-by: Wei Liu
On Thu, Jul 12, 2018 at 05:48:40AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 12:53, wrote:
> > On Wed, Jul 11, 2018 at 06:06:04AM -0600, Jan Beulich wrote:
> > [...]
> >> --- a/xen/arch/x86/smpboot.c
> >> +++ b/xen/arch/x86/smpboot.c
> >> @@ -63,6 +63,8 @@ static cpumask_t scratch_cpu0mask;
flight 125147 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125147/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 280f49b81170aee9176a47085b168ff3bc9fd3e7
baseline version:
ovmf
>>> On 12.07.18 at 17:45, wrote:
> On 11/07/18 13:10, Jan Beulich wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1040,6 +1040,13 @@ identical to the boot CPU will be parked
>> ### hpetbroadcast (x86)
>> > `= `
>>
>> +### ht (x86)
>
>
On 12/07/18 19:27, Boris Ostrovsky wrote:
> Otherwise we may leak kernel stack for events that sample user
> registers.
>
> Reported-by: Mark Rutland
> Signed-off-by: Boris Ostrovsky
> Cc: sta...@vger.kernel.org
Reviewed-by: Juergen Gross
Juergen
This patch is focused on moving the for loop to the caller so
now we can save info for a single vcpu instance with the save_one
handlers.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/save.c | 141 +---
1 file changed, 111 insertions(+), 30
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
xen/arch/x86/hvm/viridian.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
This patch removes the redundant save functions and renames the
save_one* to save. It then changes the domain param to vcpu in the save
funcs.
Signed-off-by: Alexandru Isaila
---
Changes since V9:
- Add enum return type for save funcs
---
xen/arch/x86/cpu/mcheck/vmce.c | 24 +++--
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/cpu/mcheck/vmce.c | 1 -
xen/arch/x86/hvm/hpet.c| 2 +-
xen/arch/x86/hvm/hvm.c | 5 +
xen/arch/x86/hvm/i8254.c | 2 +-
xen/arch/x86/hvm/irq.c | 6 +++---
xen/arch/x86/hvm/mtrr.c| 2 +-
On Fri, Jul 13, 2018 at 01:49:37AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 18:48, wrote:
> > In the x86 test harness and the fuzzer, and instead create a link in
> > the tools/include directory that can be used by all the tools.
> >
> > No functional change.
> >
> > Signed-off-by: Roger
>>> On 11.07.18 at 15:15, wrote:
> While indirect calls have always been more expensive than direct ones,
> their cost has further increased with the Spectre v2 mitigations. In a
> number of cases we simply pointlessly use them in the first place. In
> many other cases the indirection solely
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V10:
- Add ASSERT to save_one func.
---
xen/arch/x86/hvm/hvm.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V9:
- Change return of the save_one func to return hvm_save_entry.
---
xen/arch/x86/hvm/hvm.c | 14 ++
1 file changed, 10 insertions(+), 4
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V10:
- Add memset to 0 for ctxt.
---
xen/arch/x86/cpu/mcheck/vmce.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since v10:
- Add blank line before memset.
Note: This patch is based on Roger Pau Monne's series[1]
---
xen/arch/x86/hvm/mtrr.c | 76 ++---
1 file
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V7:
- Moved the init of ctxt->count to hvm_save_cpu_msrs_one()
---
xen/arch/x86/hvm/hvm.c | 101 +++--
1 file
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V8:
- Change return of the save_one func to return hvm_save_entry
- Move continue out of on func
- Remove #define CONTINUE.
---
On 11/07/18 14:04, Jan Beulich wrote:
> While I've run into the issue with further patches in place which no
> longer guarantee the per-CPU area to start out as all zeros, the
> CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
> the per-CPU cpupool pointer,
Hi all,
This patch series addresses the ideea of saving data from a single vcpu
instance.
First it starts by adding *save_one functions, then it introduces a handler for
the
new save_one* funcs and makes use of it in the hvm_save and hvm_save_one funcs.
The final 2 patches are used for clean
flight 74964 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74964/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74939
baseline version:
This run is configured for baseline tests only.
flight 74967 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74967/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ae08ea246fe9b4a4e05b7ee6cdbd5b0fa38f3f69
baseline
So that it can be used by other components apart from the efi specific
code.
This is required so that the conditional used to define the efi symbol
in the linker script can be removed and instead the definition of the
efi symbol can be guarded using the preprocessor.
The motivation behind this
flight 125155 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125155/
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
Hello,
I'm currently testing last Xen 4.8.4 build for CentOS
(http://cbs.centos.org/koji/buildinfo?buildID=23169) and disabling
XPTI for dom0 doesn't seem to work:
(XEN) Command line: dom0_mem=1792M,max:2048M dom0_max_vcpus=4 cpuinfo
com1=115200,8n1 console=com1,vga xpti=dom0=false loglvl=all
flight 125096 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125096/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 122969
From: Roger Pau Monné
Both Xen and the toolstack have need of the same logic when it comes to
manipulation and checking of the CPUID and MSR values offered to guests. To
that end, libx86 is being introduced to allow Xen and the toolstack to share a
single implementation, rather than duplicating
This series introduces libx86, a small shared library between the hypervisor
and libxc, and hypercalls to get full CPUID/MSR policies. Future work will
implement XEN_DOMCTL_set_cpumsr_policy, after the auditing and comparison
logic is sorted.
In the meantime, the data marshalling logic is in a
To facilitate the shared Xen and toolstack code in libx86, struct msr_policy
needs to be available in the same way as struct cpuid_policy.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Ian Jackson
v2:
* Rebase over the
From: Roger Pau Monné
Move x86_cpuid_lookup_deep_deps() into the shared library, removing the
individual copies from the hypervisor and libxc respectively.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC:
As with the serialise side, Xen's copy_from_guest API is used, with a
compatibility wrapper for the userspace build.
Signed-off-by: Andrew Cooper
Signed-off-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Ian
Begin to untangle the header dependency tangle by moving definition of
struct cpuid_leaf out of x86_emulate.h into the new cpuid.h.
Additionally, plumb the header through to libxc. This is technically a
redundant include at this point, but it helps build-test the later changes,
and will be used
From: Roger Pau Monné
This avoids all users needing to opencode local generation of the file.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Ian Jackson
v2:
* Rewrite from scratch
---
.gitignore
From: Roger Pau Monné
As with CPUID, an architectural form is used for representing the MSR data.
It is expected not to change moving forwards, but does have a 32 bit field
(currently reserved) which can be used compatibly if needs be.
Signed-off-by: Andrew Cooper
Signed-off-by: Sergey Dyasli
The serialised form is made up of the leaf, subleaf and data tuple. As this
is the architectural form, it is expected not to change going forwards.
The serialisation of the Xen/Viridian leaves isn't fully implemented yet. It
is just enough to be bug-compatible with the current DOMCTL_set_cpuid
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of George John
> Sent: Thursday, July 5, 2018 1:41 AM
> To: xen-devel
> Subject: [Xen-devel] Error during cross compiling of xen by chroot
>
> Hi,
> I am using chroot to cross compile xen.
On Thu, 12 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 07/07/2018 00:12, Stefano Stabellini wrote:
> > Introduce vpl011 support to guests started from Xen: it provides a
> > simple way to print output from a guest, as most guests come with a
> > pl011 driver. It is also able to provide a
Hi all,
It is time for another Xen on ARM Community Call. I suggest to talk
again on Wed 25 July at 9AM California time.
Please reply to this thread suggestions topics for discussion. I'll
start by suggesting "progress on certifications".
This time we get to use the Xilinx WebEx conference
This is prep work for the following patch - please refer to it as well.
When auditing and manipulating policies, it is necessary to do so with a
complete set of policies, due to the interdependences of the contents. A
containing structure like this will allow for clearer APIs and code.
As a
From: Sergey Dyasli
Provide a SYSCTL for the toolstack to obtain complete system CPUID and MSR
policy information.
For the XSM side of things, this subop is closely related to
{phys,cputopo,numa}info, so shares the physinfo access vector.
Extend the xen-cpuid utility to be able to dump the
From: Sergey Dyasli
This finally (after literally years of work!) marks the point where the
toolstack can ask the hypervisor for the current CPUID configuration of a
specific domain.
Also extend xen-cpuid's --policy mode to be able to take a domid and dump a
specific domains CPUID and MSR
From: Roger Pau Monné
Signed-off-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Ian Jackson
v2:
* Rebase over the msr_{domain,vcpu}_policy rename
* Only deserialse msr_policy
*
On Mon, 9 Jul 2018, Julien Grall wrote:
> Hi,
>
> On 07/07/18 00:12, Stefano Stabellini wrote:
> > Extend the existing device tree based multiboot protocol to include
> > information regarding multiple domains to boot.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v2:
>
81 matches
Mail list logo
