This run is configured for baseline tests only.
flight 75573 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75573/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 6 libvirt-buildfail like 75565
On 2018-11-06 03:14, Andrew Morton wrote:
On Mon, 05 Nov 2018 15:12:27 +0530 Arun KS
wrote:
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
flight 129438 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 128921
Tests which are
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-shadow
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
flight 129434 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129434/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 129353
build-i386-pvops
Hi Stefano,
On 11/5/18 9:10 PM, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
Set/Way operations are used to perform maintenance on a given cache.
At the moment, Set/Way operations are not trapped and therefore a guest
OS will directly act on the local cache. However, a
Hi Stefano,
On 11/5/18 9:35 PM, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using
Hi Stefano,
On 11/5/18 7:47 PM, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
A follow-up patch will require to emulate some accesses to some
co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes
to the virtual memory control registers will be trapped
flight 129473 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129473/
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
flight 129428 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
On Mon, 05 Nov 2018 15:12:27 +0530 Arun KS wrote:
> 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
On Mon, 8 Oct 2018, Julien Grall wrote:
> At the moment, the implementation of Set/Way operations will go through
> all the entries of the guest P2M and flush them. However, this is very
> expensive and may render unusable a guest OS using them.
>
> For instance, Linux 32-bit will use Set/Way
flight 129446 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129446/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd d843b0f4abd4782caf9abffd5f7628b51d65d541
baseline version:
freebsd
On Mon, 8 Oct 2018, Julien Grall wrote:
> Set/Way operations are used to perform maintenance on a given cache.
> At the moment, Set/Way operations are not trapped and therefore a guest
> OS will directly act on the local cache. However, a vCPU may migrate to
> another pCPU in the middle of the
flight 129454 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129454/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e40f8efb8b06e023689120452e7ed5db199363de
baseline version:
ovmf
> 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
> 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.
Acked-by: Daniel De Graaf
On Mon, 8 Oct 2018, Julien Grall wrote:
> A follow-up patch will require to emulate some accesses to system
> registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes to the
> virtual memory control registers will be trapped to the hypervisor.
>
> This patch adds the infrastructure to
On 05/11/18 17:52, Roger Pau Monné wrote:
> On Mon, Nov 05, 2018 at 11:16:40AM +, Andrew Cooper wrote:
>> diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
>> index 95ed853..2c41031 100644
>> --- a/tools/misc/xen-cpuid.c
>> +++ b/tools/misc/xen-cpuid.c
>> @@ -3,6 +3,8 @@
>>
On Fri, Nov 02, 2018 at 07:33:28PM +, Wei Liu 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
> ---
> Cc: Jan
On Mon, 8 Oct 2018, Julien Grall wrote:
> A follow-up patch will require to emulate some accesses to some
> co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes
> to the virtual memory control registers will be trapped to the hypervisor.
>
> This patch adds the
flight 129467 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129467/
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
In "build: add autoconf to replace custom checks in tools/check"
--enable-githttp was introduced. But we missed this comment where it
was advertised.
Signed-off-by: Ian Jackson
CC: Paul Durrant
CC: Wei Liu
---
config/Tools.mk.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This shell fragment lacked set -e. So, eg if the download failed a
broken ipxe.tar.gz would be left behind.
Signed-off-by: Ian Jackson
CC: Paul Durrant
CC: Wei Liu
---
tools/firmware/etherboot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In "build: add autoconf to replace custom checks in tools/check"
--enable-githttp was introduced. But that had the effect of
uncondtionally setting GIT_HTTP from the configure variable.
But the env var is advertised in some places as the way to specify
this behaviour, and overriding it is just
xen.git/tools/firmware/etherboot/Makefile tries to get a tarball from
xen-extfiles first and if that fails, tries cloning from ipxe.org.
ipxe.org is sometimes down (or half-down) and when that happens
without a tarball the build breaks and is hard to fix.
We would like, therefore, to ensure that
On Mon, Nov 05, 2018 at 04:17:56PM +0200, Alexandru Vasile wrote:
> On Mon, Nov 05, 2018 at 12:57 PM, Wei Liu wrote:
> > 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)
On 11/05/2018 06:07 PM, George Dunlap wrote:
> docs/qemu-deprivilege.txt had some basic instructions for using
> dm_restrict, but it was incomplete, misleading, and stale.
>
> Update the docs in a number of ways.
>
> First, separate user-facing documentation and technical description
> into
QEMU running under Xen doesn't need mount or IPC functionality.
Create and enter separate namespaces for each of these before
executing QEMU, so that in the event that other restrictions fail, the
process won't be able to even name system mount points or exsting
non-file-based IPC descriptors to
docs/qemu-deprivilege.txt had some basic instructions for using
dm_restrict, but it was incomplete, misleading, and stale.
Update the docs in a number of ways.
First, separate user-facing documentation and technical description
into docs/features and docs/design, respectively.
In the feature
Limit the ability of a potentially compromised QEMU to consume system
resources. Key limits:
- RLIMIT_FSIZE (file size): 256KiB
- RLIMIT_NPROC (after uid changes to a unique uid)
Probably unnecessary limits but why not:
- RLIMIT_CORE: 0
- RLIMIT_MSGQUEUE: 0
- RLIMIT_LOCKS: 0
-
When dm_restrict is enabled, ask QEMU to chroot into an empty directory.
* Create /var/run/qemu/root-domid (deleting the old one if it's there)
* Pass the -chroot option to QEMU
Rather than running `rm -rf` on the directory before creating it
(since there is no library function to do this),
Signed-off-by: George Dunlap
---
Changes since v3:
- Moved from the qemu-depriv doc patches.
- Reword to include the possibility of having a non-dom0 "devicemodel"
domain which may want to be protected
- Specify `Linux dom0` as the currently-tech-supported window
CC: Ian Jackson
CC: Wei Liu
Add a tool to check whether the various process-level deprivileging
operations have actually taken place on the process.
The tool takes a domname or domid, and returns success or failure.
Signed-off-by: George Dunlap
---
Changes since v3:
- Use xen-qemuuser-range-base's gid rather than
On Mon, 5 Nov 2018, Julien Grall wrote:
> 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
> >
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 05/11/18 17:38, Wei Liu wrote:
> A build breakage is discovered by a non-debug build. Debug build
> worked because the ASSERT made the compiler eliminate the rest of the
> functions.
>
> Currently they are PV only. There are comments alluding to possible
> future HVM support but we can cross
A build breakage is discovered by a non-debug build. Debug build
worked because the ASSERT made the compiler eliminate the rest of the
functions.
Currently they are PV only. There are comments alluding to possible
future HVM support but we can cross the bride when we get there.
Signed-off-by:
Hi Stefano,
On 05/11/2018 17:31, Stefano Stabellini wrote:
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
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
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
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
>>> 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
>>> 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
>>> 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
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,
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
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
>>> 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 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,
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.
>> ---
>>
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
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
* 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(-)
> -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
> ;
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 ++-
>
>>> 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
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 ;
>>
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
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 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 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(
>>> }
>>>
>>>
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 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 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:
> 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
>>> 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
>>> 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
>>> 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 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 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
> ---
>
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
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:
> @@ -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,
>
> -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
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
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
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.
>
>
>>> 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 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
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
> -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
> -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
> -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:
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
> -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:
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.
> ---
>
>>> 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
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
>>> 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
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.
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
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
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
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]
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:
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
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
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
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
1 - 100 of 131 matches
Mail list logo
