>>> On 02.11.18 at 18:54, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -311,8 +311,11 @@ struct vcpu *alloc_vcpu_struct(void)
> * may require that the shadow CR3 points below 4GB, and hence the whole
> * structure must satisfy this restriction. Thus we specif
>>> On 02.11.18 at 20:33, wrote:
> Introduce a new directory to put in configs we care about. Modify
> build script to build with those configs.
>
> While we only introduce x86 configs initially, provision for non-x86
> configs.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
> Jan, feel fr
>>> On 03.11.18 at 00:45, wrote:
> Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> mechanism to allow for switching between Xen, Dom0, and any of the
> initial DomU created from Xen alongside Dom0 out of information provided
> via device tree.
>
> Rename xen_rx to console_rx t
On 2018-10-22 16:03, Arun KS wrote:
On 2018-10-19 13:37, Michal Hocko wrote:
On Thu 18-10-18 19:18:25, Andrew Morton wrote:
[...]
So this patch needs more work, yes?
Yes, I've talked to Arun (he is offline until next week) offlist and
he
will play with this some more.
Converted totalhigh_
>>> On 02.11.18 at 19:14, wrote:
> On 02/11/18 16:45, Jan Beulich wrote:
>> This is a check explicitly listed by the instruction page in the SDM.
>>
>> Signed-off-by: Jan Beulich
>
> Hmm - looking at the listing, I think we've got an IOPL mismatch. This
> behaviour, as well as the VIP adjustmen
This patch adds a couple of regs to the vm_event that are used by
the introspection. The base, limit and ar
bits are compressed into a uint64_t union so as not to enlarge the
vm_event.
Signed-off-by: Alexandru Isaila
---
Changes since V7:
- Move dr6 netx to dr7 in vm_event_regs_x86.
---
>>> On 02.11.18 at 19:24, wrote:
> On 02/11/18 16:46, Jan Beulich wrote:
>> Now that there's an almost unconditional CR4 read right at the beginning
>> of x86_emulate(), centralize its reading there and use result and value
>> everywhere else without further invoking the hook.
>>
>> Subsequently w
On Sun, Nov 4, 2018 at 10:49:02PM +0200, Pasi Kärkkäinen wrote:
>
> Hello Ian,
>
> On Mon, Oct 29, 2018 at 08:55:09PM +, Paraschiv, Andra-Irina wrote:
> >
> >
> > On Mon, Oct 29, 2018 at 04:58:22PM +0200, Pasi Kärkkäinen wrote:
> > > Hi,
> > >
> > > On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ia
>>> On 05.11.18 at 10:54, wrote:
> This patch adds a couple of regs to the vm_event that are used by
> the introspection. The base, limit and ar
> bits are compressed into a uint64_t union so as not to enlarge the
> vm_event.
>
> Signed-off-by: Alexandru Isaila
Acked-by: Jan Beulich
___
On Tue, Oct 30, 2018 at 15:19:22 +, Wei Liu wrote:
On Tue, Oct 30, 2018 at 01:32:38PM +0200, Alexandru Vasile wrote:
Hello,
There is some low-hanging fruit, both in Xen and the Linux kernel,
which can really be worked in parallel by different parties, so let me
know if you have some capa
On Mon, Nov 05, 2018 at 02:06:01AM -0700, Jan Beulich wrote:
> >>> On 02.11.18 at 20:33, wrote:
> > Introduce a new directory to put in configs we care about. Modify
> > build script to build with those configs.
> >
> > While we only introduce x86 configs initially, provision for non-x86
> > conf
On Sun, Nov 04, 2018 at 06:37:36PM +0530, Rishi wrote:
> I've built a dom0 kernel 4.14 with SMP support. The dom0 kernel crashes
> when I'm downloading a large file on host. It does not crash if I have
> nosmp boot option on xen command line.
>
> my .config SMP options are
>
> [root@f6029920339a
On Fri, Nov 02, 2018 at 07:30:43PM +, Andrew Cooper wrote:
> On 02/11/18 19:28, Wei Liu wrote:
> > This function is used by PV code only. This issue is discovered by
> > clang build.
>
> Indeed. It is only used by two PV hypercalls.
>
> >
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86
flight 75571 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75571/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail blocked in
75534
test-amd64-i386-amd64-sid-netboot-
On 11/05/2018 08:50 AM, Jan Beulich wrote:
On 02.11.18 at 18:54, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -311,8 +311,11 @@ struct vcpu *alloc_vcpu_struct(void)
>> * may require that the shadow CR3 points below 4GB, and hence the whole
>> * struct
Nothing is getting logged. I suspect its because the kernel just goes in
halt state.
/var/log/kern.log /var/log/messages /var/log/xen/hypervisor.log
All of these files have nothing appended.
I can fetch info from kernel debugfs, if you point me to required area,
The dom0 kernel works fine with
Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition
[and 1 more messages] [and 2 more messages] [and 2 more messages]"):
> Basically, you are saying that even if had a well maintained deb
> repository of kernel packages for OSSTest to use, doesn't matter how we
> achieve th
On Mon, Nov 05, 2018 at 11:58:09AM +0200, Alexandru Vasile wrote:
> Hello,
> (XEN) event_channel.c:319:d0v1 EVTCHNOP failure: domain 1, error -22
> (XEN) event_channel.c:319:d0v3 EVTCHNOP failure: domain 1, error -22
Do you perhaps have more than one xenstored / xenconsoled running?
> (XEN) Asser
On Mon, Nov 05, 2018 at 04:26:03PM +0530, Rishi wrote:
> Nothing is getting logged. I suspect its because the kernel just goes in
> halt state.
>
> /var/log/kern.log /var/log/messages /var/log/xen/hypervisor.log
>
> All of these files have nothing appended.
>
> I can fetch info from kernel debug
Hi Stefano,
On 02/11/2018 23:44, Stefano Stabellini wrote:
On Fri, 2 Nov 2018, Julien Grall wrote:
On 02/11/2018 17:56, Stefano Stabellini wrote:
On Fri, 2 Nov 2018, Ian Jackson wrote:
Ie the biggest work here of all kinds is is glue. Adding more
entities to the problem will increase rather
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
b
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 firs
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
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.
Introduce a new flask access vector and update the default policies.
Also extend xen-cpuid's --policy mode to be
Its long-since time to repost this work, seeing as it is blocking parts of the
speculative improvement work already discussed. See indiviudal patches for
details.
Andrew Cooper (2):
libx86: Introduce a helper to serialise cpuid_policy objects
x86: Introduce struct cpu_policy to refer to a gro
From: Sergey Dyasli
Provide a SYSCTL for the toolstack to obtain complete system CPUID and MSR
policy information.
For the flask 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 sy
flight 129430 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129430/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e048ce883c8e9f746a655ca5a4c8c0ce34198999
baseline version:
ovmf 93f98985826a6eba30584
Prompted by Jan's "x86emul: consolidate CR4 handling", I've cleaned up this
series and posted it. The end purpose is the substantial reduction in
compiled volume of x86_emulate().
Andrew Cooper (6):
tools: Move the typesafe min/max helpers into xen-tools/libs.h
libx86: Split x86_cpuid_policy_
This will shortly be wanted by the userspace emulator harnesses as well.
Consolidate the cpuid{,_count}_leaf() helpers beside the structure definition,
rather than having them scattered throughout Xen.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/cpuid.c
This will shortly be required to pass into the emulator itself.
Simplify the shared cpu_has_* helpers by reading the correct bit out of the
CPUID policy itself.
No (intended) change in behaviour.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
tools/fuzz/x86_instruction_emul
They are identical, so provide a single x86emul_cpuid() instead.
As x86_emulate() now only uses the ->cpuid() hook for real CPUID instructions,
the hook can be omitted from all special-purpose emulation ops.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/hvm/emu
This will be used to simplify feature checking.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 1 +
tools/tests/x86_emulator/test_x86_emulator.c| 2 +-
xen/arch/x86/hvm/emulate.c | 2 +-
xen/arch/x86/m
... rather than implementing them separately for libxc and libxl. They will
shortly be wanted in libx86 as well.
Fix up the style/consistency in the declaration, but no functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/include/xen-tools/libs.h | 38 +++
For a release build of xen, this removes almost 4k of code volume, and removes
a function pointer call from every instantiation.
add/remove: 0/1 grow/shrink: 0/3 up/down: 0/-3877 (-3877)
Function old new delta
adjust_bnd
On Mon, Nov 05, 2018 at 11:21:02AM +, Andrew Cooper wrote:
> ... rather than implementing them separately for libxc and libxl. They will
> shortly be wanted in libx86 as well.
>
> Fix up the style/consistency in the declaration, but no functional change.
>
> Signed-off-by: Andrew Cooper
Ac
Alright, I got the serial console and following is the crash log. Thank you
for pointing that out.
[ 133.594852] watchdog: BUG: soft lockup - CPU#2 stuck for 22s!
[ksoftirqd/2:22]
[ 133.599232] Kernel panic - not syncing: softlockup: hung tasks
[ 133.602275] CPU: 2 PID: 22 Comm: ksoftirqd/2 T
Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages] [and 2 more messages] [and 2 more messages]"):
> AFAICT, Ian's main concern was adding yet another dependency on external
> entity.
We could put the .deb repository on xenbits.
There remains the question
This run is configured for baseline tests only.
flight 75570 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-build
On Mon, Nov 05, 2018 at 04:58:35PM +0530, Rishi wrote:
> Alright, I got the serial console and following is the crash log. Thank you
> for pointing that out.
>
> [ 133.594852] watchdog: BUG: soft lockup - CPU#2 stuck for 22s!
> [ksoftirqd/2:22]
>
> [ 133.599232] Kernel panic - not syncing: soft
Yes, I'm running it in a HVM domU for development purpose.
On Mon, Nov 5, 2018 at 5:11 PM Wei Liu wrote:
> On Mon, Nov 05, 2018 at 04:58:35PM +0530, Rishi wrote:
> > Alright, I got the serial console and following is the crash log. Thank
> you
> > for pointing that out.
> >
> > [ 133.594852] wa
Hi,
On 02/11/2018 23:27, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
Currently a Stage-2 translation fault could happen:
1) MMIO emulation
2) When the page-tables is been updated using Break-Before-Make
^ have
3) Page not ma
Hi Stefano,
On 02/11/2018 23:44, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
With the recent changes, a P2M entry may be populated but may as not
valid. In some situation, it would be useful to know whether the entry
has been marked available to guest in order to perform a
On Mon, Nov 05, 2018 at 05:18:43PM +0530, Rishi wrote:
> Yes, I'm running it in a HVM domU for development purpose.
What is your exact setup?
Wei.
>
> On Mon, Nov 5, 2018 at 5:11 PM Wei Liu wrote:
>
> > On Mon, Nov 05, 2018 at 04:58:35PM +0530, Rishi wrote:
> > > Alright, I got the serial con
I'm using a XenServer Host and XCP-NG on it as HVM. I used xencons=tty
console=ttyS0 on XCP-NG dom0 kernel line, to obtain serial console.
I'm working on to build a more recent dom0 kernel for improved support of
Ceph in XenServer/XCP-NG.
On Mon, Nov 5, 2018 at 5:28 PM Wei Liu wrote:
> On Mon,
I forgot to say: please don't top-post.
On Mon, Nov 05, 2018 at 06:00:10PM +0530, Rishi wrote:
> I'm using a XenServer Host and XCP-NG on it as HVM. I used xencons=tty
> console=ttyS0 on XCP-NG dom0 kernel line, to obtain serial console.
> I'm working on to build a more recent dom0 kernel for impr
>>> On 31.10.18 at 13:43, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/viridian/synic.c
> @@ -0,0 +1,225 @@
> +/**
> *
> + * synic.c
> + *
> + * An implementation of some interrupt related Viridian enlightenments.
> + * See
>>> On 31.10.18 at 13:43, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/viridian/time.c
> @@ -0,0 +1,245 @@
> +/**
> *
> + * time.c
> + *
> + * An implementation of some time related Viridian enlightenments.
> + * See Micros
Yes, I'm taking out patches from 4.4 and actually do have a working 4.9
kernel along with blktap. Tested networking and disk IO in it.
There are roughly 415 patches to 4.4 out of which some ~210+ are already
applied in 4.9 and ~220+ are already applied in 4.14. I dont have numbers
for 4.19 yet.
E
>>> On 31.10.18 at 13:43, wrote:
> --- a/xen/include/asm-x86/hvm/viridian.h
> +++ b/xen/include/asm-x86/hvm/viridian.h
> @@ -92,7 +92,7 @@ struct viridian_vcpu
> {
> struct {
> union viridian_page_msr msr;
> -void *va;
> +void *ptr;
Why void rather than the actual t
On Mon, Nov 5, 2018 at 6:29 PM Rishi <2rushike...@gmail.com> wrote:
> Yes, I'm taking out patches from 4.4 and actually do have a working 4.9
> kernel along with blktap. Tested networking and disk IO in it.
>
> There are roughly 415 patches to 4.4 out of which some ~210+ are already
> applied in 4
>>> On 31.10.18 at 13:43, wrote:
> The 'vp_assist' page is currently an example of a guest page which needs to
> be kept mapped throughout the life-time of a guest, but there are other
> such examples in the specifiction [1]. This patch therefore introduces a
> generic 'viridian_page' type and con
Any changes required for this to go in?
Regards,
Alex
On 29.10.2018 17:53, Alexandru Stefan ISAILA wrote:
> Signed-off-by: Alexandru Isaila
> Acked-by: Tamas K Lengyel
> Acked-by: Jan Beulich
>
> ---
> Changes since V1:
> - Made style corrections suggested by Jan.
> ---
> xen/arch/x86
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 November 2018 13:06
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; Ian Jackson ; xen-devel
>
> Subject: Re: [PATCH v2 9/9] viridian: introduce struct viridian_page
>
> >>> On 31.10.18 at 13:43, wrote:
>
There is no need for struct vcpu to live below the 4G boundary for PV guests,
or for HVM vcpus using HAP.
Plumb struct domain into alloc_vcpu_struct() so the x86 version can query the
domain's type and paging settings.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: George Dun
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 November 2018 13:00
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; xen-devel
> Subject: Re: [PATCH v2 7/9] viridian: define type for the 'virtual VP
> assist page'
>
> >>> On 31.10.18 at 13:43, wrote:
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 November 2018 12:51
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; xen-devel
> Subject: Re: [PATCH v2 5/9] viridian: separate interrupt related
> enlightenment implementations...
>
> >>> On 31.10.18 at
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 November 2018 12:57
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; xen-devel
> Subject: Re: [PATCH v2 6/9] viridian: separate time related enlightenment
> implementations...
>
> >>> On 31.10.18 at 13:43,
flight 129417 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129417/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs.
125898
test-amd64-
>>> On 05.11.18 at 14:17, wrote:
> There is no need for struct vcpu to live below the 4G boundary for PV guests,
> or for HVM vcpus using HAP.
>
> Plumb struct domain into alloc_vcpu_struct() so the x86 version can query the
> domain's type and paging settings.
>
> Signed-off-by: Andrew Cooper
>>> On 05.11.18 at 14:26, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 05 November 2018 12:57
>>
>> >>> On 31.10.18 at 13:43, wrote:
>> > --- /dev/null
>> > +++ b/xen/arch/x86/hvm/viridian/time.c
>> > @@ -0,0 +1,245 @@
>> >
>> +/
On Mon, Nov 05, 2018 at 01:17:30PM +, Andrew Cooper wrote:
> There is no need for struct vcpu to live below the 4G boundary for PV guests,
> or for HVM vcpus using HAP.
>
> Plumb struct domain into alloc_vcpu_struct() so the x86 version can query the
> domain's type and paging settings.
>
> S
Hi,
On 05/11/2018 13:17, Andrew Cooper wrote:
There is no need for struct vcpu to live below the 4G boundary for PV guests,
or for HVM vcpus using HAP.
Plumb struct domain into alloc_vcpu_struct() so the x86 version can query the
domain's type and paging settings.
Signed-off-by: Andrew Cooper
flight 129451 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129451/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 November 2018 13:37
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; xen-devel
> Subject: RE: [PATCH v2 6/9] viridian: separate time related enlightenment
> implementations...
>
> >>> On 05.11.18 at 14:26,
On 02/11/18 15:55, Wei Liu wrote:
> @@ -2078,6 +2092,7 @@ void activate_debugregs(const struct vcpu *curr)
> }
> }
>
> +#ifdef CONFIG_PV
> /*
> * Used by hypercalls and the emulator.
> * -ENODEV => #UD
> @@ -2193,6 +2208,7 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
> unsi
On 02/11/18 15:55, Wei Liu wrote:
> Going through toolstack code, they are used for PV guests only.
>
> Tighten their access to PV only. Return -EOPNOTSUPP if they are called
> on HVM guests. Rewrite the code in a pattern that makes DCE work.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
On 02/11/18 15:55, Wei Liu wrote:
> We want Xen to crash if we hit these paths when PV is disabled.
>
> For syscall, we provide stubs for {l,c}star_enter which end up calling
> panic. For sysenter, we initialise CS to 0 so that #GP can be raised.
>
> Signed-off-by: Wei Liu
> ---
> v3: rewrite
> -
On 02/11/18 15:55, Wei Liu wrote:
> @@ -553,8 +523,43 @@ ENTRY(dom_crash_sync_extable)
> jmp asm_domain_crash_synchronous /* Does not return */
> .popsection
>
> +/* --- CODE BELOW THIS LINE (MOSTLY) NOT GUEST RELATED --- */
> +
> +.text
> +
> +ALIGN
No need f
On 02/11/18 15:55, Wei Liu wrote:
> Skip building x86_64/compat/entry.S and put CONFIG_PV in
> x86_64/entry.S.
>
> Signed-off-by: Wei Liu
> ---
> v3:
> 1. make CR4_PV32_RESTORE expand to nothing when !PV
> 2. use unconditional jmp and add assertions
>
> v2: new
> ---
> xen/arch/x86/x86_64/Makefil
>>> On 05.11.18 at 14:54, wrote:
> Where typedefs are actually given in the spec I prefer to lift them, even
> though they do not adhere to our coding style. I could but a document in the
> viridian subdirectory stating this if you'd like.
I don't think that's worth it.
Jan
>>> On 02.11.18 at 16:55, wrote:
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -298,8 +298,21 @@ static unsigned int write_stub_trampoline(
> }
>
> DEFINE_PER_CPU(struct stubs, stubs);
> +
> +#ifdef CONFIG_PV
> void lstar_enter(void);
> void cstar_enter(void);
>>> On 02.11.18 at 16:55, wrote:
> Update text. Change "guest" to "domain" where appropriate because
> "guest" doesn't include Domain 0.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
htt
>>> On 05.11.18 at 12:16, wrote:
> 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
>>> On 05.11.18 at 12:16, wrote:
> 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
>>> On 05.11.18 at 12:16, wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -1075,12 +1075,25 @@ struct xen_sysctl_set_parameter {
> * - Default_*: Default set of features a PV or HVM guest can use. This is
> * the security supported set.
> *
>>> On 05.11.18 at 12:16, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1528,6 +1528,38 @@ long arch_do_domctl(
> recalculate_cpuid_policy(d);
> break;
>
> +case XEN_DOMCTL_get_cpu_policy:
> +/* Process the CPUID leaves. */
> +if (
On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
> >>> On 02.11.18 at 16:55, wrote:
> > --- a/xen/arch/x86/x86_64/traps.c
> > +++ b/xen/arch/x86/x86_64/traps.c
> > @@ -298,8 +298,21 @@ static unsigned int write_stub_trampoline(
> > }
> >
> > DEFINE_PER_CPU(struct stubs, stubs);
> >
On 05/11/18 15:48, Wei Liu wrote:
> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
> On 02.11.18 at 16:55, wrote:
>>> --- a/xen/arch/x86/x86_64/traps.c
>>> +++ b/xen/arch/x86/x86_64/traps.c
>>> @@ -298,8 +298,21 @@ static unsigned int write_stub_trampoline(
>>> }
>>>
>>> DEFI
On Mon, Nov 05, 2018 at 03:49:40PM +, Andrew Cooper wrote:
> On 05/11/18 15:48, Wei Liu wrote:
> > On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
> > On 02.11.18 at 16:55, wrote:
> >>> --- a/xen/arch/x86/x86_64/traps.c
> >>> +++ b/xen/arch/x86/x86_64/traps.c
> >>> @@ -298,8 +
On Mon, Nov 05, 2018 at 11:16:40AM +, Andrew Cooper wrote:
> 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.
>
> Introduce a new flask access vector
On Mon, Nov 05, 2018 at 11:16:39AM +, Andrew Cooper wrote:
> From: Sergey Dyasli
>
> Provide a SYSCTL for the toolstack to obtain complete system CPUID and MSR
> policy information.
>
> For the flask side of things, this subop is closely related to
> {phys,cputopo,numa}info, so shares the ph
Paul Durrant writes:
>> -Original Message-
>> From: Kevin Wolf [mailto:kw...@redhat.com]
>> Sent: 02 November 2018 11:04
>> To: Tim Smith
>> Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; qemu-
>> bl...@nongnu.org; Anthony Perard ; Paul Durrant
>> ; Stefano Stabellini ;
>> Ma
>>> On 05.11.18 at 16:49, wrote:
> On 05/11/18 15:48, Wei Liu wrote:
>> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
>> On 02.11.18 at 16:55, wrote:
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -298,8 +298,21 @@ static unsigned int writ
On 10/29/2018 03:53 PM, Alexandru Stefan ISAILA wrote:
> Signed-off-by: Alexandru Isaila
> Acked-by: Tamas K Lengyel
> Acked-by: Jan Beulich
>
> ---
> Changes since V1:
> - Made style corrections suggested by Jan.
> ---
> xen/arch/x86/hvm/hvm.c| 3 ++-
> xen/arch/x86/mm/mem_s
> -Original Message-
> From: Markus Armbruster [mailto:arm...@redhat.com]
> Sent: 05 November 2018 15:58
> To: Paul Durrant
> Cc: 'Kevin Wolf' ; Tim Smith ;
> Stefano Stabellini ; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Max Reitz ; Anthony Perard
> ; xen-devel@lists.xenproject.org
* s/unsigned char/uint8_t/ for clarity
* Drop redundant return at the end of a void function
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
Noticed while reviewing Wei's CONFIG_PV series.
---
xen/arch/x86/traps.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
d
On Mon, Nov 05, 2018 at 04:19:05PM +, Andrew Cooper wrote:
> * s/unsigned char/uint8_t/ for clarity
> * Drop redundant return at the end of a void function
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-dev
Andrew Cooper writes ("[Xen-devel] MSR load lists on Harpertown"):
> I realise this is an old CPU, but I've I've encountered a weird failure
> on it.
...
> However, given this behaviour, I can't think of any way to context
> switch NX properly, and leave 64bit guests in a working state.
>
> Do you
On 11/5/18 6:17 PM, George Dunlap wrote:
> On 10/29/2018 03:53 PM, Alexandru Stefan ISAILA wrote:
>> Signed-off-by: Alexandru Isaila
>> Acked-by: Tamas K Lengyel
>> Acked-by: Jan Beulich
>>
>> ---
>> Changes since V1:
>> - Made style corrections suggested by Jan.
>> ---
>> xen/arch/x86/hvm
>>> On 05.11.18 at 17:17, wrote:
> On 10/29/2018 03:53 PM, Alexandru Stefan ISAILA wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -448,7 +448,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m,
>> unsigned long gfn_l,
>> /* Try to unshare. If we fail, com
>>> On 05.11.18 at 17:23, wrote:
> On Mon, Nov 05, 2018 at 04:19:05PM +, Andrew Cooper wrote:
>> * s/unsigned char/uint8_t/ for clarity
>> * Drop redundant return at the end of a void function
>>
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Wei Liu
Acked-by: Jan Beulich
On 11/05/2018 04:28 PM, Jan Beulich wrote:
On 05.11.18 at 17:17, wrote:
>> On 10/29/2018 03:53 PM, Alexandru Stefan ISAILA wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -448,7 +448,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m,
>>> unsigned long gfn_
On 05/11/18 16:25, Ian Jackson wrote:
> Andrew Cooper writes ("[Xen-devel] MSR load lists on Harpertown"):
>> I realise this is an old CPU, but I've I've encountered a weird failure
>> on it.
> ...
>> However, given this behaviour, I can't think of any way to context
>> switch NX properly, and leav
flight 129426 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129426/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail pass in 129400
Tests which did not succeed, but
>>> On 30.10.18 at 16:41, wrote:
> When switching the memory decoding bit in the command register the
> rest of the changes where dropped, leading to only the memory decoding
> bit being updated.
>
> Fix this by unconditionally writing the guest-requested command except
> for the memory decoding
>>> On 30.10.18 at 16:41, wrote:
> BAR map/unmap is a long running operation that needs to be preempted
> in order to avoid overrunning the assigned vCPU time (or even
> triggering the watchdog).
>
> Current logic for this preemption is wrong, and won't work at all for
> AMD since only Intel make
>>> On 30.10.18 at 16:41, wrote:
> Make sure the MSIX MMIO regions don't have p2m entries setup, so that
> accesses to them trap into the hypervisor and can be handled by vpci.
>
> This is a side-effect of commit 042678762 for PVH Dom0, which added
> mappings for all the reserved regions into the
On Mon, Nov 05, 2018 at 02:33:23PM +, Andrew Cooper wrote:
> On 02/11/18 15:55, Wei Liu wrote:
> > Skip building x86_64/compat/entry.S and put CONFIG_PV in
> > x86_64/entry.S.
> >
> > Signed-off-by: Wei Liu
> > ---
> > v3:
> > 1. make CR4_PV32_RESTORE expand to nothing when !PV
> > 2. use unco
On 05/11/18 17:08, Wei Liu wrote:
> On Mon, Nov 05, 2018 at 02:33:23PM +, Andrew Cooper wrote:
>> On 02/11/18 15:55, Wei Liu wrote:
>>> Skip building x86_64/compat/entry.S and put CONFIG_PV in
>>> x86_64/entry.S.
>>>
>>> Signed-off-by: Wei Liu
>>> ---
>>> v3:
>>> 1. make CR4_PV32_RESTORE expan
On Mon, 5 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 02/11/2018 23:44, Stefano Stabellini wrote:
> > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > With the recent changes, a P2M entry may be populated but may as not
> > > valid. In some situation, it would be useful to know whether the ent
1 - 100 of 139 matches
Mail list logo
