On Wed, Jun 15, 2016 at 10:08:39AM -0400, Konrad Rzeszutek Wilk wrote:
> Heya!
>
> Please put on the 4.6 stable tree these two following patches:
>
> 2a6f71a xen-blkfront: fix resume issues after a migration
> efd1535 xen-blkfront: don't call talk_to_blkback when already connected to
> blkback
>>> On 01.08.16 at 18:59, wrote:
> I want to run Xen+Linux Dom0 host on server-grade UEFI hardware.
>
> I want to use current stable releases of Xen (4.7) and Linux kernel (4.7).
>
> I prefer to use distro packages when possible, but the current distro
> packages I use crash on Xen boot.
>
> I
On 29/07/16 11:06, Vitaly Kuznetsov wrote:
> We pass xen_vcpu_id mapping information to hypercalls which require
> uint32_t type so it would be cleaner to have it as uint32_t. The
> initializer to -1 can be dropped as we always do the mapping before using
> it and we never check the 'not set' value
>>> On 02.08.16 at 08:43, wrote:
> --- a/arch/x86/xen/pmu.c
> +++ b/arch/x86/xen/pmu.c
> @@ -547,8 +547,11 @@ void xen_pmu_init(int cpu)
> return;
>
> fail:
> - pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
> - cpu, err);
> + if (err == -EOPNOTSUPP)
On 02/08/16 09:10, Jan Beulich wrote:
On 02.08.16 at 08:43, wrote:
>> --- a/arch/x86/xen/pmu.c
>> +++ b/arch/x86/xen/pmu.c
>> @@ -547,8 +547,11 @@ void xen_pmu_init(int cpu)
>> return;
>>
>> fail:
>> -pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
>> -
>>> On 01.08.16 at 18:59, wrote:
> Introduce and use the nonnull attribute to help the compiler catch NULL
> parameters being passed to function which require their parameters not to be
> NULL. Experimentally, GCC 4.9 on Debian Jessie only warns of non-NULL-ness
> from immediate callers, so propa
>>> On 01.08.16 at 18:34, wrote:
> uintptr_t is specified as unsigned int in 32bit, not unsigned long. This is
> why, when copying inttypes.h from GCC, the use of PRIxPTR and similar is
> broken for 32bit builds.
>
> Use __attribute__((__mode__(__pointer__))) to get the compilers default
> point
This run is configured for baseline tests only.
flight 66882 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm3 host-install(3)
The default for the Xen hypervisor is to not enable VPMU in order to
avoid security issues. In this case the Linux kernel will issue the
message "Could not initialize VPMU for cpu 0, error -95" which looks
more like an error than a normal state.
Change the message to something less scary in case t
flight 99893 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99893/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR.
vs. 99891
Regressio
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 Github[0] and is part of my
contribution to this year's Google Summer of Code (GSoC)
Hello Tamas,
On 01/08/2016 21:41, Tamas K Lengyel wrote:
On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall wrote:
we did discuss whether altp2m on ARM should be exposed to guests or
not but we did not agree whether restricting it on ARM is absolutely
necessary. Altp2m was designed even on the x86 t
On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
> Add support for getting/setting registers through vm_event on ARM. Only
> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set
> as part of a response. The set of registers can be expanded in the future to
> include other regist
On Tuesday 02 August 2016 00:19:22 Jan Beulich wrote:
> > > > On 02.08.16 at 01:19, wrote:
> > > > @@ -4412,6 +4412,7 @@ x86_emulate(
> > > > case 0x7f: /* movq mm,mm/m64 */
> > > > /* {,v}movdq{a,u} xmm,xmm/m128 */
> > > > /* vmovdq{a,u} ymm,ymm/m256 */
> >
On 08/01/2016 07:52 PM, 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() comp
On 08/01/2016 08:10 PM, Sergej Proskurin wrote:
> This commit extends xen-access by a simple test of the functionality
> provided by "xc_altp2m_change_gfn". The idea is to dynamically remap a
> trapping gfn to another mfn, which holds the same content as the
> original mfn.
>
> Signed-off-by: Serg
On Mon, Aug 01, 2016 at 06:20:56PM +0200, Roger Pau Monne wrote:
> A OS could decide to not pass arguments or any environment variables to
"An"
> hotplug scripts, and this will trigger a bug in device_hotplug logic, since
> it expects both the argument and the environment arrays to exist. Allow
>
On 02/08/16 07:09, Jan Beulich wrote:
On 01.08.16 at 19:11, wrote:
>> On 01/08/16 17:06, Jan Beulich wrote:
>> On 01.07.16 at 18:51, wrote:
How about a different example, from the second hunk
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/
On Fri, Jul 29, 2016 at 08:04:12PM +0100, Andrew Cooper wrote:
> On 29/07/16 17:29, Roger Pau Monne wrote:
> > Craft the Dom0 e820 memory map and populate it.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Jan Beulich
> > Cc: Andrew Cooper
> > ---
> > xen/arch/x86/domain_build.c | 199
On Fri, Jul 29, 2016 at 10:17:22PM +0200, Ingo Jürgensmann wrote:
> Am 29.07.2016 um 13:45 schrieb Andreas Ziegler :
>
> > we tried with kernel 4.6 now, the crashed happened again, though.
>
> Please find attached the netconsole log of 3 from 4 crashes so far today…
What is also interesting is
On Tue, Aug 02, 2016 at 10:13:42AM +0100, Wei Liu wrote:
> On Mon, Aug 01, 2016 at 06:20:56PM +0200, Roger Pau Monne wrote:
> > A OS could decide to not pass arguments or any environment variables to
>
> "An"
>
> > hotplug scripts, and this will trigger a bug in device_hotplug logic, since
> > it
On Tue, Aug 02, 2016 at 11:27:13AM +0200, Roger Pau Monne wrote:
> On Tue, Aug 02, 2016 at 10:13:42AM +0100, Wei Liu wrote:
> > On Mon, Aug 01, 2016 at 06:20:56PM +0200, Roger Pau Monne wrote:
> > > A OS could decide to not pass arguments or any environment variables to
> >
> > "An"
> >
> > > hot
On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
> On 29/07/16 17:28, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
> > index 107fc8c..1b270df 100644
> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -953,6 +953,
On Thu, Jul 28, 2016 at 03:35:19PM +0200, Juergen Gross wrote:
> libxl_set_memory_target() and several other interface functions of
> libxl use a 32 bit sized parameter for a memory size value in kBytes.
> This limits the maximum size to be passed in such a parameter
> depending on signedness of th
Hi Razvan,
On 08/02/2016 11:14 AM, Razvan Cojocaru wrote:
> On 08/01/2016 08:10 PM, Sergej Proskurin wrote:
>> This commit extends xen-access by a simple test of the functionality
>> provided by "xc_altp2m_change_gfn". The idea is to dynamically remap a
>> trapping gfn to another mfn, which holds
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-clean--incoming.log
char device redirected to /dev/pts/4 (label serial0)
xen_ram_alloc: do not all
On 01/08/2016 19:22, Mark Rutland wrote:
Hi,
Hi Mark,
I realised I made a confusing mistake in my last reply; clarification below.
On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote:
On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote:
however we only need one TLBI ins
flight 99894 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99894/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 99776
Regressions which
flight 99895 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99895/
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
On Fri, Jul 29, 2016 at 02:15:24PM +0100, George Dunlap wrote:
> On 29/07/16 14:00, Juergen Gross wrote:
> > When specifying no USB controller type for a usb device the default is
> > chosen in libxl__device_usbctrl_setdefault(). For a HVM guest this is
> > currently the not yet supported "LIBXL_US
flight 99896 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99896/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 28ade7b802e0732cf9839017ee6e9cf78b842582
baseline version:
ovmf 07783fdd67e40fa7cff3ebf
On Fri, Jul 22, 2016 at 05:09:30PM +0200, Juergen Gross wrote:
> Instead of trying to read xenstore via xenstore-read use the pidfile
> of xenstored for the test whether xenstored is running. This prepares
> support of xenstore domain, as trying to read xenstore will block
> for ever in case xensto
On Tue, Aug 02, 2016 at 10:58:00AM +0100, Julien Grall wrote:
> On 01/08/2016 19:22, Mark Rutland wrote:
> >On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote:
> >>On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote:
> >>>however we only need one TLBI instruction (assuming there
On 02/08/16 12:23, Wei Liu wrote:
> On Fri, Jul 22, 2016 at 05:09:30PM +0200, Juergen Gross wrote:
>> Instead of trying to read xenstore via xenstore-read use the pidfile
>> of xenstored for the test whether xenstored is running. This prepares
>> support of xenstore domain, as trying to read xensto
This run is configured for baseline tests only.
flight 66883 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66883/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3
On 02.08.2016 11:20, Wei Liu wrote:
On Fri, Jul 29, 2016 at 10:17:22PM +0200, Ingo Jürgensmann wrote:
What is also interesting is that you seem to be running some sort of
ip accounting software (pmacctd) which also segfault'ed.
Yeah, it is segfaulting, because the database (in a domU VM) where
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.
Correct one error: don't remove old tdb files in background, as this
could lead to very subtle races.
A rerun of autogen.sh is required.
On a system with systemd the xenstore sockets are created via systemd.
Remove the related configuration files in order to be able to decide
at runtime whether the sockets should be created or not. This will
enable Xen to start xenstore either via a daemon or via a stub domain.
As the xenstore doma
Add configuration entries to sysconfig.xencommons for selection of the
xenstore type (domain or daemon) and start the selected xenstore
service via a script called from sysvinit or systemd.
Signed-off-by: Juergen Gross
---
V3: - remove check for running xenstore domain, as this is done in
i
>>> On 02.08.16 at 11:15, wrote:
> On 02/08/16 07:09, Jan Beulich wrote:
> On 01.08.16 at 19:11, wrote:
>>> On 01/08/16 17:06, Jan Beulich wrote:
>>> On 01.07.16 at 18:51, wrote:
> How about a different example, from the second hunk
>
> --- a/xen/arch/x86/x86_emulate/x86_emul
Instead of trying to read xenstore via xenstore-read use the pidfile
of xenstored for the test whether xenstored is running. This prepares
support of xenstore domain, as trying to read xenstore will block
for ever in case xenstore domain is started after trying to read.
Signed-off-by: Juergen Gros
Add a configuration option to /etc/sysconfig/xencommons to let the
user configure whether he wants to start xenstore service as a daemon
or as a stubdom.
Changes in V4:
- patch 1: remove sd_booted() test, undo unintended white space changes
- patch 3: use @XEN_RUN_DIR@ as requested by Wei Liu
Cha
On Tue, Aug 02, 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:
It fails also with staging-4.6 and staging-4.7 and their included
qemu-xen binaries, and staging-4.7
An OS could decide to not pass any environment variables to hotplug scripts,
and this will trigger a bug in device_hotplug logic, since it expects the
environment array to exist. Allow env to be NULL.
Signed-off-by: Roger Pau Monné
---
Cc: Wei Liu
Cc: Ian Jackson
---
Changes since v1:
- Fix co
On Tue, Aug 02, 2016 at 12:49:51PM +0200, Roger Pau Monne wrote:
> An OS could decide to not pass any environment variables to hotplug scripts,
> and this will trigger a bug in device_hotplug logic, since it expects the
> environment array to exist. Allow env to be NULL.
>
> Signed-off-by: Roger P
On Thu, Jul 28, 2016 at 12:06:11PM +0100, Julien Grall wrote:
> Hi,
>
> On 26/07/16 02:17, Boris Ostrovsky wrote:
> >On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
> >>On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
> >>>On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
> On Mon, 25 Jul 2016, G
On Thu, Jul 28, 2016 at 08:42:05PM +0800, Shannon Zhao wrote:
> On 2016年07月28日 19:06, Julien Grall wrote:
> > On 26/07/16 02:17, Boris Ostrovsky wrote:
> >> On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
> >>> On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
> On 07/25/2016 06:06 PM, Stefano Sta
On Tue, Aug 02, 2016 at 12:39:25PM +0200, Juergen Gross wrote:
> On a system with systemd the xenstore sockets are created via systemd.
> Remove the related configuration files in order to be able to decide
> at runtime whether the sockets should be created or not. This will
> enable Xen to start x
On Tue, Aug 02, 2016 at 12:39:26PM +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.
>
> Correct one error: don't remove old tdb files in background, as
On Tue, Aug 02, 2016 at 12:39:27PM +0200, Juergen Gross wrote:
> Instead of trying to read xenstore via xenstore-read use the pidfile
> of xenstored for the test whether xenstored is running. This prepares
> support of xenstore domain, as trying to read xenstore will block
> for ever in case xensto
On Tue, Aug 02, 2016 at 12:39:28PM +0200, Juergen Gross wrote:
> Add configuration entries to sysconfig.xencommons for selection of the
> xenstore type (domain or daemon) and start the selected xenstore
> service via a script called from sysvinit or systemd.
>
> Signed-off-by: Juergen Gross
Acke
On 02/08/16 08:38, Julien Grall wrote:
> Hello Tamas,
>
> On 01/08/2016 21:41, Tamas K Lengyel wrote:
>> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall
>> wrote:
we did discuss whether altp2m on ARM should be exposed to guests or
not but we did not agree whether restricting it on ARM is a
On 02/08/16 13:13, Wei Liu wrote:
> On Tue, Aug 02, 2016 at 12:39:26PM +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.
>>
>> Correct one error: don't
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
On Mon, Aug 01, 2016 at 09:33:56AM -0600, Jan Beulich wrote:
> >>> On 26.07.16 at 18:15, wrote:
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -814,10 +814,17 @@ int epte_get_entry_emt(struct domain *d, unsigned
> > long gfn, mfn_t mfn,
> > if ( gmtrr_mtype == -EA
flight 99900 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99900/
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 Fr, 2016-07-29 at 13:17 +0200, Juergen Gross wrote:
> When unplugging a device in the Xen pvusb backend drain the submit
> queue before deallocation of the control structures. Otherwise there
> will be bogus memory accesses when I/O contracts are finished.
>
> Correlated to this issue is the ha
On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote:
> Introducing HVMCTL, Jan wrote:
> > A long while back separating out all control kind operations (intended
> > for use by only the control domain or device model) from the currect
> > hvmop hypercall has been discussed. This series aims
On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
> >>> On 01.08.16 at 13:32, wrote:
> > 4. We could invent a new hypercall `DMOP' for hypercalls which device
> >models should be able to use, which always has the target domain in
> >a fixed location in the arguments. We have th
On Tue, Aug 02, 2016 at 01:20:40PM +0200, Juergen Gross wrote:
> On 02/08/16 13:13, Wei Liu wrote:
> > On Tue, Aug 02, 2016 at 12:39:26PM +0200, Juergen Gross wrote:
> >> In order to prepare starting a xenstore domain split out the starting
> >> of the xenstore daemon from the xencommons script int
On Di, 2016-08-02 at 08:32 +0200, Juergen Gross wrote:
> 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 do
On 02/08/16 12:37, Wei Liu wrote:
> On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote:
>> Introducing HVMCTL, Jan wrote:
>>> A long while back separating out all control kind operations (intended
>>> for use by only the control domain or device model) from the currect
>>> hvmop hypercall
flight 66884 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66884/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken R
Thanks for your reply.
I installed the debug hypervisor and got a new crash dump now.
I must confess that I have little to no experience debugging crash dumps, but
this seems to be a different kind of error, or at least the way the error is
reached is different.
The pattern with “page number X i
On 02/08/16 13:37, Gerd Hoffmann wrote:
> On Fr, 2016-07-29 at 13:17 +0200, Juergen Gross wrote:
>> When unplugging a device in the Xen pvusb backend drain the submit
>> queue before deallocation of the control structures. Otherwise there
>> will be bogus memory accesses when I/O contracts are fini
>>> On 02.08.16 at 13:25, wrote:
> On Mon, Aug 01, 2016 at 09:33:56AM -0600, Jan Beulich wrote:
>> >>> On 26.07.16 at 18:15, wrote:
>> > --- a/xen/arch/x86/hvm/mtrr.c
>> > +++ b/xen/arch/x86/hvm/mtrr.c
>> > @@ -814,10 +814,17 @@ int epte_get_entry_emt(struct domain *d, unsigned
>> > long gfn, mf
>>> On 02.08.16 at 13:38, wrote:
> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
>> >>> On 01.08.16 at 13:32, wrote:
>> > 4. We could invent a new hypercall `DMOP' for hypercalls which device
>> >models should be able to use, which always has the target domain in
>> >a fixe
On Mon, Aug 01, 2016 at 07:10:26PM +0200, Sergej Proskurin wrote:
> The current implementation allows to set the parameter HVM_PARAM_ALTP2M.
> This parameter allows further usage of altp2m on ARM. For this, we
> define an additional, common altp2m field as part of the
> libxl_domain_type struct. Th
On Tue, Aug 02, Juergen Gross wrote:
> - rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
> + rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null
>
> Please note the "&" in the removed line. And the description just tells
> you that: the file shouldn't be removed in the background. How else
>
On 02/08/16 13:59, Olaf Hering wrote:
> On Tue, Aug 02, Juergen Gross wrote:
>
>> -rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
>> +rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null
>>
>> Please note the "&" in the removed line. And the description just tells
>> you that: the file shouldn
When unplugging a device in the Xen pvusb backend drain the submit
queue before deallocation of the control structures. Otherwise there
will be bogus memory accesses when I/O contracts are finished.
Correlated to this issue is the handling of cancel requests: a packet
cancelled will still lead to
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 xen_be_del_xendev() in
When testing qemu based pvusb backend two bugs have been discovered:
- detaching of a usb controller leads to memory clobbering in qemu
- detaching of a usb device with active I/O requests could result in
crash of qemu
V2: remove checkpatch warnings for patch 2 as requested by Gerd Hoffmann
Jue
On Mon, Aug 01, 2016 at 11:14:27AM -0600, Tamas K Lengyel wrote:
> Currently mem-sharing can be performed on a page-by-page basis from the
> control
> domain. However, this process is quite wasteful when a range of pages have to
> be deduplicated.
>
> This patch introduces a new mem_sharing memop
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
>>> On 02.08.16 at 13:45, wrote:
> (XEN) [ Xen-4.6.1 x86_64 debug=y Not tainted ]
> (XEN) CPU:6
> (XEN) RIP:e008:[] vmx_vmenter_helper+0x27e/0x30a
> (XEN) RFLAGS: 00010003 CONTEXT: hypervisor
> (XEN) rax: 8005003b rbx: 8300e72fc000 rcx:
On Tue, Aug 02, 2016 at 12:42:36PM +0100, George Dunlap wrote:
> On 02/08/16 12:37, Wei Liu wrote:
> > On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote:
> >> Introducing HVMCTL, Jan wrote:
> >>> A long while back separating out all control kind operations (intended
> >>> for use by only
On Tue, Aug 02, 2016 at 12:30:30PM +0200, Ingo Jürgensmann wrote:
> On 02.08.2016 11:20, Wei Liu wrote:
> >On Fri, Jul 29, 2016 at 10:17:22PM +0200, Ingo Jürgensmann wrote:
> >What is also interesting is that you seem to be running some sort of
> >ip accounting software (pmacctd) which also segfaul
On Tue, Aug 02, 2016 at 07:48:12PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the
> corresponding macro,
>>> On 01.08.16 at 18:52, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
> int rc, fall_through = 0, paged = 0;
> int sharing_enomem = 0;
> vm_event_request_t *req_ptr = NU
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of
>>> On 18.07.16 at 11:51, wrote:
> set_segment_base is the only hypercall exists in only one of the two modes
> guests might run in; all other hypercalls are either implemented, or
> unimplemented in both modes.
>
> Remove this split, by allowing do_set_segment_base() to be called in the
> compat
>>> On 18.07.16 at 11:51, wrote:
> --- a/xen/include/asm-x86/hypercall.h
> +++ b/xen/include/asm-x86/hypercall.h
> @@ -5,9 +5,21 @@
> #ifndef __ASM_X86_HYPERCALL_H__
> #define __ASM_X86_HYPERCALL_H__
>
> +#include
> #include
> +#include
Why?
> #include /* for do_mca */
> -#include
> +
>>> On 18.07.16 at 11:51, wrote:
> Editing (and indeed, finding) the hypercall args tables can be tricky,
> especially towards the end where .rept's are used to maintain the correct
> layout.
>
> Move this all into C, and let the compiler do the hard work. As 0 is the
> default value, drop all e
On 02/08/16 12:58, Jan Beulich wrote:
On 02.08.16 at 13:38, wrote:
>> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
>> On 01.08.16 at 13:32, wrote:
4. We could invent a new hypercall `DMOP' for hypercalls which device
models should be able to use, which always
On Tue, Aug 2, 2016, at 12:06 AM, Jan Beulich wrote:
> I don't understand this distro related complaint.
Possibly because it's not a complaint. It's a question.
> Afaict the bug is in upstream Linux, and hence any distro will have the issue.
> expectation that freshly released Linux (or Xen)
On Tue, Aug 02, 2016 at 06:40:21PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the
> corresponding macro,
>>> On 18.07.16 at 11:51, wrote:
> +long pv_hypercall(struct cpu_user_regs *regs)
> +{
> +struct vcpu *curr = current;
> +#ifndef NDEBUG
> +unsigned long old_rip = regs->rip;
> +#endif
> +long ret;
> +uint32_t eax = regs->eax;
> +
> +ASSERT(curr->arch.flags & TF_kernel_mode);
On Mon, Aug 1, 2016, at 11:36 PM, Jan Beulich wrote:
> yet without a full log thereof I can't judge
I've asked what that 'full log' should be
>>> Hmmm Could you provide full console dump from Xen and Linux kernel?
>
>Will serial console output with these options
>
> kernel: earlyp
On Mon, Aug 1, 2016 at 5:59 PM, Andrew Cooper wrote:
> Introduce and use the nonnull attribute to help the compiler catch NULL
> parameters being passed to function which require their parameters not to be
> NULL. Experimentally, GCC 4.9 on Debian Jessie only warns of non-NULL-ness
> from immedia
On 02/08/16 13:50, Jan Beulich wrote:
On 18.07.16 at 11:51, wrote:
>> --- a/xen/include/asm-x86/hypercall.h
>> +++ b/xen/include/asm-x86/hypercall.h
>> @@ -5,9 +5,21 @@
>> #ifndef __ASM_X86_HYPERCALL_H__
>> #define __ASM_X86_HYPERCALL_H__
>>
>> +#include
>> #include
>> +#include
> Why
1 - 100 of 221 matches
Mail list logo
