flight 123871 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 10 debian-install fail REGR. vs. 123554
test-amd64-amd64-li
On 06/07/2018 09:33 PM, Liam Shepherd wrote:
Thank you.
As a side point David Vrabel is listed in the maintainers file for xen
hypervisor interface in 4.4.135 but his email is no longer active it seems.
Yeah, he has left Citrix. The MAINTAINERS file is not usually updated in
stable release
> -Original Message-
> From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> Sent: 07 June 2018 15:59
> To: xen-de...@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> jbeul...@suse.com; Andrew Cooper ; Paul
> Durrant ; Alexandru Isaila
>
> Subject: [PATCH v7 07/15] x86/hvm: Introduce
> vi
> -Original Message-
> From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> Sent: 07 June 2018 15:59
> To: xen-de...@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> jbeul...@suse.com; Andrew Cooper ; Paul
> Durrant ; Alexandru Isaila
>
> Subject: [PATCH v7 08/15] x86/cpu: Remove loop fo
flight 123877 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123877/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-amd64-i386-migrupgrade 10 xen-bo
flight 123879 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123879/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 236601136fea5dcfad4b57ce4a81cf980a22e1f4
baseline version:
ovmf 91c31ff04a7a72b4b0e47
Use a global variable to store the start flags for both PV and PVH.
This allows the xen_initial_domain macro to work properly on PVH.
Note that ARM is also switched to use the new variable.
Signed-off-by: Boris Ostrovsky
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jason Long
> Sent: 07 June 2018 19:10
> To: xen-devel@lists.xenproject.org
> Subject: [Xen-devel] Xen or Bhyve?
>
> Hello.
> For BSD distros, Xen is better or Bhyve? Can Bhyve be a replace
On Vi, 2018-06-08 at 08:33 +, Paul Durrant wrote:
> >
> > -Original Message-
> > From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> > Sent: 07 June 2018 15:59
> > To: xen-de...@lists.xen.org
> > Cc: Ian Jackson ; Wei Liu > com>;
> > jbeul...@suse.com; Andrew Cooper ; Paul
> > D
On Thu, Jun 07, 2018 at 05:59:06PM +0200, Roger Pau Monne wrote:
> Add a note to spell out that if the address tag is not present the
> file should be loaded using the elf header.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Daniel Kiper
> Cc: xen-devel@lists.xenproject.org
> ---
> Changes sinc
xencall_alloc_buffer() is used throughout Xen tools for allocating
hypercall buffers. Allocation is done at page granularity. For simple
administration each allocated set of pages contains a small header
holding the number of pages of that set. The hypercall buffer is
located directly after the 4 b
On 08/06/18 10:40, Roger Pau Monne wrote:
> Use a global variable to store the start flags for both PV and PVH.
> This allows the xen_initial_domain macro to work properly on PVH.
>
> Note that ARM is also switched to use the new variable.
>
> Signed-off-by: Boris Ostrovsky
> Signed-off-by: Roge
No functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v3:
- Rebase on top of Jan's MTRR fixes.
Changes since v2:
- Use unsigned int instead of uint8_t in mtrr_pat_not_equal.
---
xen/arch/x86/cpu/mtrr/main.c
From: Jan Beulich
We should not assume that the incoming set of values contains exactly
MTRR_VCNT variable range MSRs. Permit a smaller amount and reject a
bigger one. As a result the save path then also needs to no longer use
a fixed upper bound, in turn requiring unused space in the save record
Copy the state found on the hardware when creating a PVH Dom0. Since
the memory map provided to a PVH Dom0 is based on the native one using
the same set of MTRR ranges should provide Dom0 with a sane MTRR state
without having to manually build it in Xen.
Signed-off-by: Roger Pau Monné
Reviewed-by
Hello,
The following patches set a sane initial MTRR state for both Dom0 and
DomU PVH guests. Note that for Dom0 the host MTRR state is used, OTOH
for DomU the default MTRR type is set to write-back.
This should avoid guests having to setup some kind of MTRR state in
order to boot.
This has been
Expand the size of the variable ranges array to match the size of the
underlying hardware, this is a preparatory change for copying the
hardware MTRR state for Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v3:
- Move the index check to hvm_msr_wri
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/mtrr.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index c181a7a3d0..2f8f8ddd8f 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86
From: Jan Beulich
The code hopefully is more readable this way.
Also switch have_fixed to bool, seeing that it already is used as a
boolean.
Signed-off-by: Jan Beulich
[switched to use MASK_*]
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/cpu/mtrr/ge
Provided to both Dom0 and DomUs.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Changes since v2:
- Add 'currently' to the first sente
And enable MTRR. This allows to provide a sane initial MTRR state for
PVH DomUs. This will have to be expanded when pci-passthrough support
is added to PVH guests, so that MMIO regions of devices are set as
UC.
Note that initial MTRR setup is done by hvmloader for HVM guests,
that's not used by PV
On Fri, Jun 08, 2018 at 11:35:52AM +0200, Daniel Kiper wrote:
> On Thu, Jun 07, 2018 at 05:59:06PM +0200, Roger Pau Monne wrote:
> > Add a note to spell out that if the address tag is not present the
> > file should be loaded using the elf header.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> >
On 08/06/18 10:51, Juergen Gross wrote:
> xencall_alloc_buffer() is used throughout Xen tools for allocating
> hypercall buffers. Allocation is done at page granularity. For simple
> administration each allocated set of pages contains a small header
> holding the number of pages of that set. The hy
On 07/06/18 13:30, Juergen Gross wrote:
> On 06/06/18 11:40, Juergen Gross wrote:
>> On 06/06/18 11:35, Jan Beulich wrote:
>> On 05.06.18 at 18:19, wrote:
>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14
>> guest-saverestore.2
I thought I would reply again with the
On 08/06/18 07:59, osstest service owner wrote:
> flight 123874 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/123874/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i3
Can you tell where I can ask it?
On Fri, 6/8/18, Paul Durrant wrote:
Subject: Re: [Xen-devel] Xen or Bhyve?
To: "'Jason Long'" , "xen-devel@lists.xenproject.org"
Date: Friday, June 8, 2018, 8:42 AM
> -Original
Message-
> From: Xen-dev
On 08/06/18 12:09, Andrew Cooper wrote:
> On 08/06/18 10:51, Juergen Gross wrote:
>> xencall_alloc_buffer() is used throughout Xen tools for allocating
>> hypercall buffers. Allocation is done at page granularity. For simple
>> administration each allocated set of pages contains a small header
>> h
On Fri, Jun 08, 2018 at 12:08:22PM +0200, Roger Pau Monné wrote:
> On Fri, Jun 08, 2018 at 11:35:52AM +0200, Daniel Kiper wrote:
> > On Thu, Jun 07, 2018 at 05:59:06PM +0200, Roger Pau Monne wrote:
> > > Add a note to spell out that if the address tag is not present the
> > > file should be loaded
>>> On 08.06.18 at 12:18, wrote:
> On 08/06/18 07:59, osstest service owner wrote:
>> flight 123874 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/123874/
>>
>> Failures and problems with tests :-(
>>
>> Tests which did not succeed and are blocking,
>> including te
On 06/08/2018 12:46 AM, Boris Ostrovsky wrote:
(Stefano, question for you at the end)
On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote:
On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
On
On 06/08/2018 01:30 AM, Boris Ostrovsky wrote:
On 06/07/2018 04:44 AM, Oleksandr Andrushchenko wrote:
On 06/07/2018 12:48 AM, Boris Ostrovsky wrote:
On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote:
On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushc
On 06/08/2018 01:26 AM, Boris Ostrovsky wrote:
On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote:
On 06/07/2018 12:32 AM, Boris Ostrovsky wrote:
On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote:
On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
diff --git a/drivers/xen/gntdev.c b/driver
>>> On 04.06.18 at 15:59, wrote:
> @@ -82,9 +83,16 @@ void pv_inject_event(const struct x86_event *event)
> error_code |= PFEC_user_mode;
>
> trace_pv_page_fault(event->cr2, error_code);
> -}
> -else
> +break;
> +
> +case TRAP_debug:
> +curr->arc
On 08/06/18 08:08, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> If frontend is configured to expose multiple input device instances
> then backend may require a way to uniquely identify concrete input
> device within the frontend. This is useful for use-cases where
> virtual
On 08/06/18 08:08, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> If frontend is configured to expose multiple connectors then backend may
> require a way to uniquely identify concrete virtual connector within the
> frontend. This is useful for use-cases where connector needs
On 08/06/18 08:08, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Display and input protocols define "unique-id" XenBus field as string
> which is much more flexible in defining unique identifiers comparing
> to integer used by sound protocol. For example, this allows to provi
> -Original Message-
> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> Sent: 08 June 2018 09:51
> To: Paul Durrant ; xen-de...@lists.xen.org
> Cc: Ian Jackson ; jbeul...@suse.com; Andrew
> Cooper ; Wei Liu
> Subject: Re: [PATCH v7 08/15] x86/cpu: Remove loop form
> vmce_sa
On 08/06/18 13:34, Jan Beulich wrote:
On 04.06.18 at 15:59, wrote:
>> @@ -82,9 +83,16 @@ void pv_inject_event(const struct x86_event *event)
>> error_code |= PFEC_user_mode;
>>
>> trace_pv_page_fault(event->cr2, error_code);
>> -}
>> -else
>> +break;
>>
On 06/08/2018 09:08 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
This series fixes inconsistency in section used while defining kbdif
XenBus entries and adds string "unique-id" XenBus entry missing in
displif and kbdif. It also changes sndif's "unique-id" field fro
>>> On 04.06.18 at 15:59, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1437,19 +1437,49 @@ static void svm_inject_event(const struct x86_event
> *event)
> switch ( _event.vector | -(_event.type == X86_EVENTTYPE_SW_INTERRUPT) )
> {
> case TRAP_d
>>> On 04.06.18 at 15:59, wrote:
> The current logic used to update %dr6 when injecting #DB is buggy. The
> architectural behaviour is to overwrite B{0..3} (rather than accumulate) and
> accumulate all other bits.
>
> Introduce a new merge_dr6() helper, which also takes care of handing RTM
> cor
>>> On 04.06.18 at 15:59, wrote:
> Replace the few remaining uses with X86_DR6_* constants.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listi
On 08/06/18 14:00, Jan Beulich wrote:
On 04.06.18 at 15:59, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1437,19 +1437,49 @@ static void svm_inject_event(const struct x86_event
>> *event)
>> switch ( _event.vector | -(_event.type == X86_EVENTTYPE
Apropos of the irc conversation below, in particular my suggestion to
use mg-repro-setup. Probably, an appropriate rune is
./mg-repro-setup -f123855 -ejgr...@suse.com 123855
test-amd64-amd64-xl-qemuu-ovmf-amd64 guest-saverestore.2
host=alloc:'{equiv-albana}'
(You will have wanted to
git c
flight 123881 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123881/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 broken in 123492
test-amd64-amd64-xl-qemuu-o
>>> On 08.06.18 at 11:59, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3491,10 +3491,13 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t
> *msr_content)
> index = msr - MSR_MTRRfix4K_C;
> *msr_content = fixed_range_base[index + 3];
>
>>> On 08.06.18 at 14:46, wrote:
>> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
>> Sent: 08 June 2018 09:51
>> On Vi, 2018-06-08 at 08:33 +, Paul Durrant wrote:
>> > > From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
>> > > Sent: 07 June 2018 15:59
>> > > Signed-off-b
>>> On 07.06.18 at 16:59, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
Acked-by: Jan Beulich
also for patch 2, both in case they remain the way they are (according
to one of the two proposals I've just made in reply to Paul's outline).
Jan
>>> On 07.06.18 at 16:59, wrote:
> @@ -799,100 +897,7 @@ static int hvm_save_cpu_ctxt(struct domain *d,
> hvm_domain_context_t *h)
> continue;
>
> memset(&ctxt, 0, sizeof(ctxt));
> -
Why do you not move this memset() as well? I'm pretty convinced the
eventual other mode o
>>> On 07.06.18 at 16:59, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
Acked-by: Jan Beulich
(with the same constraint as before)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
>>> On 07.06.18 at 16:59, wrote:
> @@ -1370,32 +1402,8 @@ static int hvm_save_cpu_msrs(struct domain *d,
> hvm_domain_context_t *h)
> ctxt = (struct hvm_msr *)&h->data[h->cur];
> ctxt->count = 0;
Along the lines of what I've said for patch 3: Why is this line not being
moved?
>>> On 07.06.18 at 16:59, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
I think it would help if you based this on top of Roger's series[1] right away,
as that one is pretty likely to go in relatively soon after branching. If you
choose to do so,
> > Oleksandr Andrushchenko (4):
> >xen/kbdif: Move multi-touch device parameters to backend nodes
> >xen/kbdif: Add unique input device identifier
> >xen/displif: Add unique display connector identifier
> >xen/sndif: Change stream's unique-id to string
> >
> > xen/include/public
The value written by the guest must be valid according to the mask
provided in the interrupt routing capabilities register. If the
interrupt is not valid set it to the first valid IRQ in the
capabilities field if the timer is enabled, else just clear the field.
Also refuse to start any timer that
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/vpt.c | 67 +++---
1 file changed, 36 insertions(+), 31 deletions(-)
diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
index a0cc61fd2
In order to test HPET level trigger interrupts.
Note that the test doesn't check that the interrupt is injected
correctly, only that the status bits are properly set an acknowledged
when using HPET with level triggered interrupts.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
---
arch/x
Hello,
The following series contain a couple of bug fixes for the vhpet/vpt
code, and also add support for level trigger interrupts to vhpet. Level
triggered interrupts are not an optional feature of the hpet spec, so
they must be implemented in order to have a complete emulated hpet
implementatio
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/include/asm-x86/hvm/vpt.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/include/asm-x86/hvm/vpt.h b/xen/include/asm-x86/hvm/vpt.h
index 0eb5ff632e..f693c0bcf1
Instead of the stale value inside the periodic_time struct.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/vpt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
index d5363caec7..
Level trigger interrupts will be asserted regardless of whether the
interrupt is masked, and thus the callback will also be executed.
Add a new 'level' parameter to create_periodic_time in order to create
level triggered timers.
Note that none of the current users of vpt are switched to use level
Level triggered interrupts are not an optional feature of HPET, and
must be implemented in order to comply with the HPET specification.
Implement them by adding a callback to the timer which sets the
interrupt bit in the general interrupt status register. Further
interrupts (in case of periodic mo
On 06/06/18 11:34, Roger Pau Monné wrote:
> On Mon, Jun 04, 2018 at 02:59:07PM +0100, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>> index 528aff1..0872466 100644
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -3,6 +3,7 @@
The documentation for the iommu_inclusive_mapping Xen command line option
states:
"Use this to work around firmware issues providing incorrect RMRR entries"
Unfortunately this workaround does not function correctly if the dom0-strict
iommu option is also specified.
The documentation goes on to s
It is hard to reconcile the comment at the top of the loop in
vtd_set_hwdom_mapping() with the if statement following it. This patch
re-phrases the logic, preserving the semantics, but making it easier
to read.
The patch also modifies the Xen command line documentation to make it
clear that iommu_
When dom0-strict mode is enabled the iommu_inclusive_mapping workaround
for firmware with undeclared RMRRs is rendered useless. This series fixes
the problem.
Paul Durrant (2):
VT-d: re-phrase logic in vtd_set_hwdom_mapping() for clarity
VT-d: reconcile iommu_inclusive_mapping and iommu=dom0-s
On 08/06/18 16:25, Ian Jackson wrote:
> Apropos of the irc conversation below, in particular my suggestion to
> use mg-repro-setup. Probably, an appropriate rune is
>
> ./mg-repro-setup -f123855 -ejgr...@suse.com 123855
> test-amd64-amd64-xl-qemuu-ovmf-amd64 guest-saverestore.2
> host=alloc:'
On 06/06/18 14:56, Jan Beulich wrote:
On 04.06.18 at 15:59, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -322,6 +322,14 @@ void free_vcpu_struct(struct vcpu *v)
>> free_xenheap_page(v);
>> }
>>
>> +static void initialise_registers(struct vcpu *v)
>> +{
>>
On 07/06/18 12:05, Jan Beulich wrote:
On 06.06.18 at 16:16, wrote:
>> On 06/06/18 14:50, Jan Beulich wrote:
>> On 04.06.18 at 15:59, wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3696,6 +3696,7 @@ void vmx_vmexit_handler(struct cpu_user_regs
On 06/06/18 15:20, Jan Beulich wrote:
On 04.06.18 at 15:59, wrote:
>> No functional change (as curr->arch.debugreg[5] is zero when DE is clear),
>> but
>> this change simplifies the following patch.
> A comment to this effect would be helpful ...
>
>> --- a/xen/arch/x86/x86_emulate.c
>> +++
This run is configured for baseline tests only.
flight 74805 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start
>>> On 08.06.18 at 17:58, wrote:
> On 07/06/18 12:05, Jan Beulich wrote:
> On 06.06.18 at 16:16, wrote:
>>> On 06/06/18 14:50, Jan Beulich wrote:
>>> On 04.06.18 at 15:59, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3696,6 +3696,7 @@ voi
On Fri, 8 Jun 2018, Roger Pau Monne wrote:
> Use a global variable to store the start flags for both PV and PVH.
> This allows the xen_initial_domain macro to work properly on PVH.
>
> Note that ARM is also switched to use the new variable.
>
> Signed-off-by: Boris Ostrovsky
> Signed-off-by: Rog
>>> On 08.06.18 at 17:42, wrote:
> On 06/06/18 14:56, Jan Beulich wrote:
> On 04.06.18 at 15:59, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -322,6 +322,14 @@ void free_vcpu_struct(struct vcpu *v)
>>> free_xenheap_page(v);
>>> }
>>>
>>> +static void i
>>> On 08.06.18 at 18:03, wrote:
> On 06/06/18 15:20, Jan Beulich wrote:
> On 04.06.18 at 15:59, wrote:
>>> No functional change (as curr->arch.debugreg[5] is zero when DE is clear),
> but
>>> this change simplifies the following patch.
>> A comment to this effect would be helpful ...
>>
>>>
On Fri, Jun 08, 2018 at 09:12:25AM -0700, Stefano Stabellini wrote:
> On Fri, 8 Jun 2018, Roger Pau Monne wrote:
> > Use a global variable to store the start flags for both PV and PVH.
> > This allows the xen_initial_domain macro to work properly on PVH.
> >
> > Note that ARM is also switched to u
flight 123945 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123945/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 74806 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74806/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74770
baseline version:
fl
This run is configured for baseline tests only.
flight 74807 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74807/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 236601136fea5dcfad4b57ce4a81cf980a22e1f4
baseline v
On Fri, 8 Jun 2018, Oleksandr Andrushchenko wrote:
> On 06/08/2018 12:46 AM, Boris Ostrovsky wrote:
> > (Stefano, question for you at the end)
> >
> > On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
> > > On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
> > > > On 06/06/2018 04:14 AM, Oleksan
flight 123897 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123897/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-pair 23 guest-migrate/dst_host/src_host fail in 123852
pass in 123812
test-amd64-am
Up until this point, the MSR load/save lists have only ever accumulated
content. Introduce vmx_del_msr() as a companion to vmx_add_msr().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
CC: Wei Liu
CC: Roger Pau Monné
v2:
* s/arch_vmx/vmx/ as per patch 2 r
The purpose of this patchset is to fix a longstanding bug whereby Xen's NXE
setting leaks into HVM context, and has a visible effect on the guests
pagewalk.
To allow patch 9 to function, there are 8 patches of improvements to the MSR
load/save infrastructure, purely to support first-gen VT-x hardw
Collect together related infrastructure in vmcs.h, rather than having it
spread out. Turn vmx_{read,write}_guest_msr() into static inlines, as they
are simple enough.
Replace 'int type' with 'enum vmx_msr_list_type', and use switch statements
internally. Later changes are going to introduce a ne
The main purpose of this change is to allow us to set a specific MSR value,
without needing to know whether there is already a load/save list slot for it.
Previously, callers wanting this property needed to call both vmx_add_*_msr()
and vmx_write_*_msr() to cover both cases, and there are no calle
Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load
and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and VM_ENTRY_MSR_LOAD_ADDR
at the same page, and setting VM_EXIT_MSR_STORE_COUNT and
VM_ENTRY_MSR_LOAD_COUNT to the same value.
However, for MSRs which we won't let the gu
The main purpose of this patch is to only ever insert the LBR MSRs into the
guest load/save list once, as a future patch wants to change the behaviour of
vmx_add_guest_msr().
The repeated processing of lbr_info and the guests MSR load/save list is
redundant, and a guest using LBR itself will have
At the moment, all modifications of the MSR lists are in current context.
However, future changes may need to put MSR_EFER into the lists from domctl
hypercall context.
Plumb a struct vcpu parameter down through the infrastructure, and use
vmx_vmcs_{enter,exit}() for safe access to the VMCS in vmx
Intel hardware only uses 4 bits in MSR_EFER. Changes to LME and LMA are
handled automatically via the VMENTRY_CTLS.IA32E_MODE bit.
SCE is handled by ad-hoc logic in context_switch(), vmx_restore_guest_msrs()
and vmx_update_guest_efer(), and works by altering the host SCE value to match
the settin
Instead of having multiple algorithms searching the MSR lists, implement a
single one. It has the semantics required by vmx_add_msr(), to identify the
position in which an MSR should live, if it isn't already present.
There will be a marginal improvement for vmx_find_msr() by avoiding the
functio
* Use an arch_vmx_struct local variable to reduce later code volume.
* Use start/total instead of msr_area/msr_count. This is in preparation for
more finegrained handling with later changes.
* Use ent/end pointers (again for preparation), and to make the vmx_add_msr()
logic easier to foll
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
>
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
map->kunmap
Hi Manish,
Julien had responded back on the removal of code in this patch before
following is the response to Roger:
"What matters is to know what is common between SMMUv2 and SMMUv3 driver. So it
can be pulled in a separate headers.
IHMO, the both yours and his way are valid. TBH, I would hav
flight 123907 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123907/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail in 123817 pass in 123907
test-amd64-amd64-rumprun-amd6
On 6/7/2018 10:36 PM, Manish Jaggi wrote:
> Hi Sameer,
>
>
> On 06/08/2018 05:17 AM, Sameer Goel wrote:
>> Pull common defines for SMMU drives in a local header.
> Can add more detail in commit message?
>>
>> Signed-off-by: Sameer Goel
>> ---
>> xen/drivers/passthrough/arm/smmu-v3.c | 96 +---
branch xen-unstable
xenbranch xen-unstable
job build-arm64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemuu git://xenbits.
flight 123914 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123914/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 122969
test-amd64-amd64-xl-s
flight 123919 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123919/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12 guest-
flight 123929 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123929/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
+= xen-devel
On Sat, Jun 9, 2018 at 10:55 AM, Ajay Garg wrote:
> Hi All.
>
> a)
> git://xenbits.xen.org/xen.git does not have a arm64 listing in the
> stubdom directory.
> Upon running "make c", following is seen :
>
> \u@\h:\w$ make c
> /xen/stubdom/../extras/mini-os/Config.mk:86:
> /xen/stubdom
flight 123923 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123923/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123870
test-armhf-armhf-libvirt 14 sav
100 matches
Mail list logo
