flight 106814 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106814/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 7 host-ping-check-xen fail REGR. vs. 105975
Regre
> From: Gao, Chao
> Sent: Wednesday, March 15, 2017 1:11 PM
>
> The current logic of using VT-d pi is when guest configurates the pirq's
> destination vcpu to a single vcpu, the according IRTE is updated to posted
> format. If the destination of the pirq is multiple vcpus, we just use
> interrupt
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 16, 2017 6:29 PM
>
> >>> On 15.03.17 at 23:39, wrote:
> > On Wed, Mar 15, 2017 at 10:48:25AM -0600, Jan Beulich wrote:
> > On 15.03.17 at 06:11, wrote:
> >>> +/*
> >>> + * The following method to update IR
flight 106813 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106813/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 5 xen-install fail REGR. vs. 106696
test-amd
> From: Gao, Chao
> Sent: Wednesday, March 15, 2017 1:11 PM
>
> Currently, msi_msg_to_remap_entry is buggy when the live IRTE is in posted
> format. Straightforwardly, we can let caller specify which format of IRTE they
> want update to. But the problem is current callers are not aware of the
> bi
Hi Konrad,
On 4 March 2017 at 01:29, Konrad Rzeszutek Wilk wrote:
> .snip..
>> +case VPL011_UARTCR_OFFSET:
>> +*r = v->domain->arch.vpl011.control;
>> +break;
>
> Pls add a new newline after each break.
Ok.
>
>> +case VPL011_UARTDR_OFFSET:
>> +
flight 106812 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106812/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 guest-start fail REGR. vs. 106802
test-amd64-amd64-x
On 21/03/17 19:54, Stefano Stabellini wrote:
> On Tue, 21 Mar 2017, Juergen Gross wrote:
>> On 17/03/17 19:33, Stefano Stabellini wrote:
>>> On Fri, 17 Mar 2017, Juergen Gross wrote:
On 16/03/17 21:20, Stefano Stabellini wrote:
> On Thu, 16 Mar 2017, Juergen Gross wrote:
>> Instead of
2017年3月22日星期三，Stefano Stabellini 写道：
> On Tue, 21 Mar 2017, Wei Liu wrote:
> > On Wed, Mar 22, 2017 at 12:41:01AM +0800, Zhongze Liu wrote:
> > > This allows downstreams to set their defaults without modifying the
> source code
> > > all over the place. Also probably useful for the embedded space
On Thu, 16 Mar 2017, Andre Przywara wrote:
> To be able to easily send commands to the ITS, create the respective
> wrapper functions, which take care of the ring buffer.
> The first two commands we implement provide methods to map a collection
> to a redistributor (aka host core) and to flush the
On Thu, 16 Mar 2017, Andre Przywara wrote:
> Instead of directly manipulating the tables in memory, an ITS driver
> sends commands via a ring buffer in normal system memory to the ITS h/w
> to create or alter the LPI mappings.
> Allocate memory for that buffer and tell the ITS about it to be able
>
On Thu, 16 Mar 2017, Andre Przywara wrote:
> Each ITS maps a pair of a DeviceID (for instance derived from a PCI
> b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
> pair of LPI number and collection ID, which points to the target CPU.
> This mapping is stored in the device and
On Tue, 21 Mar 2017, André Przywara wrote:
> On 21/03/17 22:57, Stefano Stabellini wrote:
> > On Thu, 16 Mar 2017, Andre Przywara wrote:
> >> The ARM GICv3 provides a new kind of interrupt called LPIs.
> >> The pending bits and the configuration data (priority, enable bits) for
> >> those LPIs are
On 21/03/17 22:57, Stefano Stabellini wrote:
> On Thu, 16 Mar 2017, Andre Przywara wrote:
>> The ARM GICv3 provides a new kind of interrupt called LPIs.
>> The pending bits and the configuration data (priority, enable bits) for
>> those LPIs are stored in tables in normal memory, which software has
flight 106809 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs.
106793
Regressions w
On Thu, 16 Mar 2017, Andre Przywara wrote:
> The ARM GICv3 provides a new kind of interrupt called LPIs.
> The pending bits and the configuration data (priority, enable bits) for
> those LPIs are stored in tables in normal memory, which software has to
> provide to the hardware.
> Allocate the requ
This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4.
do_suspend (from xen/manage.c) and thus xen_resume_notifier never get
called on the initial-domain at resume (it is if running as guest.)
The rationale for the breaking change was that upload_pm_data()
potentially does blocking wo
Replace hard coded "ACPI0007" with ACPI_PROCESSOR_DEVICE_HID
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Ankur Arora
---
drivers/xen/xen-acpi-processor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
This patch series re-enables the upload of PM data from initial-domain
to Xen. This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4.
The upload now happens post-resume in workqueue context. From the
POV of Xen, the PM upload might be delayed a little but should be
fine -- Xen falls-b
Define the ring and request and response structs according to the
specification. Use the new DEFINE_XEN_FLEX_RING macro.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
---
xen/include/public/io/pvcalls.h | 152
1 file changed, 152 insertions
Define the ring according to the protocol specification, using the new
DEFINE_XEN_FLEX_RING_AND_INTF macro.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
---
xen/include/public/io/9pfs.h | 57
1 file changed, 57 insertions(+)
create mo
This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.
Indexes page
+
Hi all,
this patch series introduces a set of new ring macros to support rings
in the formats specified by the Xen 9pfs transport and PV Calls
protocol. It also introduces the Xen 9pfs and PV Calls protocols
headers.
Changes in v3:
- fix commit message
- add newlines after read/write_packet func
This run is configured for baseline tests only.
flight 71063 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71063/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f2333c707dd04f069c102bcae004561ec590a3a0
baseline v
flight 106806 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106806/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
Signed-off-by: Stefano Stabellini
Signed-off-by: Stefano Stabellini
CC: gr...@kaod.org
CC: anthony.per...@citrix.com
---
This patch is meant to be on top of
http://marc.info/?l=xen-devel&m=149003409510264&w=2
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINT
On Tue, 21 Mar 2017, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 20, 2017 at 10:49:21AM -0700, Stefano Stabellini wrote:
> > This patch introduces macros, structs and functions to handle rings in
> > the format described by docs/misc/pvcalls.markdown and
> > docs/misc/9pfs.markdown. The index page (
flight 106817 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106817/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 5 ker
On Tue, 21 Mar 2017, Luca Miccio wrote:
> Hi,
> I'm an undergraduate student from the Computer Science Bachelor's Degree
> of the University of Modena and Reggio Emilia (Italy).
>
> I'm very interested in the "Xen on ARM: create multiple guests from device
> tree"
> project.
> A year ago I starte
On Tue, 21 Mar 2017, Greg Kurz wrote:
> On Mon, 20 Mar 2017 11:18:46 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > Hi all,
> >
> > This patch series implements a new transport for 9pfs, aimed at Xen
> > systems.
> >
> > The transport is based on a traditional Xen frontend and backend drivers
>
On Mon, Mar 20, 2017 at 10:49:21AM -0700, Stefano Stabellini wrote:
> This patch introduces macros, structs and functions to handle rings in
> the format described by docs/misc/pvcalls.markdown and
> docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
> contains the indexes and the
Hi,
I'm an undergraduate student from the Computer Science Bachelor's Degree
of the University of Modena and Reggio Emilia (Italy).
I'm very interested in the "Xen on ARM: create multiple guests from
device tree"
project.
A year ago I started a project on the "Hikey" board with the Android
ope
On Tue, 21 Mar 2017, Paul Durrant wrote:
> This patch adds a command-line option (-xen-domid-restrict) which will
> use the new libxendevicemodel API to restrict devicemodel [1] operations
> to the specified domid. (Such operations are not applicable to the xenpv
> machine type).
>
> This patch al
On Tue, 21 Mar 2017, Juergen Gross wrote:
> On 17/03/17 19:33, Stefano Stabellini wrote:
> > On Fri, 17 Mar 2017, Juergen Gross wrote:
> >> On 16/03/17 21:20, Stefano Stabellini wrote:
> >>> On Thu, 16 Mar 2017, Juergen Gross wrote:
> Instead of trying to guess the Xen version to use by compil
This patch adds a command-line option (-xen-domid-restrict) which will
use the new libxendevicemodel API to restrict devicemodel [1] operations
to the specified domid. (Such operations are not applicable to the xenpv
machine type).
This patch also adds a tracepoint to allow successful enabling of
On Tue, 21 Mar 2017, Juergen Gross wrote:
> On 20/03/17 18:59, Stefano Stabellini wrote:
> > Implement functions to handle the xenbus handshake. Upon connection,
> > allocate the rings according to the protocol specification.
> >
> > Initialize a work_struct and a wait_queue. The work_struct will
The current threshold before the guest issues the hypercall is, and always
has been, hard-coded to 2047. It is not clear where this number came
from so, to at least allow for ease of experimentation, this patch makes
the threshold tunable via the Xen command line.
Signed-off-by: Paul Durrant
Revi
The numbers correspond to ASCII characters so just use appropriate
character strings directly.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
v2:
- Use memcpy() rather than cast-and-assign
---
xen/arch/x86/hvm/viridian.c | 10 ++
1 file changed, 6 insertio
Paul Durrant (6):
x86/viridian: fix xen-hvmcrash when vp_assist page is present
x86/viridian: don't put Xen version information in CPUID leaf 2
x86/viridian: get rid of the magic numbers in CPUID leaves 1 and 2
x86/viridian: add warnings for unimplemented hypercalls and MSRs
x86/viridian:
These warnings can be useful when Microsoft updates Windows.
In the past there have been several cases when Windows erroneously uses
hypercalls and MSRs that should be gated on CPUID flags than Xen does
not set. The usual symptom is a guest crash with little or no information
in the hypervisor log
Currently use of xen-hvmcrash will cause an immediate domain_crash() in
initialize_vp_assist() because it is called from viridian_load_vcpu_ctxt()
without having first cleared any previous mapping.
This patch addes a check into viridian_load_vcpu_ctxt() to avoid re-
initialization and turned the d
Section 2.4.4 of the Hypervisor Top Level Functional Specification states
that enabling bit 10 in EDX of CPUID leaf 3 advertises to Windows a set
of MSRs into which it can write crash information.
This patch advertises that bit and implements the MSRs such that Xen can
log the information if a Win
The Hypervisor Top Level Functional Specification v5.0a states in section
2.5:
"The hypervisor version information is encoded in leaf 0x4002. Two
version numbers are provided: the main version and the service version.
The main version includes a major and minor version number and a build
numbe
On Tue, 21 Mar 2017, Juergen Gross wrote:
> On 20/03/17 18:59, Stefano Stabellini wrote:
> > Implement struct p9_trans_module create and close functions by looking
> > at the available Xen 9pfs frontend-backend connections. We don't expect
> > many frontend-backend connections, thus walking a list
On Tue, Mar 21, 2017 at 06:21:24PM +0100, Juergen Gross wrote:
> On 21/03/17 18:16, Wei Liu wrote:
> > On Tue, Mar 21, 2017 at 05:14:47PM +, Wei Liu wrote:
> >> On Mon, Mar 20, 2017 at 09:00:20AM +0100, Juergen Gross wrote:
> >>> When the number of permitted xenstore entries for a domain is bei
On Mon, Mar 20, 2017 at 01:27:26PM -0600, Tamas K Lengyel wrote:
>
> if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
> (libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) &&
> - libxl_defbool_val(d_config->b_info.u.hvm.altp2m))) {
> +(libxl_defbool_val(d_conf
On Tue, Mar 21, 2017 at 06:10:06PM +0100, Vitaly Kuznetsov wrote:
> Boris Ostrovsky writes:
> > Can we read xenstore's dm-version? Or is it too early to get access there?
> >
>
> Seems to be too late: xenbus_init() is a postcore_initcall. Moreover, it
> seems that 'dm-version' lives under 'libxl'
On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich wrote:
On 21.03.17 at 18:09, wrote:
>> On Tue, Mar 21, 2017 at 11:06 AM, Jan Beulich wrote:
>> On 21.03.17 at 17:43, wrote:
On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
On 21.03.17 at 17:30, wrote:
>> On Tue, Mar
flight 106802 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106802/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 6 xen-boot fail in 106796 pass in 106802
test-amd64-amd64-xl-qemut-debian
On 21/03/17 18:16, Wei Liu wrote:
> On Tue, Mar 21, 2017 at 05:14:47PM +, Wei Liu wrote:
>> On Mon, Mar 20, 2017 at 09:00:20AM +0100, Juergen Gross wrote:
>>> When the number of permitted xenstore entries for a domain is being
>>> exceeded the operation trying to create a new entry is denied.
>
>>> On 21.03.17 at 18:09, wrote:
> On Tue, Mar 21, 2017 at 11:06 AM, Jan Beulich wrote:
> On 21.03.17 at 17:43, wrote:
>>> On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
>>> On 21.03.17 at 17:30, wrote:
> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
>> Furthermore
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
Signed-off-by: Juergen Gross
---
drivers/input/misc/xen-kbdfront.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/
On Mon, Mar 20, 2017 at 09:00:21AM +0100, Juergen Gross wrote:
> Add a missing allocation failure checks.
s/a//
>
> Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
As my patch tying the resolution of the xen pointing device to that of
the framebuffer wasn't accepted add support for different resolutions
via a module parameter.
Another possibility would be to set parameters via Xenstore, but this
is broken (patch 2 fixes that) and not yet supported by Xen too
Setting the pointing device resolution via Xenstore isn't working
reliably: in case XenbusStateInitWait has been missed the resolution
settings won't be read. Correct this.
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
---
drivers/input/misc/xen-kbdfront.c | 32
On Tue, Mar 21, 2017 at 05:14:47PM +, Wei Liu wrote:
> On Mon, Mar 20, 2017 at 09:00:20AM +0100, Juergen Gross wrote:
> > When the number of permitted xenstore entries for a domain is being
> > exceeded the operation trying to create a new entry is denied.
> > Unfortunately errno isn't being se
On Mon, Mar 20, 2017 at 09:00:20AM +0100, Juergen Gross wrote:
> When the number of permitted xenstore entries for a domain is being
> exceeded the operation trying to create a new entry is denied.
> Unfortunately errno isn't being set in this case so the error code
> returned to the client is unde
On Sun, Mar 19, 2017 at 09:41:09AM -0400, Konrad Rzeszutek Wilk wrote:
> tools/libxc/include/xenctrl.h | 2 +-
> tools/libxc/xc_tmem.c | 52
> +-
Code looks sensible, but there are comments on the hypervisor bits. I
will ack this patch when it is
On Sun, Mar 19, 2017 at 09:41:11AM -0400, Konrad Rzeszutek Wilk wrote:
> The hypervisor code (tmemc_shared_pool_auth) since the inception
> would consider auth values of:
> 0 - to disable authentication!
> 1 - to enable authentication for the given UUID.
>
> The docs have it the other way around
On Sun, Mar 19, 2017 at 09:41:08AM -0400, Konrad Rzeszutek Wilk wrote:
> diff --git a/tools/libxc/xc_tmem.c b/tools/libxc/xc_tmem.c
> index 51d11ef..181de48 100644
> --- a/tools/libxc/xc_tmem.c
> +++ b/tools/libxc/xc_tmem.c
> @@ -385,16 +385,18 @@ static int xc_tmem_restore_new_pool(
>
On Sun, Mar 19, 2017 at 09:41:12AM -0400, Konrad Rzeszutek Wilk wrote:
> A simple
> xl tmem-shared-auth -u --000A--0001 -A 0 0
>
> resulted in uuid_low = 1 (correct) and uuid_high = 0 (umm?).
>
> The issue was that for hex values above 'A' (or 'a') we forgot
> to add 10.
>
Boris Ostrovsky writes:
> On 03/21/2017 10:44 AM, Vitaly Kuznetsov wrote:
>> Vitaly Kuznetsov writes:
>>
>>> Roger Pau Monne writes:
>>>
On Tue, Mar 21, 2017 at 10:21:52AM +0100, Vitaly Kuznetsov wrote:
> Boris Ostrovsky writes:
>
>> On 03/20/2017 02:20 PM, Vitaly Kuznetsov wr
On Tue, Mar 21, 2017 at 11:06 AM, Jan Beulich wrote:
On 21.03.17 at 17:43, wrote:
>> On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
>> On 21.03.17 at 17:30, wrote:
On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
> Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
On Fri, Mar 17, 2017 at 07:43:13PM +0100, Dario Faggioli wrote:
> It being very very basic, also means this scheduler does
> not need much support at the tools level (for now).
>
> Basically, just the definition of the symbol of the
> scheduler itself and a couple of stubs.
>
> Signed-off-by: Dar
>>> On 21.03.17 at 17:43, wrote:
> On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
> On 21.03.17 at 17:30, wrote:
>>> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
supposed to always be available to the guest (as long
On Mon, Mar 20, 2017 at 05:08:21PM +, Paul Durrant wrote:
> Section 2.4.4 of the Hypervisor Top Level Functional Specification states
> that enabling bit 10 in EDX of CPUID leaf 3 advertises to Windows a set
> of MSRs into which it can write crash information.
>
> This patch advertises that bi
On Tue, 21 Mar 2017, Géza Gémes wrote:
> 2017. márc. 21. 0:54 ezt írta ("Stefano Stabellini" ):
> On Sun, 19 Mar 2017, Géza Gémes wrote:
> > Change deb package build in order to symlink the files installed
> > to site-packages to dist-packages to have them inluded in the
> >
On Mon, Mar 20, 2017 at 07:03:11PM +0100, Vitaly Kuznetsov wrote:
>
> @@ -1737,6 +1737,12 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
> state->console_mfn = xs_console_mfn ? atol(xs_console_mfn): 0;
> free(xs_console_mfn);
>
> +xs_console_tty = xs_read(ctx->xsh, XBT_NULL,
>
On Mon, Mar 20, 2017 at 07:03:10PM +0100, Vitaly Kuznetsov wrote:
> Guests with LIBXL_DEVICE_MODEL_VERSION_NONE don't have a device model
> running so there is no save file to rename.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
Acked-by: Wei Liu
___
Xe
>>> On 21.03.17 at 17:44, wrote:
> On 03/21/2017 06:29 PM, Jan Beulich wrote:
> On 21.03.17 at 16:38, wrote:
>>> On 03/15/2017 06:57 PM, Jan Beulich wrote:
>>> On 15.03.17 at 17:46, wrote:
> On 03/15/2017 06:30 PM, Jan Beulich wrote:
> On 15.03.17 at 17:04, wrote:
>>> --
On Mon, Mar 20, 2017 at 04:32:10PM +, Andrew Cooper wrote:
> c/s 4045953 "x86/paging: Enforce PG_external == PG_translate == PG_refcounts"
> in the hypervisor finally prevented the construction of PV autotranslate
> guests.
>
> Remove support for such guests in the domain builder, bailing out
On Tue, 21 Mar 2017, Wei Liu wrote:
> On Wed, Mar 22, 2017 at 12:41:01AM +0800, Zhongze Liu wrote:
> > This allows downstreams to set their defaults without modifying the source
> > code
> > all over the place. Also probably useful for the embedded space.
> > (See Also: https://xenproject.atlassia
flight 106811 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106811/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 5 ker
On 03/21/2017 06:29 PM, Jan Beulich wrote:
On 21.03.17 at 16:38, wrote:
>> On 03/15/2017 06:57 PM, Jan Beulich wrote:
>> On 15.03.17 at 17:46, wrote:
On 03/15/2017 06:30 PM, Jan Beulich wrote:
On 15.03.17 at 17:04, wrote:
>> ---
>> Changes since V1:
>> - Added
>>> On 21.03.17 at 17:41, wrote:
> Changed since v8:
> * Changed the CMDLINE's "depends on EXPERT='y'" into a
> conditional prompt.
I'm not sure why you've sent this - the patch went in 2 hours ago,
and I actually did send you the mail about the problem after fixing
it and having pushed.
J
On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
On 21.03.17 at 17:30, wrote:
>> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
>>> Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
>>> supposed to always be available to the guest (as long as altp2m
>>> is enabled)? You don't all
On Wed, Mar 22, 2017 at 12:41:01AM +0800, Zhongze Liu wrote:
> This allows downstreams to set their defaults without modifying the source
> code
> all over the place. Also probably useful for the embedded space.
> (See Also: https://xenproject.atlassian.net/browse/XEN-41)
>
> If CMDLINE is set, i
This allows downstreams to set their defaults without modifying the source code
all over the place. Also probably useful for the embedded space.
(See Also: https://xenproject.atlassian.net/browse/XEN-41)
If CMDLINE is set, it will be parsed prior to the bootloader command line.
This order of parsi
>>> On 21.03.17 at 17:30, wrote:
> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
>> Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
>> supposed to always be available to the guest (as long as altp2m
>> is enabled)? You don't allow this here anymore.
>
> Absolutely not, that's one of th
2017-03-21 23:22 GMT+08:00 Jan Beulich :
On 21.03.17 at 15:56, wrote:
>> 2017-03-21 22:27 GMT+08:00 Jan Beulich :
>> On 21.03.17 at 12:18, wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -237,4 +237,26 @@ config FAST_SYMBOL_LOOKUP
The only user of
>>> On 21.03.17 at 16:41, wrote:
> No functional change.
The reason it's done the original way is, I guess, that - other than
your title suggests - this is not a macro, and not even an inline
function. In cases where the two checks the function does aren't
needed, I think it is reasonable to avoi
On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
On 20.03.17 at 20:27, wrote:
>> Signed-off-by: Tamas K Lengyel
>> Signed-off-by: Sergej Proskurin
>> Acked-by: Jan Beulich
>
> I'll need to make this conditional upon a few more adjustments:
>
>> @@ -4370,18 +4370,19 @@ static int do_alt
>>> On 21.03.17 at 16:38, wrote:
> On 03/15/2017 06:57 PM, Jan Beulich wrote:
> On 15.03.17 at 17:46, wrote:
>>> On 03/15/2017 06:30 PM, Jan Beulich wrote:
>>> On 15.03.17 at 17:04, wrote:
> ---
> Changes since V1:
> - Added Andrew Cooper's credit, as he's kept the patch cur
>>> On 21.03.17 at 16:45, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 21 March 2017 15:29
>> To: Paul Durrant
>> Cc: Andrew Cooper ; xen-
>> de...@lists.xenproject.org
>> Subject: Re: [PATCH v2 2/6] x86/viridian: don't put Xen version informatio
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 March 2017 15:33
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 4/6] x86/viridian: add warnings for unimplemented
> hypercalls and MSRs
>
> >>> On 20.03.17 a
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 March 2017 15:36
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 5/6] x86/viridian: make the threshold for
> HvNotifyLongSpinWait tunable
>
> >>> On 20.03.17
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 March 2017 15:42
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; Ian Jackson ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 6/6] x86/viridian: implement the crash MSRs
>
> >>> On 20.03.17 at
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 March 2017 15:29
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 2/6] x86/viridian: don't put Xen version information in
> CPUID leaf 2
>
> >>> On 20.03.17 at
>>> On 20.03.17 at 18:08, wrote:
> @@ -619,6 +636,36 @@ int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
> update_reference_tsc(d, 1);
> break;
>
> +case HV_X64_MSR_CRASH_P0:
> +case HV_X64_MSR_CRASH_P1:
> +case HV_X64_MSR_CRASH_P2:
> +case HV_X64_MSR_CRA
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 2 +-
xen/drivers/passthrough/io.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 028298
On 03/21/2017 05:38 PM, Razvan Cojocaru wrote:
> On 03/15/2017 06:57 PM, Jan Beulich wrote:
> On 15.03.17 at 17:46, wrote:
>>> On 03/15/2017 06:30 PM, Jan Beulich wrote:
>>> On 15.03.17 at 17:04, wrote:
> ---
> Changes since V1:
> - Added Andrew Cooper's credit, as he's kept
On 03/15/2017 06:57 PM, Jan Beulich wrote:
On 15.03.17 at 17:46, wrote:
>> On 03/15/2017 06:30 PM, Jan Beulich wrote:
>> On 15.03.17 at 17:04, wrote:
---
Changes since V1:
- Added Andrew Cooper's credit, as he's kept the patch current
througout non-trivial code ch
>>> On 20.03.17 at 18:08, wrote:
> The current threshold before the guest issues the hypercall is, and always
> has been, hard-coded to 2047. It is not clear where this number came
> from so, to at least allow for ease of experimentation, this patch makes
> the threshold tunable via the Xen comman
>>> On 20.03.17 at 18:08, wrote:
> Currently use of xen-hvmcrash will cause an immediate domain_crash() in
> initialize_vp_assist() because it is called from viridian_load_vcpu_ctxt()
> without having first cleared any previous mapping.
>
> This patch addes a check into viridian_load_vcpu_ctxt()
>>> On 20.03.17 at 18:08, wrote:
> These warnings can be useful when Microsoft updates Windows.
>
> In the past there have been several cases when Windows erroneously uses
> hypercalls and MSRs that should be gated on CPUID flags than Xen does
> not set. The usual symptom is a guest crash with li
>>> On 20.03.17 at 18:08, wrote:
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -106,6 +106,21 @@ typedef struct {
> #define CPUID6A_MSR_BITMAPS (1 << 1)
> #define CPUID6A_NESTED_PAGING (1 << 3)
>
> +/*
> + * Version and build number reported by CPUID leaf 2
>>> On 20.03.17 at 18:08, wrote:
> The numbers correspond to ASCII characters so just use appropriate
> character strings directly.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https:/
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 March 2017 15:27
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 1/6] x86/viridian: fix xen-hvmcrash when vp_assist
> page is present
>
> >>> On 20.03.17 at 1
>>> On 21.03.17 at 15:56, wrote:
> 2017-03-21 22:27 GMT+08:00 Jan Beulich :
> On 21.03.17 at 12:18, wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -237,4 +237,26 @@ config FAST_SYMBOL_LOOKUP
>>> The only user of this is Live patching.
>>>
>>> If unsure
>>> On 19.03.17 at 14:41, wrote:
> Having an off by default option allowing guests to join
> _any_ shared pool is not very secure.
>
> Lets eliminate tmem_shared_auth bootup option (which
> was disabled by default) and have the code force this by default.
>
> Signed-off-by: Konrad Rzeszutek Wilk
1 - 100 of 195 matches
Mail list logo
