> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 07 December 2018 15:26
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v2 03
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 07 December 2018 15:58
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v2 05
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
b/drivers/gpu/drm/xen/xen_drm_front_conn
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. And indeed, all atomic drivers are now free of
drm_crtc_h
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. And indeed, all atomic drivers are now free of
drm_crtc_h
On 12/10/18 12:03 PM, Daniel Vetter wrote:
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_c
From: Talons Lee
Commit e657fcc clears cpu capability bit instead of using fake cpuid
value, the EXTD should always be off for PV guest without depending
on cpuid value. So remove the cpuid check in xen_read_msr_safe() to
always clear the X2APIC_ENABLE bit.
Signed-off-by: Talons Lee
Reviewed-by
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 out.
>
> To make sure I actually achieved the goal here I went throu
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 I
Hello All,
On 27.11.18 23:27, Stefano Stabellini wrote:
See the following:
https://marc.info/?l=xen-devel&m=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 li
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 to
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 out
> -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, Paul
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
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),
>>> 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 root=UUID=f4dcb7e6
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 s
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 physica
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 paramet
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
-
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
u
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. The
(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&m=148668817704668
> So I did port that stuff to the current staging [1].
> Also, the corresponde
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 disc
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 is
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 tells
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 a/docs/Makef
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 renderin
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. And
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
test-amd64-
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
https://lists.xenproject.org
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 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.
>
> --- a/xen/arch/x86/x86_emulate/x
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 o
>>> 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 gues
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 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 ca
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 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: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 ar
>>> 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 #
* 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 unsigned
>>> 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.
> Havin
>>> 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 cha
>>> 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 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/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 my
>>> 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 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 need
>>> 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 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 '%' c
>>> 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 host
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 1
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
>> X
> -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
> regis
> -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
>
> > -Origin
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 requeste
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 0dd5eaec5f
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
> initiali
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 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
>> > vlapic_reg_w
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 b/arch/x86/xen/xen-asm_64.
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.
>
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 do
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 fe1d52247bbe..262
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) r
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
https
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(), which
>>> 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 t
> -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 14
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
> wor
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 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 supp
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 16bi
>>> 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 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 m
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, c
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 win
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 PCID
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.
>
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 vm_event_emulate_ch
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 object_apply_global_pr
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
>> +++ b/xen/include/asm-arm/vm_eve
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
u
>>> 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 afte
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 /proc/cp
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
> wor
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] https://xenbits.xen.org/do
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
__
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
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 1
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
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
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. Mo
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 hy
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 first step in that direction is to create a new file that will
eventually hold the Xen specific routines.
Signed-off-by: Maran Wilson
Reviewed-by: Juergen Gross
---
arch/x86/pla
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: Ma
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
1 - 100 of 109 matches
Mail list logo
