This run is configured for baseline tests only.
flight 66895 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66895/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64 3 host-install(3) bro
flight 99913 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99913/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
flight 99911 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99911/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 99906
Regressions which ar
flight 66894 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66894/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-squeeze-netboot-pygrub 3 host-install(3) broken blocked
in 66838
test-
Denverton is an Intel Atom based micro server which shares the same
Goldmont architecture as Broxton. The available C-states on
Denverton is a subset of Broxton with only C1, C1e, and C6.
Signed-off-by: Jacob Pan
Signed-off-by: Len Brown
Signed-off-by: Rafael J. Wysocki
[Linux commit: 0080d65b7
... as per the June 2016 edition of the SDM.
Also remove a couple of dead break statements as well as unused
*MSR_PM_LASTBRANCH* #define-s.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -61,14 +61,14 @@
#define GET_HW_RES_IN_NS(msr, val)
>>> On 03.08.16 at 08:54, wrote:
> On 08/02/16 08:46, Jan Beulich wrote:
>> >>> On 18.07.16 at 02:29, wrote:
>> > (4) Because the reserved area is now used by Xen hypervisor, it
>> > should not be accessible by Dom0 any more. Therefore, if a host
>> > pmem device is recorded by Xen hyp
>>> On 03.08.16 at 03:32, wrote:
>> On 25/07/16 07:09, Kang, Luwei wrote:
>> First of all - please don't top post.
>>
>> > What about remove the dependency between AVX2 and AVX512F
>> >> ( AVX2:
>> [AVX512F], ) ?
>>
>> Yes, that's what I think we want, but we need And
>>> On 02.08.16 at 20:43, wrote:
> On Tue, 2 Aug 2016, Jan Beulich wrote:
>> >>> On 02.08.16 at 16:59, wrote:
>> > On 02/08/16 15:54, Jan Beulich wrote:
>> > On 02.08.16 at 16:26, wrote:
>> >>> On 02/08/16 15:17, Jan Beulich wrote:
>> Well, I find it quite odd for hypercall argument cou
>>> On 02.08.16 at 21:02, wrote:
>> > Can you try
>> >
>> > ((void *)(md) + (m)->desc_size - 1) <
>> > (m)->map_end; \
>> >
>> > instead?
>
> with the 'baseline' as referenced + a patched kernel
>
> > Can you try
> >((void *)(m
On 03/08/16 09:36, Jan Beulich wrote:
> Denverton is an Intel Atom based micro server which shares the same
> Goldmont architecture as Broxton. The available C-states on
> Denverton is a subset of Broxton with only C1, C1e, and C6.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Len Brown
> Signed-
I would suggest changing the title to
libxl: return any serial tty path in libxl_console_get_tty
On Wed, Aug 03, 2016 at 09:27:19AM +0800, Bob Liu wrote:
> When specifying a serial list in domain config, users of
> libxl_console_get_tty cannot get the tty path of a second specified pty
> seri
On Tue, Aug 02, 2016 at 06:28:37PM +0100, Andrew Cooper wrote:
> On 02/08/16 18:25, Juergen Gross wrote:
> > Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size
> > in kb requires 64 bit variable") introduced a bug: abs() shouldn't
> > be called with an int64_t argument. llabs() is
On Tue, Aug 02, 2016 at 06:10:45PM +0200, Juergen Gross wrote:
> In order to prepare starting a xenstore domain split out the starting
> of the xenstore daemon from the xencommons script into a dedicated
> launch-xenstore script.
>
> A rerun of autogen.sh is required.
>
> Signed-off-by: Juergen G
On 03/08/16 09:38, Jan Beulich wrote:
> ... as per the June 2016 edition of the SDM.
>
> Also remove a couple of dead break statements as well as unused
> *MSR_PM_LASTBRANCH* #define-s.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-de
On 03/08/16 11:13, Wei Liu wrote:
> On Tue, Aug 02, 2016 at 06:28:37PM +0100, Andrew Cooper wrote:
>> On 02/08/16 18:25, Juergen Gross wrote:
>>> Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size
>>> in kb requires 64 bit variable") introduced a bug: abs() shouldn't
>>> be called
>>> On 02.08.16 at 21:25, wrote:
> On 20/06/16 16:19, Jan Beulich wrote:
> On 20.06.16 at 16:20, wrote:
>>> On 15/06/16 11:28, Jan Beulich wrote:
--- a/xen/arch/x86/i8259.c
+++ b/xen/arch/x86/i8259.c
@@ -359,12 +359,7 @@ void __init init_IRQ(void)
apic_intr_ini
On 08/03/16 02:45, Jan Beulich wrote:
> >>> On 03.08.16 at 08:54, wrote:
> > On 08/02/16 08:46, Jan Beulich wrote:
> >> >>> On 18.07.16 at 02:29, wrote:
> >> > (4) Because the reserved area is now used by Xen hypervisor, it
> >> > should not be accessible by Dom0 any more. Therefore, if a h
Cc Anthony and Stefano
On Tue, Aug 02, 2016 at 11:58:05AM +0200, Olaf Hering wrote:
> Doing a live migration of a HVM domU from staging-4.5 with its included
> qemu-xen to staging-4.7 with qemu-xen from qemu.org (either master or
> 2.6.0) fails:
>
> # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-cle
>>> On 02.08.16 at 21:08, wrote:
> On 04/07/16 16:53, Jan Beulich wrote:
> On 04.07.16 at 17:39, wrote:
>>> On 20/06/16 16:20, Jan Beulich wrote:
>>> On 20.06.16 at 16:32, wrote:
> On 15/06/16 11:28, Jan Beulich wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>>> On 03.08.16 at 11:37, wrote:
> On 08/03/16 02:45, Jan Beulich wrote:
>> >>> On 03.08.16 at 08:54, wrote:
>> > On 08/02/16 08:46, Jan Beulich wrote:
>> >> >>> On 18.07.16 at 02:29, wrote:
>> >> > (4) Because the reserved area is now used by Xen hypervisor, it
>> >> > should not be acces
On Wed, Aug 03, 2016 at 11:27:04AM +0200, Juergen Gross wrote:
> On 03/08/16 11:13, Wei Liu wrote:
> > On Tue, Aug 02, 2016 at 06:28:37PM +0100, Andrew Cooper wrote:
> >> On 02/08/16 18:25, Juergen Gross wrote:
> >>> Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size
> >>> in kb r
Shifting into the sign bit of an integer is undefined behaviour.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
I was experimenting with -fsanitise=undefined and this bit failed to compile,
as the initialisation became a non-constant expression.
---
xen/arch/x86/x86_64/mmconfig-shared.c | 6
flight 99915 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99915/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf deaacda3b2740477733564066eb69d5c94b41bba
baseline version:
ovmf 4884e81b5d0da1bcc05361d
On 08/03/16 03:47, Jan Beulich wrote:
> >>> On 03.08.16 at 11:37, wrote:
> > On 08/03/16 02:45, Jan Beulich wrote:
> >> >>> On 03.08.16 at 08:54, wrote:
> >> > On 08/02/16 08:46, Jan Beulich wrote:
> >> >> >>> On 18.07.16 at 02:29, wrote:
> >> >> > (4) Because the reserved area is now used by X
On 26/07/16 17:21, Dario Faggioli wrote:
> On Mon, 2016-07-25 at 17:12 +0100, Anshul Makkar wrote:
>> It introduces context-switch rate-limiting. The patch enables the VM
>> to batch
>> its work and prevents the system from spending most of its time in
>> context
>> switches because of a VM that is
>>> On 03.08.16 at 12:08, wrote:
> On 08/03/16 03:47, Jan Beulich wrote:
>> >>> On 03.08.16 at 11:37, wrote:
>> > By using the file name, e.g. if I specify vnvdimm = [ 'file=/mnt/dax/foo' ]
>> > in a domain config file, SPA occupied by /mnt/dax/foo are mapped to
>> > the domain. If the same file
>>> On 03.08.16 at 11:51, wrote:
> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
> @@ -182,10 +182,10 @@ static const char __init *pci_mmcfg_nvidia_mcp55(void)
> int bus, i;
>
> static const u32 extcfg_regnum = 0x90;
> -static const
Wei Liu writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"):
> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
> > > A DMOP is defined to never put at risk the stability or security of
> > > the whole system, nor of the domain which calls DMOP. However, a DMOP
> > >
flight 99918 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99918/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd645 coverity-buildfail REGR. vs. 96924
version tar
This run is configured for baseline tests only.
flight 66891 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66891/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-x
Hi Jan,
On 03/08/16 09:53, Jan Beulich wrote:
On 02.08.16 at 20:43, wrote:
On Tue, 2 Aug 2016, Jan Beulich wrote:
On 02.08.16 at 16:59, wrote:
On 02/08/16 15:54, Jan Beulich wrote:
On 02.08.16 at 16:26, wrote:
On 02/08/16 15:17, Jan Beulich wrote:
Well, I find it quite odd for hypercall
On 03/08/16 11:24, Jan Beulich wrote:
On 03.08.16 at 11:51, wrote:
>> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
>> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
>> @@ -182,10 +182,10 @@ static const char __init *pci_mmcfg_nvidia_mcp55(void)
>> int bus, i;
>>
>> static const u32 ex
On 24/06/16 11:28, Jan Beulich wrote:
> ... as a means to replace all HVMOP_* which a domain can't issue on
> itself (i.e. intended for use by only the control domain or device
> model).
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
Jan,
Could you post this branch to a git repo somewhe
On 27/07/16 04:09, Dario Faggioli wrote:
> In fact, when not finding a suitable runqueue where to
> place a vCPU, and hence using a fallback, we either:
> - don't issue any trace record (while we should, at
>least, output the chosen pcpu),
> - risk underruning when accessing the runqueues
>
This run is configured for baseline tests only.
flight 66896 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66896/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64 3 host-install(3) bro
This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.8 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a fixed
Hi Tamas,
On 02/08/16 23:47, Tamas K Lengyel wrote:
On Tue, Aug 2, 2016 at 4:05 PM, Julien Grall wrote:
On 02/08/2016 22:34, Tamas K Lengyel wrote:
On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall wrote:
On 02/08/2016 19:53, Tamas K Lengyel wrote:
Well, the data abort can only be a permission
On 03/08/16 11:16, George Dunlap wrote:
On 26/07/16 17:21, Dario Faggioli wrote:
On Mon, 2016-07-25 at 17:12 +0100, Anshul Makkar wrote:
It introduces context-switch rate-limiting. The patch enables the VM
The subject, which will become the "title" of the commit, is way too
long. That must be
>>> On 03.08.16 at 13:06, wrote:
> On 24/06/16 11:28, Jan Beulich wrote:
>> ... as a means to replace all HVMOP_* which a domain can't issue on
>> itself (i.e. intended for use by only the control domain or device
>> model).
>>
>> Signed-off-by: Jan Beulich
>> Reviewed-by: Wei Liu
>
> Could yo
On 02/08/16 17:08, Andrew Cooper wrote:
On 02/08/16 08:34, Julien Grall wrote:
Hi Andrew,
On 02/08/2016 00:14, Andrew Cooper wrote:
On 01/08/2016 19:15, Julien Grall wrote:
On 01/08/16 18:10, Sergej Proskurin wrote:
Hello all,
Hello Sergej,
The following patch series can be found on G
On Thu, Jul 28, 2016 at 6:29 PM, Dario Faggioli
wrote:
> On Mon, 2016-07-18 at 16:09 +0200, Juergen Gross wrote:
>> Acked-by: Juergen Gross
>>
>> for this patch then.
>>
> George,
>
> Ping about this series.
Dario,
Somehow I can only find patch 1/2 in either Google or my Citrix
mailbox. What's
Hi Wei,
On 03/08/16 12:33, Wei Liu wrote:
=== ARM ===
* ITS emulation (Dom0 only)
- Andre Przywara
* Xen ARM DomU ACPI support
- Shannon Zhao
* Alternative patching support
- Julien Grall
* Altp2m for ARM
- Sergej Proskurin
Another big item to track for ARM:
P2M rework to
On Tue, Aug 02, 2016 at 05:35:08PM -0700, Stefano Stabellini wrote:
> Hi all,
>
> This is the design document of the PV Calls protocol. You can find
> prototypes of the Linux frontend and backend drivers here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-4
>
> To
On 03/08/16 12:53, Julien Grall wrote:
>
>
> On 02/08/16 17:08, Andrew Cooper wrote:
>> On 02/08/16 08:34, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 02/08/2016 00:14, Andrew Cooper wrote:
On 01/08/2016 19:15, Julien Grall wrote:
> On 01/08/16 18:10, Sergej Proskurin wrote:
>>
>
>>> On 03.08.16 at 12:29, wrote:
> Wei Liu writes ("Re: Device model operation hypercall (DMOP, re qemu
> depriv)"):
>> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
>> > > A DMOP is defined to never put at risk the stability or security of
>> > > the whole system, nor of the domai
On Wed, Aug 03, 2016 at 12:56:14PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 03/08/16 12:33, Wei Liu wrote:
> >=== ARM ===
> >
> >* ITS emulation (Dom0 only)
> > - Andre Przywara
> >
> >* Xen ARM DomU ACPI support
> > - Shannon Zhao
> >
> >* Alternative patching support
> > - Julien Gra
On 03/08/16 13:00, Andrew Cooper wrote:
On 03/08/16 12:53, Julien Grall wrote:
On 02/08/16 17:08, Andrew Cooper wrote:
On 02/08/16 08:34, Julien Grall wrote:
Hi Andrew,
On 02/08/2016 00:14, Andrew Cooper wrote:
On 01/08/2016 19:15, Julien Grall wrote:
On 01/08/16 18:10, Sergej Proskurin w
On 03/08/16 13:03, Wei Liu wrote:
On Wed, Aug 03, 2016 at 12:56:14PM +0100, Julien Grall wrote:
Hi Wei,
On 03/08/16 12:33, Wei Liu wrote:
=== ARM ===
* ITS emulation (Dom0 only)
- Andre Przywara
* Xen ARM DomU ACPI support
- Shannon Zhao
* Alternative patching support
- Julien Gr
On 03/08/16 13:13, Julien Grall wrote:
>
>
> On 03/08/16 13:00, Andrew Cooper wrote:
>> On 03/08/16 12:53, Julien Grall wrote:
>>> On 02/08/16 17:08, Andrew Cooper wrote:
On 02/08/16 08:34, Julien Grall wrote:
> Hi Andrew,
>
> On 02/08/2016 00:14, Andrew Cooper wrote:
>> On 01/
On Wed, 2016-08-03 at 12:43 +0100, anshul makkar wrote:
> On 03/08/16 11:16, George Dunlap wrote:
> >
> > Reviewed-by: George Dunlap
> >
> > If Anshul and Dario are happy, I can fix all those thing up on
> > commit.
> >
> Fine with me.
>
I'm ok too.
And with those changes, you can also add:
R
On 18/07/16 15:09, Juergen Gross wrote:
> On 18/07/16 16:03, Dario Faggioli wrote:
>> On Fri, 2016-07-15 at 16:23 +0200, Dario Faggioli wrote:
>>> On Fri, 2016-07-15 at 14:52 +0200, Juergen Gross wrote:
On 15/07/16 13:52, Dario Faggioli wrote:
> Therefore, I still think this patch is corre
On Wed, Aug 03, 2016 at 10:41:25AM +0100, Wei Liu wrote:
> Cc Anthony and Stefano
>
> On Tue, Aug 02, 2016 at 11:58:05AM +0200, Olaf Hering wrote:
> > Doing a live migration of a HVM domU from staging-4.5 with its included
> > qemu-xen to staging-4.7 with qemu-xen from qemu.org (either master or
>
On 08/03/2016 02:18 PM, Andrew Cooper wrote:
> On 03/08/16 13:13, Julien Grall wrote:
>>
>> On 03/08/16 13:00, Andrew Cooper wrote:
>>> On 03/08/16 12:53, Julien Grall wrote:
On 02/08/16 17:08, Andrew Cooper wrote:
> On 02/08/16 08:34, Julien Grall wrote:
>> Hi Andrew,
>>
>>
On Wed, Aug 03, Anthony PERARD wrote:
> Does the patch "xen: handle inbound migration of VMs without ioreq
> server pages" from Paul fix the issue?
> <1470042985-680-1-git-send-email-paul.durr...@citrix.com>
> https://lists.xen.org/archives/html/xen-devel/2016-08/msg00020.html
Would that help wit
1: calibrate TSC against platform timer
2: correctly honor late clearing of TSC related feature flags
3: support 32-bit wide ACPI PM timer
4: fold recurring code
5: group time stamps into a structure
6: relax barriers
Signed-off-by: Jan Beulich
---
v2: Only patch 1 changed (see there) and a new 6
... instead of unconditionally against the PIT. This allows for local
and master system times to remain in better sync (which matters even
when, on any modern system, the master time is really used only during
secondary CPU bringup, as the error between the two is in fact
noticable in cross-CPU NOW
As such clearing of flags may have an impact on the selected rendezvous
function, handle such in a central place.
But don't allow such feature flags to be cleared during CPU hotplug:
Platform and local system times may have diverged significantly by
then, potentially causing noticably (even if onl
I have no idea why we didn't do so from the beginning.
Signed-off-by: Jan Beulich
Tested-by: Dario Faggioli
Tested-by: Joao Martins
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -481,22 +481,23 @@ static int __init acpi_parse_fadt(struct
i
Common code between time_calibration_{std,tsc}_rendezvous() can better
live in a single place, eliminating the risk of adjusting one without
the other.
Signed-off-by: Jan Beulich
Tested-by: Dario Faggioli
Tested-by: Joao Martins
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/time.c
+++ b/xen/a
If that had been done from the beginning, mistakes like the one
corrected in commit b64438c7c1 ("x86/time: use correct (local) time
stamp in constant-TSC calibration fast path") would likely never have
happened.
Also add a few "const" to make more obvious when things aren't expected
to change.
Si
On x86 there's no need for full barriers in loops waiting for some
memory location to change. Nor do we need full barriers between two
reads and two writes - SMP ones fully suffice (and I actually think
they could in fact be dropped, since atomic_*() operations should
already provide enough orderin
From: Juergen Gross
When a Xenstore watch fires indicating a backend has to be removed
don't remove all backends for that domain with the specified device
index, but just the one which has the correct type.
The easiest way to achieve this is to use the already determined
xendev as parameter for
From: Juergen Gross
Instead of calling xen_be_register() for each supported backend type
for hvm and pv guests in their machine init functions use a common
function in order not to have to add new backends twice.
This at once fixes the error that hvm domains couldn't use the qusb
backend.
Signe
On 03/08/16 14:00, Jan Beulich wrote:
> ... instead of unconditionally against the PIT. This allows for local
> and master system times to remain in better sync (which matters even
> when, on any modern system, the master time is really used only during
> secondary CPU bringup, as the error between
flight 99919 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99919/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e80cb37ee7b507b6cfe4e4b0f23dc4c5cb2c1d5d
baseline version:
ovmf deaacda3b27404777335640
On Wed, Aug 03, 2016 at 02:52:54PM +0200, Olaf Hering wrote:
> On Wed, Aug 03, Anthony PERARD wrote:
>
> > Does the patch "xen: handle inbound migration of VMs without ioreq
> > server pages" from Paul fix the issue?
> > <1470042985-680-1-git-send-email-paul.durr...@citrix.com>
> > https://lists.x
On 03/08/16 14:04, Jan Beulich wrote:
> On x86 there's no need for full barriers in loops waiting for some
> memory location to change. Nor do we need full barriers between two
> reads and two writes - SMP ones fully suffice (and I actually think
> they could in fact be dropped, since atomic_*() op
On Wed, Aug 03, Anthony PERARD wrote:
> Haven't you try to create a guest with Xen 4.5 and qemu-xen-4.5, and
> then migrate to Xen 4.7 with QEMU-2.6/master?
In the end I tried xen-4.5/6/7/8 as source and their qemu-xen, and
migrated to qemu#master. All failed.
Olaf
signature.asc
Description: P
>>> On 03.08.16 at 15:11, wrote:
> On 03/08/16 14:04, Jan Beulich wrote:
>> On x86 there's no need for full barriers in loops waiting for some
>> memory location to change. Nor do we need full barriers between two
>> reads and two writes - SMP ones fully suffice (and I actually think
>> they could
Hi guys
I got around to take a closer look at the crash dump today.
tl;dr:
You were right, vmx_vmenter_helper is not called at all in the call stack.
The real reason behind the [] vmx_vmenter_helper+0x27e/0x30a
should be a failed
__vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0); in static void
vmx
On Wed, Aug 3, 2016, at 02:01 AM, Jan Beulich wrote:
> Thanks. Does the use of /mapbs really matter for booting? I was
> assuming it would be relevant only for shutdown/reboot?
It has no effect on boot. With or without the "/mapbs" it boots Xen OK.
Without the "/mapbs" the system used to crash on
Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
depriv)"):
> On 03.08.16 at 12:29, wrote:
> > I thought it useful to set out the DMOP proposal from first
> > principles, with clear motivation, discussion of not-chosen
> > alternatives, and of course with a clear statement
>>> On 02.08.16 at 15:55, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2283,7 +2283,11 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
> if ( !nestedhvm_vmswitch_in_progress(v) &&
> nestedhvm_vcpu_in_guestmode(v) )
> paging_update_nest
>>> On 03.08.16 at 15:24, wrote:
> I got around to take a closer look at the crash dump today.
>
> tl;dr:
> You were right, vmx_vmenter_helper is not called at all in the call stack.
> The real reason behind the []
> vmx_vmenter_helper+0x27e/0x30a
> should be a failed
> __vmwrite(HOST_CR0, v->a
>>> On 03.08.16 at 15:33, wrote:
> On Wed, Aug 3, 2016, at 02:01 AM, Jan Beulich wrote:
>> Thanks. Does the use of /mapbs really matter for booting? I was
>> assuming it would be relevant only for shutdown/reboot?
>
> It has no effect on boot. With or without the "/mapbs" it boots Xen OK.
As exp
The IO-APIC address has variable bits determined by the PCI-to-ISA
bridge (albeit for now we refrain from actually evaluating them, as
there's still implicit rather than explicit agreement on the IO-APIC
base address between qemu and the hypervisor), and the IO-APIC version
should be read from the
flight 99921 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99921/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 03/08/16 14:57, Jan Beulich wrote:
On 03.08.16 at 15:33, wrote:
>> On Wed, Aug 3, 2016, at 02:01 AM, Jan Beulich wrote:
>>> Thanks. Does the use of /mapbs really matter for booting? I was
>>> assuming it would be relevant only for shutdown/reboot?
>> It has no effect on boot. With or witho
On 03/08/16 14:58, Jan Beulich wrote:
> @@ -185,6 +188,14 @@ static void init_vm86_tss(void)
>
> static void apic_setup(void)
> {
> +/*
> + * This would the The Right Thing To Do (tm), if only qemu
> + * negotiated with Xen where the IO-APIC actually sits. Uncomment
> + * this c
Hello Sergej,
Please try to reply to all when answering on the ML. Otherwise the
answer may be delayed/lost.
On 03/08/16 13:45, Sergej Proskurin wrote:
The interesting part about #VE is that it allows to handle certain
violations (currently limited to EPT violations -- future
implementations
Hi Julien,
On 08/03/2016 04:08 PM, Julien Grall wrote:
> Hello Sergej,
>
> Please try to reply to all when answering on the ML. Otherwise the
> answer may be delayed/lost.
>
Right, sorry.
> On 03/08/16 13:45, Sergej Proskurin wrote:
>> The interesting part about #VE is that it allows to handle
On 03/08/16 15:16, Jan Beulich wrote:
On 03.08.16 at 15:37, wrote:
>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
>> depriv)"):
>>> On 03.08.16 at 12:29, wrote:
Does that mean that functionality exposed by all the prooposed HVMCTLs
is currently availab
>>> On 03.08.16 at 15:37, wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
> depriv)"):
>> On 03.08.16 at 12:29, wrote:
>> > Does that mean that functionality exposed by all the prooposed HVMCTLs
>> > is currently available to stubdoms ?
>>
>> That series only m
On 02/08/16 15:06, Paulina Szubarczyk wrote:
>
> +/**
> + * Copy memory from or to grant references. The information of each
> operations
> + * are contained in 'xengnttab_grant_copy_segment_t'. The @flag value
> indicate
> + * the direction of an operation (GNTCOPY_source_gref\GNTCOPY_dest_gref
On 01/08/16 17:52, Tamas K Lengyel wrote:
> The two functions monitor_traps and mem_access_send_req duplicate some of the
> same functionality. The mem_access_send_req however leaves a lot of the
> standard vm_event fields to be filled by other functions.
>
> Remove mem_access_send_req() completel
> > A #GP fault in firmware code. Not much we can do about, I'm afraid,
> > except for having you go with one of the mentioned workarounds
I tried
+ efi=no-rs
+ efi=attr=uc
on the Xen cmd line.
With efi=attr=uc, crashes on reboot with or without /mapbs
With efi=no-rs, reboots O
>>> On 18.07.16 at 11:51, wrote:
> --- a/xen/arch/x86/hypercall.c
> +++ b/xen/arch/x86/hypercall.c
> @@ -338,6 +338,34 @@ long pv_hypercall(struct cpu_user_regs *regs)
> return ret;
> }
>
> +void arch_do_multicall_call(struct mc_state *state)
> +{
> +if ( !is_pv_32bit_vcpu(current) )
>
>>> On 18.07.16 at 11:51, wrote:
> For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables", this
> removes the risk of accidentally updating only one of the tables.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
But having come here I still can't see why this can't be
On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich wrote:
On 02.08.16 at 17:49, wrote:
>> On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
>>> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
>>> > As this is for the construction of dom0, it would be better to take a
>
On 03/08/16 16:02, Jan Beulich wrote:
On 18.07.16 at 11:51, wrote:
>> --- a/xen/arch/x86/hypercall.c
>> +++ b/xen/arch/x86/hypercall.c
>> @@ -338,6 +338,34 @@ long pv_hypercall(struct cpu_user_regs *regs)
>> return ret;
>> }
>>
>> +void arch_do_multicall_call(struct mc_state *state)
>
>>> On 18.07.16 at 11:51, wrote:
> For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables" and
> (TODO - changeset) "x86/pv: Merge the pv hypercall tables", this removes the
> risk of accidentally updating only one of the tables.
Based on this argument perhaps hypercall and args tab
On 03/08/16 16:12, Jan Beulich wrote:
On 18.07.16 at 11:51, wrote:
>> For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables" and
>> (TODO - changeset) "x86/pv: Merge the pv hypercall tables", this removes the
>> risk of accidentally updating only one of the tables.
> Based on t
>>> On 18.07.16 at 11:51, wrote:
> The highest populated entry in each hypercall table is currently at index 49.
> There is no need to extend both to tables to 64 entries.
>
> Range check eax against the hypercall table array size, and use a
> BUILD_BUG_ON() to ensure that the hypercall tables do
On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap wrote:
> On 01/08/16 17:52, Tamas K Lengyel wrote:
>> The two functions monitor_traps and mem_access_send_req duplicate some of the
>> same functionality. The mem_access_send_req however leaves a lot of the
>> standard vm_event fields to be filled by o
>>> On 03.08.16 at 17:11, wrote:
> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich wrote:
> On 02.08.16 at 17:49, wrote:
>>> On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
> As this is for the construction
On 03/08/16 16:25, Jan Beulich wrote:
On 03.08.16 at 17:11, wrote:
>> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich wrote:
>> On 02.08.16 at 17:49, wrote:
On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wr
>>> On 03.08.16 at 17:15, wrote:
> On 03/08/16 16:12, Jan Beulich wrote:
> On 18.07.16 at 11:51, wrote:
>>> For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables" and
>>> (TODO - changeset) "x86/pv: Merge the pv hypercall tables", this removes the
>>> risk of accidentally updat
This run is configured for baseline tests only.
flight 66904 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66904/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e80cb37ee7b507b6cfe4e4b0f23dc4c5cb2c1d5d
baseline v
On 03/08/16 16:18, Tamas K Lengyel wrote:
> On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap
> wrote:
>> On 01/08/16 17:52, Tamas K Lengyel wrote:
>>> The two functions monitor_traps and mem_access_send_req duplicate some of
>>> the
>>> same functionality. The mem_access_send_req however leaves a l
1 - 100 of 200 matches
Mail list logo
