All,
I am pleased to announce the release of Xen 4.8.5. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8
(tag RELEASE-4.8.5) or from the XenProject download page
All,
I am pleased to announce the release of Xen 4.11.1. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.11
(tag RELEASE-4.11.1) or from the XenProject download page
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, December 11, 2018 1:13 AM
>
> Ping Kevin / Jun.
>
> On 16/10/2018 19:54, Andrew Cooper wrote:
> > Hello,
> >
> > I realise this is an old CPU, but I've I've encountered a weird failure
> > on it.
> >
> > Specifically:
> >
On Sun, 9 Dec 2018, Borislav Petkov wrote:
> On Mon, Dec 03, 2018 at 11:23:49AM +, Andrew Cooper wrote:
> > Right, but the documentation also states that where it says package, it
> > means "Node" in AMD's terminology, and the information in CPUID is per
> > socket, not per node.
> >
> > My
On 12/10/18 6:52 AM, Andrew Cooper wrote:
> The intention of this patch was to remove the calls to nsvm_{rd,wr}msr() from
> the default cases of svm_msr_{read,write}_intercept(), but it has turned into
> a more corrective patch than just code motion.
>
> First, collect the VM_CR bit definitions
flight 131183 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131183/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 131070
test-armhf-armhf-libvirt 14
flight 131172 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131172/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129996
test-armhf-armhf-libvirt 14
From: Yangtao Li
Date: Mon, 10 Dec 2018 10:53:29 -0500
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li
Applied.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 131212 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131212/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.
Signed-off-by:
Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests.
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
In order to pave the way for hypervisors other than Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from
flight 131210 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131210/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 131168 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131168/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 131130
test-amd64-i386-xl-qemut-win7-amd64 17
On Mon, Dec 10, 2018 at 01:00:49PM +, Anthony PERARD wrote:
> With pandoc 2.5, the man/xen-vbd-interface.markdown.7 isn't detected as
> markdown and the output isn't formated. Add the format of the input to
> pandoc's command line.
>
> Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
On Mon, Dec 10, 2018 at 01:00:48PM +, Anthony PERARD wrote:
> In pandoc's markdown, a code block needs at least 4 spaces to be
> recognize as such. This patch fix the rendering of description of the
> encoding in the VBD interface so that [1] can be readable.
>
> [1]
On Mon, Dec 10, 2018 at 05:04:26PM +, Andrew Cooper wrote:
> See the code comment for a full discussion, but in short: guests which
> currently run under Xen don't move the window, because moving it has never
> worked properly. Implementing support for moving the window is never going to
>
Ping Kevin / Jun.
On 16/10/2018 19:54, Andrew Cooper wrote:
> Hello,
>
> I realise this is an old CPU, but I've I've encountered a weird failure
> on it.
>
> Specifically:
>
> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 23 (0x17), Stepping 6
> (raw 00010676)
> [root@harpertown ~]# head
>>> On 10.12.18 at 17:44, wrote:
> Does setting pcid=0 leave me increasingly vulnerable to Meltdown
> and/or negatively impact performance?
I don't think there's any vulnerability concern with disabling use
of PCID. On hardware without the feature we consider ourselves
sufficiently mitigated
See the code comment for a full discussion, but in short: guests which
currently run under Xen don't move the window, because moving it has never
worked properly. Implementing support for moving the window is never going to
work architecturally unless we switch to per-vcpu P2Ms (which seems very
On 12/10/18 6:49 PM, Roger Pau Monné wrote:
> On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
>> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
>> index 66f2474..b63249e 100644
>> --- a/xen/include/asm-arm/vm_event.h
>> +++
On Mon, 10 Dec 2018 17:45:22 +0100
Igor Mammedov wrote:
> On Tue, 4 Dec 2018 18:20:11 +0400
> Marc-André Lureau wrote:
>
> > Instead of registering compat properties as globals, let's keep them
> > in their own array, to avoid mixing with user globals.
> >
> > Introduce
On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
> index 66f2474..b63249e 100644
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -52,4 +52,10 @@ void
On Tue, 4 Dec 2018 18:20:11 +0400
Marc-André Lureau wrote:
> Instead of registering compat properties as globals, let's keep them
> in their own array, to avoid mixing with user globals.
>
> Introduce object_apply_global_props() function, to apply compatibility
> properties from a GPtrArray.
>
Hi Jan,
On Mon, Dec 10, 2018 at 09:29:34AM -0700, Jan Beulich wrote:
> >>> On 10.12.18 at 16:58, wrote:
> > Are there any other hypervisor command line options that would be
> > beneficial to set for next time?
>
> Well, just like for your report from a couple of weeks ago - if this is
> on
On Mon, Dec 10, 2018 at 04:20:07PM +, Andrew Cooper wrote:
> On 10/12/2018 16:14, Roger Pau Monné wrote:
> > On Mon, Dec 10, 2018 at 11:45:13AM +, Andrew Cooper wrote:
> >> See the code comment for a full discussion, but in short: guests which
> >> currently run under Xen don't move the
On 12/7/18 6:15 PM, David Woodhouse wrote:
>
> - load_TLS_descriptor(t, cpu, 0);
> - load_TLS_descriptor(t, cpu, 1);
> - load_TLS_descriptor(t, cpu, 2);
> + load_TLS_descriptor(t, cpu, 0, flush_gs);
> + load_TLS_descriptor(t, cpu, 1, flush_gs);
> + load_TLS_descriptor(t,
> On Dec 10, 2018, at 9:11 AM, Wei Liu wrote:
>
> We skipped build stage for those branches. We want to skip test state
> for those branches too.
>
> Signed-off-by: Wei Liu
Thanks for taking care of this.
Acked-by: Doug Goldstein
___
Xen-devel
>>> On 10.12.18 at 16:58, wrote:
> Are there any other hypervisor command line options that would be
> beneficial to set for next time?
Well, just like for your report from a couple of weeks ago - if this is
on PCID/INVPCID capable hardware, have you tried disabling use
of PCID?
Jan
On 10/12/2018 16:01, Jan Beulich wrote:
On 07.12.18 at 21:07, wrote:
>> By default on capable hardware, SECONDARY_EXEC_ENABLE_VMCS_SHADOWING is
>> activated unilaterally. The VMCS Link pointer is initialised to ~0, but the
>> VMREAD/VMWRITE bitmap pointers are not.
>>
>> This causes the
On 10/12/2018 16:14, Roger Pau Monné wrote:
> On Mon, Dec 10, 2018 at 11:45:13AM +, Andrew Cooper wrote:
>> See the code comment for a full discussion, but in short: guests which
>> currently run under Xen don't move the window, because moving it has never
>> worked properly. Implementing
flight 131188 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
On Mon, Dec 10, 2018 at 11:45:13AM +, Andrew Cooper wrote:
> See the code comment for a full discussion, but in short: guests which
> currently run under Xen don't move the window, because moving it has never
> worked properly. Implementing support for moving the window is never going to
>
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 07 December 2018 18:21
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Kevin Wolf ; Max Reitz
> Subject: Re: [PATCH v2
>>> On 07.12.18 at 21:07, wrote:
> By default on capable hardware, SECONDARY_EXEC_ENABLE_VMCS_SHADOWING is
> activated unilaterally. The VMCS Link pointer is initialised to ~0, but the
> VMREAD/VMWRITE bitmap pointers are not.
>
> This causes the 16bit IVT and Bios Data Area get interpreted as
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for single-stepping). Otherwise, attempting
to emulate an instruction when requested by a vm_event
reply may legitimately need to call e.g.
hvm_inject_page_fault(),
On Mon, Dec 10, 2018 at 10:53:29AM -0500, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li
Acked-by: Wei Liu
Thanks for the patch.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hi,
Up front information:
Today one of my Xen hosts crashed with this logging on the serial:
(XEN) [ Xen-4.10.1 x86_64 debug=n Not tainted ]
(XEN) CPU:15
(XEN) RIP:e008:[] guest_4.o#shadow_set_l1e+0x75/0x6a0
(XEN) RFLAGS: 00010246 CONTEXT: hypervisor (d31v1)
(XEN)
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
---
drivers/net/xen-netback/xenbus.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index
On 10/12/2018 14:22, Jan Beulich wrote:
On 07.12.18 at 14:45, wrote:
>> Adjust the default line to note that the default is now selectable in
>> Kconfig.
>>
>> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beulich
Thanks.
> with one remark:
>
>> @@ -2180,3 +2164,19 @@ for dom0 or guest
On Fri, Dec 07, 2018 at 01:45:44PM +, Andrew Cooper wrote:
> * vwfi needs a closing `. rmrr needs one as well, and the opening ' switched
>to `
> * The com1/com2 example lines are already verbatim blocks and shouldn't
>escape their underscores. This ends up in the rendered output.
Blacklist symbols in Xen probe-prohibited areas, so that user can see
these prohibited symbols in debugfs.
See also: a50480cb6d61.
Signed-off-by: Andrea Righi
---
arch/x86/xen/xen-asm_64.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/xen/xen-asm_64.S
>>> On 10.12.18 at 15:57, wrote:
>> From: Paul Durrant
>> Sent: 10 December 2018 14:57
>>
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 10 December 2018 13:44
>> >
>> > >>> On 07.12.18 at 18:50, wrote:
>> > > The code in viridian_synic_wrmsr() duplicates logic in
>> >
Juergen Gross writes ("Re: [PATCH 0/7] docs: Fix support matrix release notes
link"):
> On 03/12/2018 13:16, Ian Jackson wrote:
> > The only part of this that needs to be backported is the part to
> > change the syntax in SUPPORT.md, but we do need to wait for the other
> > changes to hit master.
On Fri, Dec 07, 2018 at 12:18:04PM +0800, Dongli Zhang wrote:
> The xenstore 'ring-page-order' is used globally for each blkback queue and
> therefore should be read from xenstore only once. However, it is obtained
> in read_per_ring_refs() which might be called multiple times during the
>
We skipped build stage for those branches. We want to skip test state
for those branches too.
Signed-off-by: Wei Liu
---
automation/gitlab-ci/test.yaml | 10 ++
1 file changed, 10 insertions(+)
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index
On 12/10/18 4:32 PM, Jan Beulich wrote:
On 08.12.18 at 21:48, wrote:
>> Block interrupts (in vmx_intr_assist()) for the duration of
>> processing a sync vm_event (similarly to the strategy
>> currently used for single-stepping). Otherwise, attempting
>> to emulate an instruction when
> -Original Message-
> From: Paul Durrant
> Sent: 10 December 2018 14:57
> To: 'Jan Beulich'
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/hvm/viridian: stop open coding updates to APIC
> registers
>
> >
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 December 2018 13:44
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH] x86/hvm/viridian: stop open coding updates to APIC
>
On 10/12/2018 15:45, Jan Beulich wrote:
On 10.12.18 at 12:44, wrote:
>> Today the memory size of dom0 can be specified only in terms of bytes
>> (either an absolute value or "host-mem - value"). When dom0 shouldn't
>> be auto-ballooned this requires nearly always a manual adaption of the
>>
flight 131207 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131207/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
>>> On 10.12.18 at 12:44, wrote:
> Today the memory size of dom0 can be specified only in terms of bytes
> (either an absolute value or "host-mem - value"). When dom0 shouldn't
> be auto-ballooned this requires nearly always a manual adaption of the
> Xen boot parameters to reflect the actual
>>> On 10.12.18 at 12:44, wrote:
> Modify parse_size_and_unit() to support a value followed by a '%'
> character. In this case ps is required to be non-NULL to ensure the
> caller can detect that case. The returned value will be the integer
> value s was pointing to and *ps will point to the '%'
>>> On 10.12.18 at 15:26, wrote:
> On 10/12/2018 14:11, Jan Beulich wrote:
> On 10.12.18 at 14:50, wrote:
>>> On 07/12/2018 11:17, Jan Beulich wrote:
The check needs to happen whenever EVEX.b is clear, not just in the
memory operand case.
>>> EVEX.b is a different field to EVEX.br
>>> On 08.12.18 at 21:48, wrote:
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an instruction when requested by a vm_event
> reply may legitimately
On 10/12/2018 14:11, Jan Beulich wrote:
On 10.12.18 at 14:50, wrote:
>> On 07/12/2018 11:17, Jan Beulich wrote:
>>> The check needs to happen whenever EVEX.b is clear, not just in the
>>> memory operand case.
>> EVEX.b is a different field to EVEX.br
>>
>> I'm afraid that this goes back to
>>> On 07.12.18 at 14:45, wrote:
> A large amount of the information here is obsolete since Xen 4.7
>
> To being with, however, this patch marks a change in style for section
> headings, due to how HTML anchors are generated. Having more than one
> parameter per heading makes an awkward anchor,
>>> On 07.12.18 at 14:45, wrote:
> Adjust the default line to note that the default is now selectable in
> Kconfig.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
with one remark:
> @@ -2180,3 +2164,19 @@ for dom0 or guest domains only.
> > Default: `true`
>
> Permit use of the
>>> On 10.12.18 at 15:06, wrote:
> * Add "uint64_t raw" to seg_desc_t to remove the opencoded uint64_t casting
>in this function. Change the parameter to be of type seg_desc_t.
> * Rename the 'pa' parameter to 'gaddr', because it lives in GFN space rather
>than physical address space.
>>> On 10.12.18 at 15:00, wrote:
> On 07/12/2018 11:18, Jan Beulich wrote:
>> While actually benign (operands are either register or memory ones
>> anyway), I think it is better to use != instead of == for such checks.
>>
>> Signed-off-by: Jan Beulich
>
> I don't see the point of making this
>>> On 10.12.18 at 14:50, wrote:
> On 07/12/2018 11:17, Jan Beulich wrote:
>> The check needs to happen whenever EVEX.b is clear, not just in the
>> memory operand case.
>
> EVEX.b is a different field to EVEX.br
>
> I'm afraid that this goes back to my original concern with the series.
>
* Add "uint64_t raw" to seg_desc_t to remove the opencoded uint64_t casting
in this function. Change the parameter to be of type seg_desc_t.
* Rename the 'pa' parameter to 'gaddr', because it lives in GFN space rather
than physical address space.
* Use gfn_t and mfn_t rather than
>>> On 10.12.18 at 14:28, wrote:
> On 10/12/2018 11:32, Jan Beulich wrote:
>> In commit efe9cba66c ("x86emul: VME and PVI modes require a #GP(0) check
>> first thing") I neglected the fact that the retire flags get zapped only
>> in x86_decode(), which hasn't been invoked yet at the point of the
On 07/12/2018 11:18, Jan Beulich wrote:
> While actually benign (operands are either register or memory ones
> anyway), I think it is better to use != instead of == for such checks.
>
> Signed-off-by: Jan Beulich
I don't see the point of making this change. Code is easier to follow
when there
>>> On 10.12.18 at 14:20, wrote:
> On 10/12/2018 11:32, Jan Beulich wrote:
>> The avx512_vlen_check() invocation needs to be conditional.
>>
>> Signed-off-by: Jan Beulich
>
> I'm not sure if I've asked before, but do LIG instructions really #UD
> for L=3 ? I don't see any documentation to this
On 07/12/2018 11:17, Jan Beulich wrote:
> The check needs to happen whenever EVEX.b is clear, not just in the
> memory operand case.
EVEX.b is a different field to EVEX.br
I'm afraid that this goes back to my original concern with the series.
Having the fields named differently between our code
>>> On 07.12.18 at 18:50, wrote:
> The code in viridian_synic_wrmsr() duplicates logic in vlapic_reg_write()
> to update the ICR, ICR2 and TASKPRI registers. Instead of doing this,
> make vlapic_reg_write() non-static and call it.
There's a side effect from this change, which I think should be
Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
a écrit :
>
> Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> a écrit :
> >
> > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > > Having the probe helper stuff (which pretty much everyone needs) in
> > > the drm_crtc_helper.h file
>>> On 10.12.18 at 01:01, wrote:
> flight 131151 xen-4.10-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/131151/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-ws16-amd64 17
On 10/12/2018 11:32, Jan Beulich wrote:
> In commit efe9cba66c ("x86emul: VME and PVI modes require a #GP(0) check
> first thing") I neglected the fact that the retire flags get zapped only
> in x86_decode(), which hasn't been invoked yet at the point of the #GP(0)
> check added.
>
> Ahead of the
On 10/12/2018 11:32, Jan Beulich wrote:
> The avx512_vlen_check() invocation needs to be conditional.
>
> Signed-off-by: Jan Beulich
I'm not sure if I've asked before, but do LIG instructions really #UD
for L=3 ? I don't see any documentation to this effect.
>
> ---
On Thu, Dec 06, 2018 at 02:39:23PM +0100, Juergen Gross wrote:
> Don't call xen_be_set_max_grant_refs() in usbback_alloc(), as the
> gnttabdev pointer won't be initialised yet. The call can easily be
> moved to usbback_connect().
Added to usb queue.
thanks,
Gerd
On Fri, Nov 30, 2018 at 08:23:26PM +, Kirill A. Shutemov wrote:
> There's a couple fixes for the recent LDT remap placement change.
Ping?
--
Kirill A. Shutemov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 131163 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 129313
On 10/12/2018 11:11, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers.
With pandoc 2.5, the man/xen-vbd-interface.markdown.7 isn't detected as
markdown and the output isn't formated. Add the format of the input to
pandoc's command line.
Signed-off-by: Anthony PERARD
---
docs/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
In pandoc's markdown, a code block needs at least 4 spaces to be
recognize as such. This patch fix the rendering of description of the
encoding in the VBD interface so that [1] can be readable.
[1] https://xenbits.xen.org/docs/unstable/man/xen-vbd-interface.7.html
Signed-off-by: Anthony PERARD
The generated output at
https://xenbits.xen.org/docs/unstable/man/xen-vbd-interface.7.html
isn't readable. And generating it with a newer version (I guess) of
pandoc is even less readable.
Cheers,
Anthony PERARD (2):
docs: Fix output of man/xen-vbd-interface
docs: Specify format when
Hello Julien,
On 10.12.18 13:54, Julien Grall wrote:
What are the numbers without Xen?
Good question. Didn't try. At least putchar should be implemented for that.
Which version of Xen are you using?
This morning's staging, commit-id 58eb90a9650a8ea73533bc2b87c13b8ca7bbe35a.
This also
On 12/10/18 12:12 PM, George Dunlap wrote:
> On 12/7/18 6:40 PM, Wei Liu wrote:
>> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>>> Hello,
>>>
>>> This is an accumulation and summary of various tasks which have been
>>> discussed since the revelation of the speculative security
On 12/7/18 6:40 PM, Wei Liu wrote:
> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>> Hello,
>>
>> This is an accumulation and summary of various tasks which have been
>> discussed since the revelation of the speculative security issues in
>> January, and also an invitation to
(sorry for the formatting)
On Mon, 10 Dec 2018, 12:00 Andrii Anisov, wrote:
> Hello All,
>
> On 27.11.18 23:27, Stefano Stabellini wrote:
> > See the following:
> >
> > https://marc.info/?l=xen-devel=148668817704668
> So I did port that stuff to the current staging [1].
> Also, the
The intention of this patch was to remove the calls to nsvm_{rd,wr}msr() from
the default cases of svm_msr_{read,write}_intercept(), but it has turned into
a more corrective patch than just code motion.
First, collect the VM_CR bit definitions next to the main define, and simplify
the naming.
See the code comment for a full discussion, but in short: guests which
currently run under Xen don't move the window, because moving it has never
worked properly. Implementing support for moving the window is never going to
work architecturally unless we switch to per-vcpu P2Ms (which seems very
Modify parse_size_and_unit() to support a value followed by a '%'
character. In this case ps is required to be non-NULL to ensure the
caller can detect that case. The returned value will be the integer
value s was pointing to and *ps will point to the '%' character.
Signed-off-by: Juergen Gross
With being able to specify a dom0_mem value depending on host memory
size on x86 make it easy for distros to specify a default dom0 size by
adding a CONFIG_DOM0_MEM item which presets the dom0_mem boot parameter
value.
It will be used only if no dom0_mem parameter was specified in the
boot
Today the memory size of dom0 can be specified only in terms of bytes
(either an absolute value or "host-mem - value"). When dom0 shouldn't
be auto-ballooned this requires nearly always a manual adaption of the
Xen boot parameters to reflect the actual host memory size.
Add more possibilities to
Setting the memory size of dom0 on a server for the non autoballooning
case requires always specification of a boot parameter today. The value
to set will depend mostly on the host memory size.
In order to support that scenario add the possibility to set dom0_mem
depending on the amount of
>>> On 08.12.18 at 02:01, wrote:
>> > > Without a full hypervisor log this is going to remain guesswork, but
>> > > could you check whether "pcid=no" and/or "pv-l1tf=no" on the Xen
>> > > boot command line help?
>> >
>> > [vagrant@localhost ~]$ cat /proc/cmdline
>> > placeholder
The avx512_vlen_check() invocation needs to be conditional.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6179,7 +6179,8 @@ x86_emulate(
evex.w != evex.pfx),
In commit efe9cba66c ("x86emul: VME and PVI modes require a #GP(0) check
first thing") I neglected the fact that the retire flags get zapped only
in x86_decode(), which hasn't been invoked yet at the point of the #GP(0)
check added.
Ahead of the other explicit return (rather than "goto") path use
> -Original Message-
> From: Andrew Cooper
> Sent: 10 December 2018 11:04
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Wei Liu ; Roger
> Pau Monne
> Subject: Re: [PATCH] x86/hvm/viridian: stop open coding updates to APIC
> registers
>
> On 08/12/2018 11:34,
Le lun. 10 déc. 2018 à 11:24, Thierry Reding
a écrit :
>
> On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > Having the probe helper stuff (which pretty much everyone needs) in
> > the drm_crtc_helper.h file (which atomic drivers should never need) is
> > confusing. Split them
On 08/12/2018 11:34, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 07 December 2018 18:23
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich ; Wei Liu ; Roger
>> Pau Monne
>> Subject: Re: [PATCH] x86/hvm/viridian: stop open coding updates
Hello All,
On 27.11.18 23:27, Stefano Stabellini wrote:
See the following:
https://marc.info/?l=xen-devel=148668817704668
So I did port that stuff to the current staging [1].
Also, the correspondent tbm, itself is here [2].
Having 4 big cores on my SoC I run XEN with the following command
On Thu, Dec 06, 2018 at 12:42:15PM +, Wei Liu wrote:
> On Wed, Dec 05, 2018 at 03:55:00PM +0100, Roger Pau Monne wrote:
> > Current approximation of paging memory usage is based on the required
> > amount when running in shadow mode and doesn't take into account the
> > memory required by the
1 - 100 of 108 matches
Mail list logo