On 18.12.2019 21:40, Tamas K Lengyel wrote:
> Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
> when the mem_access permission is being set on a page that has not yet been
> copied over from the parent.
>
> Signed-off-by: Tamas K Lengyel Isaila
> ---
> xen/arch/x
> -Original Message-
> From: Wei Liu
> Sent: 18 December 2019 22:21
> To: Michael Kelley
> Cc: Durrant, Paul ; Wei Liu ; Xen
> Development List ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
> ; Roger Pau Monné
> Subject: Re: [PATCH v2 6/6] x86: implement Hyper-V clock source
>
> On Wed, 18
> -Original Message-
> From: Xen-devel On Behalf Of
> Andrew Cooper
> Sent: 18 December 2019 19:45
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>
> Subject: Re: [Xen-devel] [PATCH] x86/save: reserve HVM save record numbers
> that have
This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.
Requested-by: Jan Beulich
Signed-off-by: Alexandru Isaila
---
CC: Razvan Cojocaru
CC: Tamas K Lengyel
CC: Petre Pircalabu
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
C
Requested-by: Jan Beulich
Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
---
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/arch/x86/mm/p2m-ept.c | 6 --
xen/arch/x86/mm/p2m.c | 6 ++
2
By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not brake in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for co
At this moment the default_access param from xc_altp2m_create_view is
not used.
This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.
Signed-off-by: Alexandru Isaila
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
CC:
On Wed, Dec 18, 2019 at 11:40:37AM -0800, Tamas K Lengyel wrote:
> The following series implements VM forking for Intel HVM guests to allow for
> the fast creation of identical VMs without the assosciated high startup costs
> of booting or restoring the VM from a savefile.
>
> JIRA issue: https://
flight 144958 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144958/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144920
test-armhf-armhf-libvirt-raw 13 saveresto
On 18.12.2019 18:09, Lars Kurth wrote:
>
>
> On 18/12/2019, 14:29, "Julien Grall" wrote:
>
> Hi Lars,
>
> On 12/12/2019 21:14, Lars Kurth wrote:
> > +### Workflow from an Author's Perspective
> > +
> > +When code authors receive feedback on their patches, they typicall
> On 19 Dec 2019, at 09:56, Jan Beulich wrote:
>
> On 18.12.2019 18:09, Lars Kurth wrote:
>>
>>
>> On 18/12/2019, 14:29, "Julien Grall" wrote:
>>
>>Hi Lars,
>>
>>On 12/12/2019 21:14, Lars Kurth wrote:
>>> +### Workflow from an Author's Perspective
>>> +
>>> +When code authors rece
On 18.12.2019 17:09, Paul Durrant wrote:
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -639,10 +639,12 @@ struct hvm_msr {
>
> #define CPU_MSR_CODE 20
>
> +/* Range 22 - 40 reserved for Amazon */
> +
> /*
> * Largest type-code in use
>
On 19.12.2019 10:42, Alexandru Stefan ISAILA wrote:
> This patch aims to sanitize indexes, potentially guest provided
> values, for altp2m_eptp[] and altp2m_p2m[] arrays.
>
> Requested-by: Jan Beulich
> Signed-off-by: Alexandru Isaila
> ---
> CC: Razvan Cojocaru
> CC: Tamas K Lengyel
> CC: Pet
On 19.12.2019 10:42, Alexandru Stefan ISAILA wrote:
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -46,6 +46,16 @@ struct xen_hvm_altp2m_suppress_ve {
> uint64_t gfn;
> };
>
> +struct xen_hvm_altp2m_suppress_ve_multi {
> +uint16_t view;
> +uint8
On 19/12/2019 08:52, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of
>> Andrew Cooper
>> Sent: 18 December 2019 19:45
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>>
>> Subject: Re: [Xen-devel] [PATCH] x86/
> -Original Message-
> From: Jan Beulich
> Sent: 19 December 2019 10:33
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: Re: [PATCH] x86/save: reserve HVM save record numbers that have
> been consumed...
>
> On 18.12.2019
On 19.12.2019 01:15, Tamas K Lengyel wrote:
> On Wed, Dec 18, 2019 at 4:02 PM Julien Grall wrote:
>> On 18/12/2019 22:33, Tamas K Lengyel wrote:
>>> On Wed, Dec 18, 2019 at 3:00 PM Julien Grall wrote:
You also have multiple loop on the page_list in this function. Given the
number of pag
> -Original Message-
> From: Andrew Cooper
> Sent: 19 December 2019 10:52
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>
> Subject: Re: [Xen-devel] [PATCH] x86/save: reserve HVM save record numbers
> that have been consumed...
>
> On
On 19.12.2019 11:03, Lars Kurth wrote:
>
>
>> On 19 Dec 2019, at 09:56, Jan Beulich wrote:
>>
>> On 18.12.2019 18:09, Lars Kurth wrote:
>>>
>>>
>>> On 18/12/2019, 14:29, "Julien Grall" wrote:
>>>
>>>Hi Lars,
>>>
>>>On 12/12/2019 21:14, Lars Kurth wrote:
+### Workflow from an Autho
On 19.12.2019 12:06, Durrant, Paul wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 19 December 2019 10:52
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>>
>> Subject: Re: [Xen-devel] [PATCH] x86/save: reserve HVM save rec
On 18/12/2019 19:40, Tamas K Lengyel wrote:
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 5a3a962fbb..1e888b403b 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1902,12 +1902,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
>
On 19.12.2019 04:49, Marek Marczykowski-Górecki wrote:
> +enum interrupt_type xen_pcibk_get_interrupt_type(struct pci_dev *dev)
> +{
> + int err;
> + u16 val;
> +
> + err = pci_read_config_word(dev, PCI_COMMAND, &val);
> + if (err)
> + return INTERRUPT_TYPE_ERR;
> +
On 18/12/2019 11:06, Jan Beulich wrote:
> On 17.12.2019 16:46, Sergey Dyasli wrote:
>> Hide the following information that can help identify the running Xen
>> binary version:
>>
>> XENVER_extraversion
>> XENVER_compile_info
>> XENVER_capabilities
>
> What's wrong with exposing this on
On 18.12.2019 15:41, Paul Durrant wrote:
> The emulated RTC is synchronized with the PV wallclock; any write to the
> RTC will update struct domain's 'time_offset_seconds' field and call
> update_domain_wallclock().
>
> However, the value of 'time_offset_seconds' is not preserved in any save
> rec
On 19/12/2019 11:06, Durrant, Paul wrote:
>> It is not fair or reasonable to include extra headroom in a "oh dear we
>> screwed up - will the community be kind enough to help us work around
>> our ABI problems" scenario.
>>
> I would have thought all the pain you went through to keep XenServer goin
On 19.12.2019 12:23, Sergey Dyasli wrote:
> On 18/12/2019 11:06, Jan Beulich wrote:
>> On 17.12.2019 16:46, Sergey Dyasli wrote:
>>> Hide the following information that can help identify the running Xen
>>> binary version:
>>>
>>> XENVER_extraversion
>>> XENVER_compile_info
>>> XENVER_c
Lars Kurth writes ("Re: [PATCH v3 5/7] Add Code Review Guide"):
> In a nutshell, in such a review the possible interpretations are
> * I reviewed, but didn't feel qualified to do the rest
> * I reviewed, but did not get round to give it full attention
> * I reviewed, but before I make a final decis
> -Original Message-
> From: Jan Beulich
> Sent: 19 December 2019 11:30
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Julien Grall ; Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap ; Ian Jackson
> ; Konrad Rzeszutek Wilk
> ; Wei Liu ; Roger Pau Mon
Ian Jackson writes ("Re: [PATCH v3 5/7] Add Code Review Guide"):
> Lars Kurth writes ("Re: [PATCH v3 5/7] Add Code Review Guide"):
> > In a nutshell, in such a review the possible interpretations are
> > * I reviewed, but didn't feel qualified to do the rest
> > * I reviewed, but did not get round
> -Original Message-
> From: Andrew Cooper
> Sent: 19 December 2019 11:30
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>
> Subject: Re: [Xen-devel] [PATCH] x86/save: reserve HVM save record numbers
> that have been consumed...
>
> On
flight 144962 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144962/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 95bb203861c5e19b7b7d5d9318e16d82108f2134
baseline version:
ovmf c7a0aca0ed0e9b51efe0c
...for patches not (yet) upstream.
This patch is simply adding a comment to reserve save record number space
to avoid the risk of clashes between existent downstream changes made by
Amazon and future upstream changes which may be incompatible.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
--
On 19/12/2019 11:45, Durrant, Paul wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 19 December 2019 11:30
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>>
>> Subject: Re: [Xen-devel] [PATCH] x86/save: reserve HVM save rec
On 19/12/2019 12:04, Paul Durrant wrote:
> ...for patches not (yet) upstream.
>
> This patch is simply adding a comment to reserve save record number space
> to avoid the risk of clashes between existent downstream changes made by
> Amazon and future upstream changes which may be incompatible.
>
>
In an effort to clarify and simplify the annotation of assembly functions
in the kernel new macros have been introduced. These replace ENTRY and
ENDPROC. Update the annotations in the xen code to the new macros.
Signed-off-by: Mark Brown
Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
> -Original Message-
> From: Andrew Cooper
> Sent: 19 December 2019 12:16
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>
> Subject: Re: [PATCH v2] x86/save: reserve HVM save record numbers that
> have been consumed...
>
> On 19/12/201
Hi Juergen,
We recently did another quick test of core scheduling mode, and the following
failures were found:
1. live-patch apply failures:
(XEN) [ 1058.751974] livepatch: lp_1_1: Timed out on semaphore in CPU
quiesce phase 30/31
(XEN) [ 1058.751982] livepatch: lp_1_1 finished REPLACE
On Thu, Dec 19, 2019 at 12:20:24PM +0100, Jan Beulich wrote:
> On 19.12.2019 04:49, Marek Marczykowski-Górecki wrote:
> > +enum interrupt_type xen_pcibk_get_interrupt_type(struct pci_dev *dev)
> > +{
> > + int err;
> > + u16 val;
> > +
> > + err = pci_read_config_word(dev, PCI_COMMAND, &val)
convert-legacy-stream is only used for incomming migration from pre Xen 4.7,
and verify-stream-v2 appears to only be used by me during migration
development - it is little surprise that they missed the main converstion
effort in Xen 4.13.
Fix it all up.
Move open_file_or_fd() into a new util.py t
On 19/12/2019 12:37, Durrant, Paul wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 19 December 2019 12:16
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>>
>> Subject: Re: [PATCH v2] x86/save: reserve HVM save record numbe
On 19/12/2019 12:45, Sergey Dyasli wrote:
> 2. ACPI S5 crash:
>
> https://paste.debian.net/1121748/
cmpw $0x7fff,(%rax) with %rax as 0xc2c2c2c2c2c2c2c2
Looks like a use-after-free checking for the idle domain.
~Andrew
___
Xen-devel mailing list
Xe
> -Original Message-
> From: Andrew Cooper
> Sent: 19 December 2019 13:08
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Jan Beulich ; Roger Pau Monné
>
> Subject: Re: [PATCH v2] x86/save: reserve HVM save record numbers that
> have been consumed...
>
> On 19/12/201
On 19.12.2019 14:15, Durrant, Paul wrote:
>> From: Andrew Cooper
>> Sent: 19 December 2019 13:08
>>
>> On 19/12/2019 12:37, Durrant, Paul wrote:
From: Andrew Cooper
Sent: 19 December 2019 12:16
On 19/12/2019 12:04, Paul Durrant wrote:
> --- a/xen/include/public/arch-x86/hv
> -Original Message-
> From: Jan Beulich
> Sent: 19 December 2019 13:25
> To: Durrant, Paul
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org; Wei Liu ; Roger Pau Monné
>
> Subject: Re: [PATCH v2] x86/save: reserve HVM save record numbers that
> have been consumed...
>
> On 19.12.
handle_x86_pv_info() has a subtle bug. It uses an 'else if' chain with a
clause in the middle which doesn't exit unconditionally. In practice, this
means that when restoring a 32bit PV guest, later sanity checks are skipped.
Rework the logic a little to be simpler. There are exactly two valid
c
flight 144959 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144959/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 72 xtf/test-hvm64-xsa-308 fail REGR. vs. 144936
Tests which did no
GitLab have a caching capability, see [1]. Let's use it to avoid using
Internet too often.
The cache is setup so that when xen.git/Config.mk is changed, the
cache will need to be recreated. This has been chosen because that is
where the information about how to clone sub-project trees is encoded
(
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.ci-caching-v1
This is only a small improvement to the GitLab CI. It only caches git clone
that Xen's makefile creates and not submodules needed by those clones.
It doesn't cache the dif
This also allows to run `make src-tarball` without first having to run
`./configure`.
Signed-off-by: Anthony PERARD
---
tools/Rules.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index cf8935d6a3ea..31cf419ef4f5 100644
--- a/tools/Rules.m
Hi Lars,
On 18/12/2019 17:09, Lars Kurth wrote:
On 18/12/2019, 14:29, "Julien Grall" wrote:
Hi Lars,
On 12/12/2019 21:14, Lars Kurth wrote:
> +### Workflow from an Author's Perspective
> +
> +When code authors receive feedback on their patches, they typically
This has been there forever and I doubt anyone has ever used it.
Andrew Cooper tells me that it needs an L or H suffix so probably
doesn't work. Recent changes to more conspicuously report command
line parsing failures highlighted this issue.
Suggested-by: Andrew Cooper
Signed-off-by: Ian Jacks
On 19/12/2019 15:07, Ian Jackson wrote:
> This has been there forever and I doubt anyone has ever used it.
>
> Andrew Cooper tells me that it needs an L or H suffix so probably
> doesn't work. Recent changes to more conspicuously report command
> line parsing failures highlighted this issue.
>
> S
When using DRAKVUF (or another system using altp2m with shadow pages similar
to what is described in
https://xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m),
after a breakpoint is hit the system switches to the default
unrestricted altp2m view with singlestep enabled. When the single
On 19.12.2019 16:47, Sergey Kovalev wrote:
> When using DRAKVUF (or another system using altp2m with shadow pages similar
> to what is described in
> https://xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m),
> after a breakpoint is hit the system switches to the default
> unrestricted
On Thu, Dec 19, 2019 at 2:48 AM Roger Pau Monné wrote:
>
> On Wed, Dec 18, 2019 at 11:40:37AM -0800, Tamas K Lengyel wrote:
> > The following series implements VM forking for Intel HVM guests to allow for
> > the fast creation of identical VMs without the assosciated high startup
> > costs
> > of
Now that vtsc_last is the only entity protected by vtsc_lock we can
simply update it using a single atomic operation and drop the spinlock
entirely. This is extremely important for the case of running nested
(e.g. shim instance with lots of vCPUs assigned) since if preemption
happens somewhere insi
On Thu, Dec 19, 2019 at 4:05 AM Jan Beulich wrote:
>
> On 19.12.2019 01:15, Tamas K Lengyel wrote:
> > On Wed, Dec 18, 2019 at 4:02 PM Julien Grall wrote:
> >> On 18/12/2019 22:33, Tamas K Lengyel wrote:
> >>> On Wed, Dec 18, 2019 at 3:00 PM Julien Grall wrote:
> You also have multiple loop
On 19.12.19 13:45, Sergey Dyasli wrote:
Hi Juergen,
We recently did another quick test of core scheduling mode, and the following
failures were found:
1. live-patch apply failures:
(XEN) [ 1058.751974] livepatch: lp_1_1: Timed out on semaphore in CPU
quiesce phase 30/31
(XEN) [ 1058
On 18/12/2019 09:24, Jürgen Groß wrote:
> On 17.12.19 15:08, Sergey Dyasli wrote:
>> This enables to use Outline instrumentation for Xen PV kernels.
>>
>> KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
>> and hence disabled.
>>
>> Rough edges in the patch are marked with XXX.
> > Well, this is only an experimental system that's completely disabled
> > by default. Making the assumption that people who make use of it will
> > know what they are doing I think is fair.
>
> I assume that if you submit to upstream this new hypercall then there is
> longer plan to have more pe
On Thu, Dec 19, 2019 at 8:47 AM Sergey Kovalev wrote:
>
> When using DRAKVUF (or another system using altp2m with shadow pages similar
> to what is described in
> https://xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m),
> after a breakpoint is hit the system switches to the default
Hi,
On 19/12/2019 16:11, Tamas K Lengyel wrote:
Well, this is only an experimental system that's completely disabled
by default. Making the assumption that people who make use of it will
know what they are doing I think is fair.
I assume that if you submit to upstream this new hypercall then t
On Mon, Dec 16, 2019 at 02:34:51PM +, Paul Durrant wrote:
> It is not safe to close an event channel from the QEMU main thread when
> that channel's poller is running in IOThread context.
>
> This patch adds a new xen_device_set_event_channel_context() function
> to explicitly assign the chann
On Thu, Dec 19, 2019 at 12:59 AM Alexandru Stefan ISAILA
wrote:
>
>
>
> On 18.12.2019 21:40, Tamas K Lengyel wrote:
> > Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
> > when the mem_access permission is being set on a page that has not yet been
> > copied over from t
On Thu, Dec 19, 2019 at 4:19 AM Andrew Cooper wrote:
>
> On 18/12/2019 19:40, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 5a3a962fbb..1e888b403b 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -1902,12 +1902,11 @
...for patches not (yet) upstream.
This patch is simply adding a comment to reserve save record number space
to avoid the risk of clashes between existent downstream changes made by
Amazon and future upstream changes which may be incompatible.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
--
On 19/12/2019 17:23, Tamas K Lengyel wrote:
On Thu, Dec 19, 2019 at 9:58 AM Julien Grall wrote:
Hi,
On 19/12/2019 16:11, Tamas K Lengyel wrote:
Well, this is only an experimental system that's completely disabled
by default. Making the assumption that people who make use of it will
know wh
On Thu, Dec 19, 2019 at 9:58 AM Julien Grall wrote:
>
> Hi,
>
> On 19/12/2019 16:11, Tamas K Lengyel wrote:
> >>> Well, this is only an experimental system that's completely disabled
> >>> by default. Making the assumption that people who make use of it will
> >>> know what they are doing I think
We are no longer using the frozen-in-amber microcode from 2015. Now
we use current microcode from Debian (or hopefully in future via other
distros).
Empirically this fixes the XSA-308 test on rimava1, which was failing
and producing very strange symptoms.
CC: Andrew Cooper
Signed-off-by: Ian Ja
Right now this is only useful with Debian. We will call it from
ts-host-install to install the microcode.
We enable and then disable non-free so that we don't install non-free
packages unintentionally.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 16
1 file changed,
We are going to do this differently, by installing the packages from
Debian. We couldn't do that in 2015 because not every version of Xen
supported scanning the dom0 initrd for microcode, but now all
supported versions do. So we will do that, in a moment.
This reverts commit 6cedb8c7d76a0ab3820e
> >>> The alternative would be that we just release a fork (or just
> >>> the patches) and walk away.
> >>> If the Xen community wants to make the
> >>> announcement that only code that will have long term support and is
> >>> "stable" is accepted upstream that's IMHO drastically going to reduce
On Thu, Dec 19, 2019 at 4:19 AM Andrew Cooper wrote:
>
> On 18/12/2019 19:40, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 5a3a962fbb..1e888b403b 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -1902,12 +1902,11 @
On 19/12/2019 17:57, Ian Jackson wrote:
> We are no longer using the frozen-in-amber microcode from 2015. Now
> we use current microcode from Debian (or hopefully in future via other
> distros).
>
> Empirically this fixes the XSA-308 test on rimava1, which was failing
> and producing very strange
There have been no users of the xc_compression_*() interface since Migration
v2 replaced legacy migration (2016, c/s b15bc4345).
It would need adjusting to fit into migration v2, and can be pulled out of git
history if someone wants to resurrect it in the future.
Signed-off-by: Andrew Cooper
---
None of these are buggy, but the resulting code is more robust.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_dom_core.c | 3 ++-
tools/libxc/xc_misc.c | 3 ++-
tools/libxc/xc_resource.c | 7 ---
On 19/12/2019 16:21, Tamas K Lengyel wrote:
>>> @@ -437,25 +441,29 @@ static inline void mem_sharing_gfn_destroy(struct
>>> page_info *page,
>>> xfree(gfn_info);
>>> }
>>>
>>> -static struct page_info* mem_sharing_lookup(unsigned long mfn)
>>> +static inline struct page_info* mem_sharing_loo
On 18/12/2019 19:40, Tamas K Lengyel wrote:
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 614ed60fe4..5a3a962fbb 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4072,16 +4072,17 @@ static int hvmop_set_evtchn_upcall_vector(
> }
>
> static int
On 18/12/2019 19:40, Tamas K Lengyel wrote:
> During VM forking we'll copy the parent domain's parameters to the client,
> including the HAP shadow memory setting that is used for storing the domain's
> EPT. We'll copy this in the hypervisor instead doing it during toolstack
> launch
> to allow th
flight 144964 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144964/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
On 18/12/2019 19:40, Tamas K Lengyel wrote:
> During VM forking the client lock will already be taken.
>
> Signed-off-by: Tamas K Lengyel
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/ma
On 18/12/2019 19:40, Tamas K Lengyel wrote:
> @@ -1959,19 +1965,21 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
> */
> if ( paged )
> p2m_mem_paging_populate(currd, gfn);
> +
> +#ifdef CONFIG_MEM_SHARING
> if ( sharing_enomem )
> {
> -int
On Thu, Dec 19, 2019 at 11:51 AM Andrew Cooper
wrote:
>
> On 19/12/2019 16:21, Tamas K Lengyel wrote:
> >>> @@ -437,25 +441,29 @@ static inline void mem_sharing_gfn_destroy(struct
> >>> page_info *page,
> >>> xfree(gfn_info);
> >>> }
> >>>
> >>> -static struct page_info* mem_sharing_lookup(
> > --- a/xen/include/asm-x86/hvm/hvm.h
> > +++ b/xen/include/asm-x86/hvm/hvm.h
> > @@ -335,6 +335,10 @@ unsigned long hvm_cr4_guest_valid_bits(const struct
> > domain *d, bool restore);
> > bool hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
> > void
On 19/12/2019 19:38, Tamas K Lengyel wrote:
>>> --- a/xen/include/asm-x86/hvm/hvm.h
>>> +++ b/xen/include/asm-x86/hvm/hvm.h
>>> @@ -335,6 +335,10 @@ unsigned long hvm_cr4_guest_valid_bits(const struct
>>> domain *d, bool restore);
>>> bool hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, struct
On Thu, Dec 19, 2019 at 12:41 PM Andrew Cooper
wrote:
>
> On 19/12/2019 19:38, Tamas K Lengyel wrote:
> >>> --- a/xen/include/asm-x86/hvm/hvm.h
> >>> +++ b/xen/include/asm-x86/hvm/hvm.h
> >>> @@ -335,6 +335,10 @@ unsigned long hvm_cr4_guest_valid_bits(const struct
> >>> domain *d, bool restore);
On 19/12/2019 19:49, Tamas K Lengyel wrote:
> On Thu, Dec 19, 2019 at 12:41 PM Andrew Cooper
> wrote:
>> On 19/12/2019 19:38, Tamas K Lengyel wrote:
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -335,6 +335,10 @@ unsigned long hvm_cr4_guest_valid_bits
On Thu, Dec 19, 2019 at 12:57 PM Andrew Cooper
wrote:
>
> On 19/12/2019 19:49, Tamas K Lengyel wrote:
> > On Thu, Dec 19, 2019 at 12:41 PM Andrew Cooper
> > wrote:
> >> On 19/12/2019 19:38, Tamas K Lengyel wrote:
> > --- a/xen/include/asm-x86/hvm/hvm.h
> > +++ b/xen/include/asm-x86/hvm/hv
The current logic only works by chance, in that XSAVE records also tend to be
a multiple of 128. Implement the missing logic for XSAVE.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_sr_restore_x86_pv.c | 9 +
1 file changed, 9 insertions(+)
diff --gi
flight 144974 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144974/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 665afccc52e1a02ee329147e02f04b8e9cf1d571
baseline version:
ovmf 95bb203861c5e19b7b7d5
On Thu, 19 Dec 2019, Mark Brown wrote:
> In an effort to clarify and simplify the annotation of assembly functions
> in the kernel new macros have been introduced. These replace ENTRY and
> ENDPROC. Update the annotations in the xen code to the new macros.
>
> Signed-off-by: Mark Brown
> Reviewed
On 18.12.19 12:49, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
Decouple the microcode referencing mechanism when using GRUB to that
when using EFI. This allows us to avoid the "unspecified effect" of
using ` | scan` along xen.efi.
I guess "unspecified effect" in the doc was p
On 18.12.19 13:05, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
@@ -725,7 +701,7 @@ static int __init microcode_init(void)
*/
if ( ucode_blob.size )
{
-xfree(ucode_blob.data);
+bootstrap_map(NULL);
As much as I like the change, I wholehearted
flight 144983 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144983/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
+
+
+Xen can bundle microcode updates within its image. This support is conditional
+on the build configuration BUILTIN_UCODE being enabled. Builtin microcode is
+useful t
Hi,
On 19/12/2019 11:35, Jan Beulich wrote:
On 19.12.2019 12:23, Sergey Dyasli wrote:
On 18/12/2019 11:06, Jan Beulich wrote:
On 17.12.2019 16:46, Sergey Dyasli wrote:
Hide the following information that can help identify the running Xen
binary version:
XENVER_extraversion
XENVER_c
On 19/12/2019 11:35, Jan Beulich wrote:
XENVER_changeset
XENVER_commandline
XENVER_build_id
Return a more customer friendly empty string instead of ""
which would be shown in tools like dmidecode.>
>>> I think "" is quite fine for many of the original purpo
On 19/12/2019 23:15, Andrew Cooper wrote:
> On 19/12/2019 11:35, Jan Beulich wrote:
> XENVER_changeset
> XENVER_commandline
> XENVER_build_id
>
> Return a more customer friendly empty string instead of ""
> which would be shown in tools like dmidecode.>
I th
On Thu, 19 Dec 2019, Julien Grall wrote:
> > > In fact most of people on Arm are using GRUB rather than EFI directly as
> > > this is more friendly to use.
> > >
> > > Regarding the devicetree, Xen and Linux will completely ignore the
> > > memory nodes in Xen if using EFI. This because the EFI me
flight 144972 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144972/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-5 72 xtf/test-hvm64-xsa-308 fail in 144959 pass in 144972
test-armhf-armhf-xl-rtds 12
1 - 100 of 104 matches
Mail list logo
