>>> On 17.02.17 at 04:35, wrote:
> Feng just left Intel. Let me take a look at code to understand the
> rationale behind.
Do you know if he means to stay VT-d maintainer? If yes, do you
have a new email address of him? If not, would you mind sending
an update to ./MAINTAINERS removing him?
Thank
On 17/02/17 08:11, Joe Perches wrote:
> To enable eventual removal of pr_warning
>
> This makes pr_warn use consistent for arch/x86
>
> Prior to this patch, there were 46 uses of pr_warning and
> 122 uses of pr_warn in arch/x86
>
> Miscellanea:
>
> o Coalesce a few formats and realign arguments
>>> On 17.02.17 at 07:53, wrote:
>> From: Tian, Kevin
>> Sent: Friday, February 17, 2017 11:35 AM
>> > >>
>> > >> Or wait - do you have the same issue if you use
>> > >> "iommu=no,no-intremap"? In which case the problem would be
>> > >> that "iommu=no" should clear more than just "iommu_enable",
>>> On 16.02.17 at 19:09, wrote:
> On 02/16/2017 12:09 PM, Andrew Cooper wrote:
>> Second, if it is available, has the toolstack chosen to allow the domain
>> to use it. This should determine whether features/information are
>> visible in CPUID.
>
> You mean if toolstack masks out leaf 0xa on In
flight 105872 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105872/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 14 guest-saverestorefail REGR. vs. 105852
test-armhf-a
>>> On 16.02.17 at 18:31, wrote:
> On 02/16/2017 11:59 AM, Jan Beulich wrote:
>> Also this new model basically limits the opportunity to change the
>> mode to the case where no guest at all is running, iiuc. Previously
>> this would have been possible with any number of guests running,
>> as long
On Thu, 2017-02-16 at 04:15 -0700, Jan Beulich wrote:
> When __context_switch() is being bypassed during original context
> switch handling, the vCPU "owning" the VMCS partially loses control of
> it: It will appear non-running to remote CPUs, and hence their attempt
> to pause the owning vCPU will
flight 105863 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105863/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 105689
Regressi
>>> On 15.02.17 at 18:39, wrote:
> @@ -1208,22 +1208,19 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn,
> unsigned offset)
>
> /*
> * Unmap the vcpu info page if the guest decided to place it somewhere
> - * else. This is used from arch_domain_destroy and domain_soft_reset.
> + * els
flight 105865 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105865/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 958163561e9b6d8fa40ea4aac49d46cc889015ac
baseline version:
ovmf b173ad78519b2ade30901
>>> On 17.02.17 at 09:40, wrote:
> On Thu, 2017-02-16 at 04:15 -0700, Jan Beulich wrote:
>> When __context_switch() is being bypassed during original context
>> switch handling, the vCPU "owning" the VMCS partially loses control of
>> it: It will appear non-running to remote CPUs, and hence their
On 30/01/17 16:10, Juergen Gross wrote:
> Instead of using the default resolution of 800*600 for the pointing
> device of xen-kbdfront try to read the resolution of the (virtual)
> framebuffer device. Use the default as fallback only.
>
> Signed-off-by: Juergen Gross
Dmitry, any comment from you
>>> On 16.02.17 at 18:13, wrote:
> They depend soley on paging mode, so don't need to be repeated per domain, and
> can live in .rodata. While making this change, drop the redundant log_dirty
> from the function pointer names.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
but ...
>>> On 16.02.17 at 19:56, wrote:
> --- a/tools/fuzz/x86_instruction_emulator/Makefile
> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> @@ -8,12 +8,16 @@ else
> x86-instruction-emulator-fuzzer-all:
> endif
>
> -x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h:
> +x86_emulate:
> [
>>> On 16.02.17 at 19:56, wrote:
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Sat, 18 Feb 2017 09:27:37 +0800
Subject: [PATCH] x86/apicv: enhance posted-interrupt processing
If guest is already in non-root mode, an posted interrupt will
be directly delivered to guest (leaving softir
>>> On 16.02.17 at 21:07, wrote:
> Replace one opencoded mfn_eq() and some coding style issues on altered lines.
> Swap __mfn_valid() to being bool, although it can't be updated to take mfn_t
> because of include dependencies.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by
On Thu, Feb 16, 2017 at 04:02:57PM -0500, Waiman Long wrote:
> On 02/16/2017 11:09 AM, Peter Zijlstra wrote:
> > On Wed, Feb 15, 2017 at 04:37:49PM -0500, Waiman Long wrote:
> >> The cpu argument in the function prototype of vcpu_is_preempted()
> >> is changed from int to long. That makes it easier
>>> On 17.02.17 at 07:39, wrote:
> Replace tab indentation by whitespace.
>
> Signed-off-by: Haozhong Zhang
Acked-by: Jan Beulich
with ...
> @@ -345,8 +345,8 @@ struct xen_mc_fetch {
> /* IN/OUT variables. */
> uint32_t flags; /* IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
>
>>> On 17.02.17 at 07:39, wrote:
> Remove declarations of functions
> intel_mcheck_timer()
> mce_intel_feature_init()
> mce_cap_init()
> x86_mcinfo_getptr()
> whose definitions had been removed long time ago.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
___
>>> On 17.02.17 at 07:39, wrote:
> Signed-off-by: Haozhong Zhang
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 17.02.17 at 07:39, wrote:
> Signed-off-by: Haozhong Zhang
Not sure here, I can't imagine the function being here without
reason, even if the plans perhaps never got carried out. Could
you please identify in the commit message here whether there
ever were callers (and if so, when the last
>>> On 17.02.17 at 07:39, wrote:
> The second loop that gets MSR_IA32_MCG_R8 to MSR_IA32_MCG_R15 was
> surrounded by '#ifdef __X86_64__ ... #endif' and had to be seperated
> from the first loop that gets MSR_IA32_MCG_EAX to MSR_IA32_MCG_MISC.
> Because Xen had dropped support for 32-bit x86 host,
>>> On 17.02.17 at 07:39, wrote:
> Implementations of these two functions are effectively the same, so
> unify them by a common intel_default_mce_handler().
Them being the same right now may also be an issue with the
earlier authors never having completed their job. I'd like to see
justification
>>> On 17.02.17 at 07:39, wrote:
> Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 17.02.17 at 07:39, wrote:
> @@ -804,7 +800,7 @@ static void mcinfo_clear(struct mc_info *mi)
> x86_mcinfo_nentries(mi) = 0;
> }
>
> -void *x86_mcinfo_reserve(struct mc_info *mi, int size)
> +void *x86_mcinfo_reserve(struct mc_info *mi, uint16_t size, uint16_t type)
There's no need
>>> On 17.02.17 at 07:39, wrote:
> Use uint32_t rather than int to align to the type of
> xen_mc_physcpuinfo.ncpus.
I'm not sure about policies in the tool stack, but in the hypervisor I
would request to use unsigned int instead of fixed width types
where the fixed width isn't really relevant.
J
George,
thanks for pulling this together.
> On 14 Feb 2017, at 17:25, George Dunlap wrote:
>
> Here is version two, with minor revisions based on comments from version
> 1. Please give any feedback by 28 February. Thanks!
I think we may need to take a step back on this, given the coverage of
On Thu, Feb 16, 2017 at 07:10:41PM +, Andrew Cooper wrote:
> On 16/02/17 18:56, Wei Liu wrote:
> > Several `ln -sf` can race with each other and cause error like:
> >
> > 14:43:56 00:07:06 O: ln: cannot remove 'asm': No such file or directory
> >
> > Provide dedicated targets for soft-linking d
On Fri, Feb 17, 2017 at 02:24:15AM -0700, Jan Beulich wrote:
> >>> On 16.02.17 at 19:56, wrote:
> > --- a/tools/fuzz/x86_instruction_emulator/Makefile
> > +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> > @@ -8,12 +8,16 @@ else
> > x86-instruction-emulator-fuzzer-all:
> > endif
> >
> > -x
>>> On 17.02.17 at 07:39, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mcaction.c
> +++ b/xen/arch/x86/cpu/mcheck/mcaction.c
> @@ -88,21 +88,21 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
> goto vmce_failed;
> }
>
> +if ( boot_cpu_data.x86_vendo
>>> On 17.02.17 at 07:39, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -538,7 +538,14 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
> gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
> if ((gstatus & MCG_STATUS_MCIP) != 0) {
> m
Paul Durrant (4):
tools/libxendevicemodel: introduce the new library
tools/libxendevicemodel: extract functions and add a compat layer
tools/libxendevicemodel: introduce a Linux-specific implementation
tools/libxendevicemodel: add a call to restrict the handle
stubdom/Makefile
The new xendevicemodel library is intended to be used by all Xen device
models such that the only hypercall that use will be the dm_op hypercall
added by commit 524a98c2.
This patch adds the boilerplate for the new library, with only open() and
close() entry points, and calls to those from libxenc
Several `ln -sf` can race with each other. Provide dedicated targets
for soft-linking directories.
Signed-off-by: Wei Liu
---
tools/tests/x86_emulator/Makefile | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/tests/x86_emulator/Makefile
b/tools/tests/x86_
My recent patch [1] to the Linux privcmd module introduced a dedicated
mechanism for making dm_op hypercalls.
This patch adds the necessary code to libxendevicemodel to take
advantage of that mechanism if it is implemented in the tools domain
kernel.
[1]
https://git.kernel.org/cgit/linux/kernel/
My recent patch [1] to the Linux privcmd module introduced a mechanism
to restrict an open file handle to subsequently only accept operations for
a specified domain.
This patch extends the libxendevicemodel API and make use of the
mechanism in the Linux-specific code to restrict operations on the
Several `ln -sf` can race with each other and cause error like:
14:43:56 00:07:06 O: ln: cannot remove 'asm': No such file or directory
Provide dedicated targets for soft-linking directories.
Reported-by: Andrew Cooper
Signed-off-by: Wei Liu
---
tools/fuzz/x86_instruction_emulator/Makefile |
Wei Liu (2):
fuzz/x86emul: avoid race in link farm rune
x86emul/test: avoid race in link farm rune
tools/fuzz/x86_instruction_emulator/Makefile | 13 +++--
tools/tests/x86_emulator/Makefile| 13 +++--
2 files changed, 14 insertions(+), 12 deletions(-)
--
2.11.0
This patch extracts all functions resulting in a dm_op hypercall from
libxenctrl and moves them into libxendevicemodel. It also adds a compat
layer into libxenctrl, which can be selected by defining
XC_WANT_COMPAT_DEVICEMODEL_API to 1 before including xenctrl.h.
With this patch the core of libxend
Hello,
I've installed Xen 4.9-unstable (master branch, commit
1e88db4701d6e2d00c04795e6aacaea942b617e6) on an old Ubuntu workhorse
machine, and when using quemu-xen-traditional, quemu-dm crashes with
this backtrace:
# gdb /usr/lib/xen/bin/qemu-dm core
Reading symbols from /usr/lib/xen/bin/qemu-dm
>>> On 17.02.17 at 11:12, wrote:
> On Thu, Feb 16, 2017 at 07:10:41PM +, Andrew Cooper wrote:
>> On 16/02/17 18:56, Wei Liu wrote:
>> > --- a/tools/fuzz/x86_instruction_emulator/Makefile
>> > +++ b/tools/fuzz/x86_instruction_emulator/Makefile
>> > @@ -8,12 +8,16 @@ else
>> > x86-instruction-e
> On 15 Feb 2017, at 21:09, Stefano Stabellini wrote:
>
>> ...
>>
> Istinctively, I don't like the idea of splitting up the hypervisor
> project in multiple projects.
We could split out the following git repos: mini-os, osstest, raisin,
livepatch-build-tools, xtf
In
On Thu, Feb 16, 2017 at 04:49:18AM -0700, Jan Beulich wrote:
> >>> On 16.02.17 at 12:14, wrote:
> On 15.02.17 at 12:21, wrote:
> >> At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote:
> >>> >>> On 14.02.17 at 18:33, wrote:
> >>> >> TBD: Do we really want to re-init the TSS every time
>>> On 17.02.17 at 11:11, wrote:
>> On 14 Feb 2017, at 17:25, George Dunlap wrote:
>> 1c. The source is guest userspace, and the target is the guest kernel,
>> or other guest userspace processes.
>>
>> This means, for instance, that bug which allows a guest kernel to
>> perform a DoS on itself w
>>> On 17.02.17 at 11:27, wrote:
> I've installed Xen 4.9-unstable (master branch, commit
> 1e88db4701d6e2d00c04795e6aacaea942b617e6) on an old Ubuntu workhorse
> machine, and when using quemu-xen-traditional, quemu-dm crashes with
> this backtrace:
>
> # gdb /usr/lib/xen/bin/qemu-dm core
> Readi
>>> On 17.02.17 at 11:27, wrote:
> --- a/tools/fuzz/x86_instruction_emulator/Makefile
> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> @@ -8,19 +8,20 @@ else
> x86-instruction-emulator-fuzzer-all:
> endif
>
> -x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h:
> - [ -L x86_emulate
This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END,
and other macros across x86. When we have all this sorted out, this will
help to inject DWARF unwinding info by objtool later.
So, let us use the macros this way:
* ENTRY -- start of a global function
* ENDPROC -- end of a loca
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new ENTRY_ALIAS and ENTRY_LOCAL_ALIAS. This will make
the tools generating the debuginfo happy.
Signed-off-by: Jiri Slaby
Cc: Herbert Xu
Somewhere END was used to end a function, elsewhere, nothing was used.
So unify it and mark them all by ENDPROC.
Signed-off-by: Jiri Slaby
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc:
Cc: "Rafael J. Wysocki"
Cc: Pavel Machek
Cc:
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc:
Port vscsi=[] and scsi-{attach,detach,list} commands from xend to libxl.
libvirt uses its existing SCSI support:
http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg02963.html
targetcli/rtslib has to be aware of xen-scsiback (upstream unresponsive):
http://article.gmane.org/gmane.linux
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Wei Liu
---
Just a rebase to RELEASE-4.8.0
docs/man/xl.cfg.pod.5.in | 56 ++
docs/man/xl.
Just to make them public, not meant for merging:
The scripts used during development to create a bunch of SCSI devices in
dom0 using the Linux target framework. targetcli3 and rtslib3 is used.
A patch is required for python-rtslib:
http://article.gmane.org/gmane.linux.scsi.target.devel/8146
These
The variable virq_port of type uint32_t was compared to being greater than
-1. This check always results in false for unsigned data types, resulting
in never cleaning up the memory. Furthermore, the initialization with a
negative variable for an unsigned type has been fixed.
Signed-off-by: Norbert
Dear Xen developers,
I would like to bring the attached two patches online, as they fix minor defects
in the upstream code base.
Best,
Norbert
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
During destroying the m2p mapping, the loop variable was always incremented
by one, as the current version used a compare operator on the left hand side,
which always evaluated to true, i.e.
i += 1UL < (L2_PAGETABLE_SHIFT - 2)
The fix increments the value of the variable by the actual page size b
On 02/17/2017 12:43 PM, Jan Beulich wrote:
On 17.02.17 at 11:27, wrote:
>> I've installed Xen 4.9-unstable (master branch, commit
>> 1e88db4701d6e2d00c04795e6aacaea942b617e6) on an old Ubuntu workhorse
>> machine, and when using quemu-xen-traditional, quemu-dm crashes with
>> this backtrace:
flight 105879 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105879/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 14 guest-saverestorefail REGR. vs. 105852
test-armhf-a
Just very quickly...
On Thu, 2017-02-16 at 15:07 -0800, Stefano Stabellini wrote:
> (XEN) Active queues: 1
> (XEN) default-weight = 256
> (XEN) Runqueue 0:
> (XEN) ncpus = 4
> (XEN) cpus = 0-3
> (XEN) max_weight = 256
> (XEN) instload = 1
On 17/02/17 11:47, Jiri Slaby wrote:
> This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END,
> and other macros across x86. When we have all this sorted out, this will
> help to inject DWARF unwinding info by objtool later.
>
> So, let us use the macros this way:
> * ENTRY -- star
On Fri, Feb 17, 2017 at 03:46:39AM -0700, Jan Beulich wrote:
> >>> On 17.02.17 at 11:27, wrote:
> > --- a/tools/fuzz/x86_instruction_emulator/Makefile
> > +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> > @@ -8,19 +8,20 @@ else
> > x86-instruction-emulator-fuzzer-all:
> > endif
> >
> > -x
> On 23 Jan 2017, at 11:30, Jan Beulich wrote:
>
On 20.01.17 at 20:21, wrote:
>> James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security
>> Response Process"):
>>> , and the issue is considered to be of significant urgency due
>>> to its severity, then the fourth Tuesda
On Thu, 16 Feb 2017, Joe Perches wrote:
> To enable eventual removal of pr_warning
>
> This makes pr_warn use consistent for arch/x86
>
> Prior to this patch, there were 46 uses of pr_warning and
> 122 uses of pr_warn in arch/x86
>
> Miscellanea:
>
> o Coalesce a few formats and realign argume
On 17/02/17 11:47, Jiri Slaby wrote:
> Somewhere END was used to end a function, elsewhere, nothing was used.
> So unify it and mark them all by ENDPROC.
>
> Signed-off-by: Jiri Slaby
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc:
> Cc: "Rafael J. Wysocki"
> Cc: Pavel M
On 17/02/17 10:47, Norbert Manthey wrote:
> During destroying the m2p mapping, the loop variable was always incremented
> by one, as the current version used a compare operator on the left hand side,
> which always evaluated to true, i.e.
>
> i += 1UL < (L2_PAGETABLE_SHIFT - 2)
>
> The fix incremen
On 17/02/17 10:47, Norbert Manthey wrote:
> The variable virq_port of type uint32_t was compared to being greater than
> -1. This check always results in false for unsigned data types, resulting
> in never cleaning up the memory. Furthermore, the initialization with a
> negative variable for an uns
On 17/02/17 10:47, Norbert Manthey wrote:
> Dear Xen developers,
>
> I would like to bring the attached two patches online, as they fix minor
> defects
> in the upstream code base.
Thankyou for the fixes; they are both good.
For future fixes, please can you CC the appropriate maintainers
(https:
On Fri, Feb 17, 2017 at 03:33:26AM -0700, Jan Beulich wrote:
> >>> On 17.02.17 at 11:12, wrote:
> > On Thu, Feb 16, 2017 at 07:10:41PM +, Andrew Cooper wrote:
> >> On 16/02/17 18:56, Wei Liu wrote:
> >> > --- a/tools/fuzz/x86_instruction_emulator/Makefile
> >> > +++ b/tools/fuzz/x86_instructio
>>> On 17.02.17 at 12:36, wrote:
> On Fri, Feb 17, 2017 at 03:33:26AM -0700, Jan Beulich wrote:
>> >>> On 17.02.17 at 11:12, wrote:
>> > On Thu, Feb 16, 2017 at 07:10:41PM +, Andrew Cooper wrote:
>> >> On 16/02/17 18:56, Wei Liu wrote:
>> >> > --- a/tools/fuzz/x86_instruction_emulator/Makefil
On 17/02/17 11:47, Jiri Slaby wrote:
> _key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
> memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
> them all using the new ENTRY_ALIAS and ENTRY_LOCAL_ALIAS. This will make
> the tools generating the debuginfo happy.
This run is configured for baseline tests only.
flight 68570 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 14 guest-saveresto
c/s 3044a2a "common/vcpu: Switch v->vcpu_info_mfn to mfn_t" was intended to be
no functional change.
Unfortunately, because vcpu_info_reset() clobbers v->vcpu_info_mfn, the change
ended up calling put_page_and_type() on MFN_INVALID.
Reintroduce the local variable, and leave a comment behind.
Sig
The present way of setting this up is flawed: Leaving the I/O bitmap
pointer at zero means that the interrupt redirection bitmap lives
outside (ahead of) the allocated space of the TSS. Similarly setting a
TSS limit of 255 when only 128 bytes get allocated means that 128 extra
bytes may be accessed
>>> On 17.02.17 at 12:56, wrote:
> c/s 3044a2a "common/vcpu: Switch v->vcpu_info_mfn to mfn_t" was intended to be
> no functional change.
>
> Unfortunately, because vcpu_info_reset() clobbers v->vcpu_info_mfn, the change
> ended up calling put_page_and_type() on MFN_INVALID.
>
> Reintroduce the
On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning
Hi,
On 16 February 2017 at 20:04, Julien Grall wrote:
> Hi,
>
>
> On 15/02/17 15:38, Konrad Rzeszutek Wilk wrote:
>>
>> On Wed, Feb 15, 2017 at 12:53:34PM +0530, Bhupinder Thakur wrote:
>>>
>>> Hi Konrad,
>>>
>>> Thanks for the feedback.
>>>
>>> On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk
Hi,
I'm adjusting python bindings to work on python3 too. This will require
few #if in the code (to compile for both python2 and python3), but it
isn't that bad. But there are some major changes in python3, which
require some decision about the bindings API:
1. Python3 has no longer separate 'int
Hi Rafael,
On Fri, Feb 17, 2017 at 1:27 PM, Rafael J. Wysocki wrote:
> On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote:
>> There are ~4300 uses of pr_warn and ~250 uses of the older
>> pr_warning in the kernel source tree.
>>
>> Make the use of pr_warn consistent across all kernel files.
>>
>
flight 105880 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105880/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 14 guest-saverestorefail REGR. vs. 105852
test-armhf-a
This run is configured for baseline tests only.
flight 68572 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68572/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 9 redhat
On 02/17/2017 02:36 AM, Juergen Gross wrote:
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
as not being present by special casing the related cpuid leaf.
Instead of delivering fake cpuid values clear the cpu c
On 16.02.17 23:11:22, Joe Perches wrote:
> To enable eventual removal of pr_warning
>
> This makes pr_warn use consistent for arch/x86
>
> Prior to this patch, there were 46 uses of pr_warning and
> 122 uses of pr_warn in arch/x86
>
> Miscellanea:
>
> o Coalesce a few formats and realign argume
On 02/17/2017 03:27 AM, Jan Beulich wrote:
On 16.02.17 at 19:09, wrote:
On 02/16/2017 12:09 PM, Andrew Cooper wrote:
Second, if it is available, has the toolstack chosen to allow the domain
to use it. This should determine whether features/information are
visible in CPUID.
You mean if too
On 17/02/17 15:05, Boris Ostrovsky wrote:
>
>
> On 02/17/2017 02:36 AM, Juergen Gross wrote:
>> When running as pv domain xen_cpuid() is being used instead of
>> native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
>> as not being present by special casing the related cpuid leaf.
>
On 02/17/2017 03:28 AM, Jan Beulich wrote:
On 16.02.17 at 18:31, wrote:
On 02/16/2017 11:59 AM, Jan Beulich wrote:
Also this new model basically limits the opportunity to change the
mode to the case where no guest at all is running, iiuc. Previously
this would have been possible with any num
On 02/17/2017 09:19 AM, Juergen Gross wrote:
On 17/02/17 15:05, Boris Ostrovsky wrote:
On 02/17/2017 02:36 AM, Juergen Gross wrote:
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
as not being present by spec
On 17/02/17 15:30, Boris Ostrovsky wrote:
>
>
> On 02/17/2017 09:19 AM, Juergen Gross wrote:
>> On 17/02/17 15:05, Boris Ostrovsky wrote:
>>>
>>>
>>> On 02/17/2017 02:36 AM, Juergen Gross wrote:
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid(
flight 105870 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105870/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105785
test-armhf-armhf-libvirt 13
flight 68573 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68573/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
On 02/17/2017 05:26 AM, Jan Beulich wrote:
On 17.02.17 at 07:39, wrote:
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -538,7 +538,14 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
if ((gstatus & MCG
On Thu, 16 Feb 2017 23:11:22 -0800
Joe Perches wrote:
> diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
> index 38868adf07ea..4a55e453296d 100644
> --- a/arch/x86/mm/testmmiotrace.c
> +++ b/arch/x86/mm/testmmiotrace.c
> @@ -121,9 +121,8 @@ static int __init init(void)
>
Hi Stefano,
On 16/02/17 18:40, Stefano Stabellini wrote:
On Thu, 16 Feb 2017, Julien Grall wrote:
Hello,
The last two community calls went really good and I am suggesting to have a
new one on Wednesday 1st March at 4pm UTC. Any opinions?
Is it possible to change the time to 5pm?
I am fine
>>> On 17.02.17 at 16:01, wrote:
> On 02/17/2017 05:26 AM, Jan Beulich wrote:
> On 17.02.17 at 07:39, wrote:
>>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>>> @@ -538,7 +538,14 @@ void mcheck_cmn_handler(const struct cpu_user_regs
>>> *regs)
>>> gstatus
Hi Stefano,
On 16/02/17 20:17, Stefano Stabellini wrote:
On Thu, 16 Feb 2017, Julien Grall wrote:
Hi Stefano,
On 15/02/2017 23:05, Stefano Stabellini wrote:
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. Increase it to 512M.
Signed-off-by: Stefano Stabellin
Hi Jan,
On 17/02/17 07:43, Jan Beulich wrote:
Well, in the end it's your call, but I don't think this is an acceptable
model in the general case. Quite often - see the Viridian support in
x86 Xen for a very good example - distros (XenServer in this case)
enable functionality even if a guest (Lin
On Thu, Feb 16, 2017 at 02:34:30PM +, Julien Grall wrote:
> Hi,
>
> On 15/02/17 15:38, Konrad Rzeszutek Wilk wrote:
> > On Wed, Feb 15, 2017 at 12:53:34PM +0530, Bhupinder Thakur wrote:
> > > Hi Konrad,
> > >
> > > Thanks for the feedback.
> > >
> > > On 7 February 2017 at 00:05, Konrad Rzes
> Should vpl011.h be in include/xen/public/ ? If so you need
> a different license for that file.
>
> I have moved the file from the public folder and keeping it in xen/arch/arm/
Huh? But if this is a ring protocol that is used by an OS that is not
part of of Xen tree it needs
This run is configured for baseline tests only.
flight 68574 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68574/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 958163561e9b6d8fa40ea4aac49d46cc889015ac
baseline v
flight 105867 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105867/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254
test-amd64-amd64-xl
On 02/17/2017 10:13 AM, Jan Beulich wrote:
On 17.02.17 at 16:01, wrote:
On 02/17/2017 05:26 AM, Jan Beulich wrote:
On 17.02.17 at 07:39, wrote:
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -538,7 +538,14 @@ void mcheck_cmn_handler(const struct cpu_user_regs *r
1 - 100 of 175 matches
Mail list logo
