flight 129121 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 129113
build-i386-pvops
This run is configured for baseline tests only.
flight 75532 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75532/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 129090 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129090/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 128844
test-amd64-i386-xl-qemuu-ws16-am
flight 129128 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129128/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebsd 6 host-bu
Hello Julien,
Sorry for the previous email sent as html.
On 27.10.18 15:14, Andrii Anisov wrote:
>>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>>> index f6f6de3..985192b 100644
>>> --- a/xen/arch/arm/traps.c
>>> +++ b/xen/arch/arm/traps.c
>>> @@ -2095,6 +2095,7 @@ static void ent
George Dunlap writes ("Re: [PATCH 5/5] RFC: test/depriv: Add a tool to check
process-level depriv"):
> Oh, actually, 65534 is "nogroup", which is the default when you don't
> add a specific group.
>
> Should we recommend creating a separate group for the Xen qemus in our
> feature doc? Or should
>>> On 26.10.18 at 17:58, wrote:
> On 26/10/2018 16:01, Jan Beulich wrote:
> On 26.10.18 at 16:51, wrote:
>>> On 26/10/2018 15:37, Jan Beulich wrote:
>>> On 26.10.18 at 16:22, wrote:
> On 26/10/2018 14:31, Jan Beulich wrote:
> On 15.10.18 at 12:36, wrote:
>>> --- a/xen/a
>>> On 26.10.18 at 23:41, wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Friday, October 26, 2018 7:16 AM
>> To: Daniel de Graaf
>> Cc: Andrew Cooper ; xen-de...@lists.xen.org
>> Subject: [Non-DoD Source] Ping: Re: Flask default policy mismatch vs dummy
>>
>> >>> On 11.10.
>>> On 26.10.18 at 17:52, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 26 October 2018 16:46
>>
>> >>> On 17.10.18 at 10:19, wrote:
>> > {
>> > -if ( !d->is_shutting_down && printk_ratelimit() )
>> > -printk(XENLOG_ERR
>> > - "d%d: IO
flight 129125 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129125/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c09b254bdc6050cc8b580a26558f692f958645d6
baseline version:
ovmf 2f6693c283b54666def65
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/hvm.c| 2 +-
xen/arch/x86/mm/mem_sharing.c | 2 +-
xen/arch/x86/mm/p2m.c | 4 ++--
xen/common/memory.c | 2 +-
xen/common/vm_event.c | 4 ++--
xen/include/asm-x86/mem_sharing.h | 2 +-
xen/i
>>> On 03.10.18 at 20:38, wrote:
> Reviewing just the code generation at this point.
Thanks for having found the time.
> See the Linux source code for ASM_CALL_CONSTRAINT. There is a potential
> code generation issue if you've got a call instruction inside an asm
> block if you don't list the s
On Mon, Oct 22, 2018 at 03:33:07PM +0800, Chao Gao wrote:
> Hi, Roger, Andrew and Wei,
>
> Jan's patch
> (https://lists.xen.org/archives/html/xen-devel/2018-10/msg01031.html)
> fixs an issue in handling SVI. Currently, when dealing with EOI from guest,
> the
> SVI was cleared. But the correct way
flight 75534 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75534/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On Thu, Oct 25, 2018 at 03:22:17AM -0600, Jan Beulich wrote:
> >>> On 15.10.18 at 13:19, wrote:
> > On Fri, Oct 12, 2018 at 08:14:36AM -0600, Jan Beulich wrote:
> >> >>> On 04.10.18 at 17:43, wrote:
> >> > It is used by PV code only.
> >>
> >> And wrongly so - the same is needed for a PVH Dom0 a
On 26/10/18 16:15, Jan Beulich wrote:
On 15.10.18 at 12:36, wrote:
>> @@ -970,9 +972,13 @@ int arch_set_info_guest(
>> v->arch.pv.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(v, cr4) :
>> real_cr4_to_pv_guest_cr4(mmu_cr4_features);
>>
>> -memset(v->arch.debugreg, 0, sizeof(v->arc
GCC 4.3.x can't initialise the user_regs structure like this.
Reported-by: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/domain.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
On Mon, Oct 29, 2018 at 11:52:08AM +, Andrew Cooper wrote:
> GCC 4.3.x can't initialise the user_regs structure like this.
>
> Reported-by: Jan Beulich
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@list
On 26 October 2018 at 16:31, Laurent Vivier wrote:
> The following changes since commit 808ebd66e467f77c0d1f8c6346235f81e9c99cf2:
>
> Merge remote-tracking branch 'remotes/riscv/tags/riscv-for-master-3.1-sf0'
> into staging (2018-10-25 17:41:03 +0100)
>
> are available in the Git repository at:
On 10/27/18 1:14 PM, Andrii Anisov wrote:
Hello Julien,
On 10/27/2018 12:55 AM, Julien Grall wrote:
The functions below does not exist in latest Xen. So are you sure this
based on mainline?
Yep, I've put a wrong diff into the email, it is for XEN 4.10.
Please find the patch for XEN 4.12-un
Hi Stefano,
On 10/27/18 1:42 AM, Stefano Stabellini wrote:
On Fri, 26 Oct 2018, Julien Grall wrote:
On 10/26/18 10:27 PM, Julien Grall wrote:
Hi,
On 10/26/18 10:12 PM, Stefano Stabellini wrote:
On Fri, 26 Oct 2018, Julien Grall wrote:
Hi Stefano,
On 10/23/18 3:02 AM, Stefano Stabellini wro
>>> On 29.10.18 at 12:53, wrote:
> On Mon, Oct 29, 2018 at 11:52:08AM +, Andrew Cooper wrote:
>> GCC 4.3.x can't initialise the user_regs structure like this.
>>
>> Reported-by: Jan Beulich
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Wei Liu
Acked-by: Jan Beulich
__
Sorry for late reply,
> I am afraid no. .config is generated during building time. So can you
> paste here please.
".config" file is in attachment.
I also tried Xen 4.9 and I got almost same numbers, jitter is smaller
by 150ns which isn't significant change at all.
Milan
#
# Automatically gene
This patch is a pre-requisite for the one fixing VGA logdirty
freezes when using altp2m. It only concerns itself with the
ranges allocation / deallocation / initialization part. While
touching the code, I've switched global_logdirty from bool_t
to bool.
Signed-off-by: Razvan Cojocaru
---
CC: Geo
When an new altp2m view is created very early on guest boot, the
display will freeze (although the guest will run normally). This
may also happen on resizing the display. The reason is the way
Xen currently (mis)handles logdirty VGA: it intentionally
misconfigures VGA pages so that they will fault.
Hello,
This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display). Since the last version of the series,
what was previously the second (and last) patch has been split in
two patches, the first of which o
This patch is a pre-requisite for fixing the logdirty VGA issue
(display freezes when switching to a new altp2m view early in a
domain's lifetime), but sent separately for easier review.
The new ept_set_ad_sync() function has been added to update all
active altp2ms' ept.ad. New altp2ms will inherit
On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
> On 19/10/2018 18:10, Roger Pau Monné wrote:
> > On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> >> Initialize the needed Xen specific data. This is:
> >>
> >> - the Xen start of day page containing the console and Xen
The P2M code currently contains many loops to deal with the fact that,
while it may be require to handle page orders greater than 4k, the
IOMMU map and unmap functions do not.
This patch adds a page_order parameter to those functions and implements
the necessary loops within. This allows the P2M co
On 29/10/2018 10:06, Andrii Anisov wrote:
Hello Julien,
Hi,
Sorry for the previous email sent as html.
Don't worry. I didn't notice it :).
On 27.10.18 15:14, Andrii Anisov wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index
f6f6de3..985192b 100644 --- a/xen/arch/ar
flight 129104 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129104/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 128775
test-armhf-armhf-l
>>> On 19.10.18 at 16:28, wrote:
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -234,6 +234,8 @@ static int g2m_portio_write(const struct hvm_io_handler
> *handler,
> {
> case 1:
> outb(data, mport);
> +if ( post_outb_hook )
> +post_outb_ho
>>> On 19.10.18 at 16:28, wrote:
> Change "guest" to "domain" where appropriate because "guest" doesn't
> include Domain 0.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xe
On 29/10/2018 13:57, Roger Pau Monné wrote:
> On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
>> On 19/10/2018 18:10, Roger Pau Monné wrote:
>>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
Initialize the needed Xen specific data. This is:
- the Xen s
>>> On 19.10.18 at 17:20, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1272,6 +1272,24 @@ void svm_host_osvw_init()
> spin_unlock(&osvw_lock);
> }
>
> +static int acpi_c1e_quirk(int dir, unsigned int port, unsigned int bytes,
> +
On Mon, Oct 29, 2018 at 4:54 AM Alexandru Stefan ISAILA
wrote:
>
> Signed-off-by: Alexandru Isaila
Acked-by: Tamas K Lengyel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 19.10.18 at 16:28, wrote:
> They are useful to PV only.
Considering there was no is_{hvm,pv}_...() check so far, I think
you need to extend this a little plus ...
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -608,6 +608,7 @@ long arch_do_domctl(
> copyback
>>> On 19.10.18 at 16:28, wrote:
> @@ -303,14 +305,17 @@ void cstar_enter(void);
>
> void subarch_percpu_traps_init(void)
> {
> +#ifdef CONFIG_PV
> unsigned long stack_bottom = get_stack_bottom();
> unsigned long stub_va = this_cpu(stubs.addr);
> unsigned char *stub_page;
>
>>> On 19.10.18 at 17:59, wrote:
> On 19/10/18 15:28, Wei Liu wrote:
>> @@ -347,6 +352,7 @@ void subarch_percpu_traps_init(void)
>> /* Common SYSCALL parameters. */
>> wrmsrl(MSR_STAR, XEN_MSR_STAR);
>> wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
>> +#endif
>
> It would be a wise p
flight 129136 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129136/
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 19.10.18 at 16:28, wrote:
> @@ -845,19 +865,7 @@ handle_ist_exception:
> /* We want to get straight to the IRET on the NMI exit path. */
> testb $3,UREGS_cs(%rsp)
> jzrestore_all_xen
> -GET_CURRENT(bx)
> -/* Send an IPI to ourselves to cover fo
Hi,
On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ian Jackson wrote:
> Andra Paraschiv writes ("[PATCH RESEND qemu-xen-traditional] xen/pt: allow
> QEMU to request MSI unmasking at bind time"):
> > When a MSI interrupt is bound to a guest using
> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) th
Commit 5c83511bdb9832 ("x86/paravirt: Use a single ops structure")
introduced a regression for out-of-tree modules using spinlocks, as
pv_lock_ops was exported via EXPORT_SYMBOL(), while the new pv_ops
structure now containing the pv lock operations is exported via
EXPORT_SYMBOL_GPL().
Change that
>>> On 19.10.18 at 16:28, wrote:
> @@ -548,10 +550,14 @@ ENTRY(ret_from_intr)
> GET_CURRENT(bx)
> testb $3, UREGS_cs(%rsp)
> jzrestore_all_xen
> +#ifdef CONFIG_PV
> movq VCPU_domain(%rbx), %rax
> cmpb $0, DOMAIN_is_32bit_pv(%rax)
> je
>>> On 19.10.18 at 17:14, wrote:
> The PV and HVM code both have a copy of these, which gives the false
> impression in the context switch code that they are PV/HVM specific.
>
> Move the storage into struct vcpu_msrs, and update all users to match.
>
> Signed-off-by: Andrew Cooper
Reviewed-by
>>> On 29.10.18 at 11:54, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1905,7 +1905,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
> if ( sharing_enomem )
> {
> int rv;
> -if ( (rv = mem_sharing_notify_enomem(currd, gf
>>> On 25.10.18 at 17:36, wrote:
> This is a stopgap solution until the toolstack side of initialisation can be
> sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working
> correctly even when nested virt hasn't been enabled for the domain.
>
> Update nvmx_handle_vmx_insn() to i
>>> On 25.10.18 at 17:38, wrote:
> Now that nvmx_handle_vmx_insn() performs all VT-x instruction checks, there is
> no need for redundant checking in vmx_inst_check_privilege(). Remove it, and
> take out the vmxon_check boolean which was plumbed through
> decode_vmx_inst().
>
> Signed-off-by: A
Hi,
On Tue, Oct 23, 2018 at 08:40:29PM +0200, Håkon Alstadheim wrote:
>
>
> Den 08. okt. 2018 16:32, skrev Boris Ostrovsky:
> >
> > Are these two patches still needed? ISTR they were written originally
> > to deal with guest trying to use device that was previously assigned to
> > another guest
On Mon, Oct 29, 2018 at 6:41 AM Razvan Cojocaru
wrote:
>
> This patch is a pre-requisite for the one fixing VGA logdirty
> freezes when using altp2m. It only concerns itself with the
> ranges allocation / deallocation / initialization part. While
> touching the code, I've switched global_logdirty
On Mon, Oct 29, 2018 at 6:41 AM Razvan Cojocaru
wrote:
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles logdirty VGA:
On Mon, Oct 29, 2018 at 6:42 AM Razvan Cojocaru
wrote:
>
> This patch is a pre-requisite for fixing the logdirty VGA issue
> (display freezes when switching to a new altp2m view early in a
> domain's lifetime), but sent separately for easier review.
> The new ept_set_ad_sync() function has been ad
On Mon, Oct 15, 2018 at 05:35:36PM +0100, Ian Jackson wrote:
> > +static int qmp_error_class_to_libxl_error_code(const
> > libxl__qmp_error_class c)
> > +{
> > +switch (c) {
> > +case LIBXL__QMP_ERROR_CLASS_GENERICERROR:
> > +return ERROR_QMP_GENERIC_ERROR;
> > +case LIBXL__QMP
Signed-off-by: Alexandru Isaila
Acked-by: Tamas K Lengyel
Acked-by: Jan Beulich
---
Changes since V1:
- Made style corrections suggested by Jan.
---
xen/arch/x86/hvm/hvm.c| 3 ++-
xen/arch/x86/mm/mem_sharing.c | 2 +-
xen/arch/x86/mm/p2m.c | 5 ++---
xen/com
Hello Julien
On 29.10.18 15:36, Julien Grall wrote:0
> I wrote down an answer yesterday (sent it today) to your previous
> answer. You may use the LRs information from the previous guest trap as
> interrupts are re-enabled before storing the LRs.
Yes, it is the case. I've overlooked that for some
On 29/10/2018 16:16, Andrii Anisov wrote:
Hello Julien
Hi,
On 29.10.18 15:36, Julien Grall wrote:0
I wrote down an answer yesterday (sent it today) to your previous
answer. You may use the LRs information from the previous guest trap as
interrupts are re-enabled before storing the LRs.
Ye
>>> On 15.10.18 at 12:30, wrote:
> (XEN) [22641] PUSH {sp 0, irq 30, vec 0x21}
This is the last push or pop.
> (XEN) [22650] WAKE PPR 0x0020
> (XEN)IRR
> 0200
> (XEN)ISR
>
>>> On 26.10.18 at 11:11, wrote:
> @@ -157,6 +157,21 @@
> #define VM_EVENT_X86_CR42
> #define VM_EVENT_X86_XCR0 3
>
> +/*
> + * The limit field is right-shifted by 12 bits if .ar.g is set.
> + */
This is supposed to be a single line comment.
> @@ -191,9 +206,19 @@ struct vm_event_regs_
On 29/10/18 16:33, Jan Beulich wrote:
On 15.10.18 at 12:30, wrote:
>> (XEN) [22641] PUSH {sp 0, irq 30, vec 0x21}
> This is the last push or pop.
>
>> (XEN) [22650] WAKE PPR 0x0020
>> (XEN)IRR
>> 02
>>> On 19.10.18 at 17:20, wrote:
> A PVH Dom0 might use TSC scaling or other HVM specific TSC
> adjustments, so only short-circuit the TSC setup for a classic PV
> Dom0.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing
Hello Julien
On 29.10.18 15:36, Julien Grall wrote:0
I wrote down an answer yesterday (sent it today) to your previous
answer. You may use the LRs information from the previous guest trap as
interrupts are re-enabled before storing the LRs.
Yes, it is the case. I've overlooked that for some excep
>>> On 19.10.18 at 17:20, wrote:
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
with one remark:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -346,6 +346,12 @@ struct xen_arch_domainconfig {
> #define X
>>> On 19.10.18 at 17:20, wrote:
> Add an option to allow trapping accesses to IO port 0xe9 for a PVH
> Dom0, so it can print to the HVM debug console. Note this is not
> enabled by default in order to prevent clashes with hardware on the
> system using 0xe9.
>
> Signed-off-by: Roger Pau Monné
On 19/10/18 16:20, Roger Pau Monne wrote:
> Add an option to allow trapping accesses to IO port 0xe9 for a PVH
> Dom0, so it can print to the HVM debug console. Note this is not
> enabled by default in order to prevent clashes with hardware on the
> system using 0xe9.
>
> Signed-off-by: Roger Pau M
On Mon, Oct 29, 2018 at 10:33:11AM -0600, Jan Beulich wrote:
> >>> On 15.10.18 at 12:30, wrote:
> > (XEN) [22641] PUSH {sp 0, irq 30, vec 0x21}
>
> This is the last push or pop.
>
> > (XEN) [22650] WAKE PPR 0x0020
> > (XEN)IRR
> > 02
>>> On 29.10.18 at 17:44, wrote:
> On 29/10/18 16:33, Jan Beulich wrote:
> On 15.10.18 at 12:30, wrote:
>>> (XEN) [22641] PUSH {sp 0, irq 30, vec 0x21}
>> This is the last push or pop.
>>
>>> (XEN) [22650] WAKE PPR 0x0020
>>> (XEN)IRR
> 02000
Hi all,
I just submitted a Xen Project stand submission and if everything goes ok, we
will be having a booth again like the last 5 years
Accepted stands should be announced by November 11
If you already know you are going, please add yourself to
https://docs.google.com/spreadsheets/d/1uk79a_iEe
>>> On 29.10.18 at 17:53, wrote:
> On 19/10/18 16:20, Roger Pau Monne wrote:
>> Add an option to allow trapping accesses to IO port 0xe9 for a PVH
>> Dom0, so it can print to the HVM debug console. Note this is not
>> enabled by default in order to prevent clashes with hardware on the
>> system us
On 29/10/18 16:58, Jan Beulich wrote:
On 29.10.18 at 17:44, wrote:
>> On 29/10/18 16:33, Jan Beulich wrote:
>> On 15.10.18 at 12:30, wrote:
(XEN) [22641] PUSH {sp 0, irq 30, vec 0x21}
>>> This is the last push or pop.
>>>
(XEN) [22650] WAKE PPR 0x0020
(XE
flight 129141 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129141/
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
Anthony PERARD writes ("Re: [PATCH v5 03/15] libxl_qmp: Implement fd callback
and read data [and 1 more messages]"):
> On Mon, Oct 15, 2018 at 05:35:36PM +0100, Ian Jackson wrote:
> > What are LIBXL__QMP_ERROR_CLASSes and why are they even different from
> > ERROR_* values ? Maybe one of them is
Microsoft has a habit of re-numbering sections in the spec. so avoid
referring to section numbers in comments. Also remove the URL for the
spec. from the boilerplate... Again, Microsoft has a habit of changing
these too.
This patch also cleans up some > 80 character lines.
Purely cosmetic. No fun
The P2M common code currently restricts the MMIO mapping order of any
domain with IOMMU mappings, but that is not using shared tables, to 4k.
This has been shown to have a huge performance cost when passing through
a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the guest
boot time
The 'viridian_vp_assist', 'viridian_hypercall_gpa' and
'viridian_reference_tsc' union types are identical in layout. The layout
is also common throughout the specification [1].
This patch declares a common 'viridian_page_msr' type and converts the rest
of the code to use that type for both the hyp
...into new 'synic' module.
The SynIC (synthetic interrupt controller) is specified [1] to be a super-
set of a virtualized LAPIC, and its definition encompasses all
enlightenments related to virtual interrupt control.
This patch reduces the size of the main viridian source module by giving
these
Subsequent patches will introduce support for more viridian enlightenments
which will make a single source module quite lengthy.
This patch therefore creates a new arch/x86/hvm/viridian sub-directory and
moves viridian.c into that.
The patch also fixes some bad whitespace whilst moving the code.
The specification [1] defines a type so we should use it, rather than just
OR-ing and AND-ing magic bits.
No functional change.
NOTE: The type defined in the specification does include an anonymous
sub-struct in the page type but, as we currently use only the first
element, the struct
...into new 'time' module.
This patch reduces the size of the main viridian source module by
moving time related enlightenments into their own source module. This is
done in anticipation of implementation of more such enightenments and
a desire to not further lengthen the main source module when t
They're not really useful so maintaining them is pointless.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/hvm/viridian/viridian.c | 21 -
xen/include/asm-x86/perfc_defn.h | 26 --
2 files changed,
I plan to add implementations for more viridian enlightenments in the near
future. This series is just some cleanup I've been doing in preparation.
Paul Durrant (8):
viridian: move the code into its own sub-directory
viridian: remove MSR perf counters
viridian: remove comments referencing se
The P2M code currently contains many loops to deal with the fact that,
while it may be require to handle page orders greater than 4k, the
IOMMU map and unmap functions do not.
This patch adds a page_order parameter to those functions and implements
the necessary loops within. This allows the P2M co
Apologies. Ignore this as it is just a re-post of a stale patch.
Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 29 October 2018 18:02
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
>
> Subject:
Apologies. Ignore this as it is just a re-post of a stale patch.
Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 29 October 2018 18:02
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; George Dun
The 'vp_assist' page is currently an example of a guest page which needs to
be kept mapped throughout the life-time of a guest, but there are other
such examples in the specifiction [1]. This patch therefore introduces a
generic 'viridian_page' type and converts the current vp_assist/apic_assist
re
info->nr_rings isn't adjusted in case of ENOMEM error from
negotiate_mq(). This leads to kernel panic in error path.
Typical call stack involving panic -
#8 page_fault at 8175936f
[exception RIP: blkif_free_ring+33]
RIP: a0149491 RSP: 8804f7673c08 RFLAGS: 00010292
.
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org
Hi Samuel,
On 29/10/18 18:01, Samuel Ortiz wrote:
ACPI tables are platform and machine type and even architecture
agnostic, and as such we want to provide an internal ACPI API that
only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independent
On Fri, 26 Oct 2018, Jan Beulich wrote:
> >>> On 23.10.18 at 04:03, wrote:
> > @@ -391,31 +394,79 @@ static void dump_console_ring_key(unsigned char key)
> > free_xenheap_pages(buf, order);
> > }
> >
> > -/* CTRL- switches input direction between Xen and DOM0. */
> > +/*
> > + * CTRL- chan
On Wed, 24 Oct 2018, Oleksandr Andrushchenko wrote:
> On 10/23/2018 05:03 AM, Stefano Stabellini wrote:
> > Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> > mechanism to allow for switching between Xen, Dom0, and any of the
> > initial DomU created from Xen alongside Dom0 out o
On 10/29/18 8:00 PM, Stefano Stabellini wrote:
On Wed, 24 Oct 2018, Oleksandr Andrushchenko wrote:
On 10/23/2018 05:03 AM, Stefano Stabellini wrote:
+ * console_rx=0 => input to xen
+ * console_rx=1 => input to dom0
+ * console_rx=N => input to dom(N-1)
So, why do you only handle case 0/1?
+#
On Wed, 24 Oct 2018, Oleksandr Tyshchenko wrote:
> Hi, Stefano
>
> On Tue, Oct 23, 2018 at 5:04 AM Stefano Stabellini
> wrote:
> >
> > Make vpl011 being able to be used without a userspace component in Dom0.
> > In that case, output is printed to the Xen serial and input is received
> > from the
On Wed, 24 Oct 2018, Oleksandr Andrushchenko wrote:
> On 10/23/2018 05:03 AM, Stefano Stabellini wrote:
> > To avoid mixing the output of different domains on the console, buffer
> > the output chars and print line by line. Unless the domain has input
> > from the serial, in which case we want to p
On Mon, Oct 29, 2018 at 04:58:22PM +0200, Pasi Kärkkäinen wrote:
> Hi,
>
> On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ian Jackson wrote:
> > Andra Paraschiv writes ("[PATCH RESEND qemu-xen-traditional] xen/pt: allow
> > QEMU to request MSI unmasking at bind time"):
> > > When a MSI interrupt is b
On Fri, 26 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/15/18 12:03 AM, Stefano Stabellini wrote:
> > Backport commit 3714ce1d6655098ee69ede632883e5874d67e4ab
> > "iommu/arm-smmu: Disable stalling faults for all endpoints" from the
> > Linux kernel.
> >
> > Original commit message:
> >
From: Stefano Stabellini
Backport commit 3714ce1d6655098ee69ede632883e5874d67e4ab
"iommu/arm-smmu: Disable stalling faults for all endpoints" from the
Linux kernel. This works-around Erratum #842869.
Original commit message:
Enabling stalling faults can result in hardware deadlock on poorly
On 10/29/18 9:14 PM, Stefano Stabellini wrote:
From: Stefano Stabellini
Backport commit 3714ce1d6655098ee69ede632883e5874d67e4ab
"iommu/arm-smmu: Disable stalling faults for all endpoints" from the
Linux kernel. This works-around Erratum #842869.
Original commit message:
Enabling stallin
On Fri, 26 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/26/18 7:04 PM, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > xen_create_contiguous_region has now only an implementation if
> > CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
> > we do hav
On Mon, 8 Oct 2018, Julien Grall wrote:
> The new helpers make it easier to read the code by abstracting the way to
> set/get an MFN from/to an LPAE entry. The helpers are using "walk" as the
> bits are common across different LPAE stages.
>
> At the same time, use the new helpers to replace the v
On Mon, 8 Oct 2018, Julien Grall wrote:
> Currently, lpae_is_{table, mapping} helpers will always return false on
> entries with the valid bit unset. However, it would be useful to have them
> operating on any entry. For instance to store information in advance but
> still request a fault.
>
> Wit
On Mon, 8 Oct 2018, Julien Grall wrote:
> GUEST_BUG_ON may be used in other files doing guest emulation.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
>
> The patch was previously sent separately.
> ---
> xen/arch/arm/traps.c| 24
>
1 - 100 of 117 matches
Mail list logo
