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
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
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 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 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
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:
> >
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
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
flight 129123 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129123/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 129086
On Mon, 8 Oct 2018, Julien Grall wrote:
> A follow-up patch will re-purpose the valid bit of LPAE entries to
> generate fault even on entry containing valid information.
>
> This means that when translation a guest VA to guest PA (e.g IPA) will
> fail if the Stage-2 entries used have the valid
On Mon, 8 Oct 2018, Julien Grall wrote:
> The LPAE format allows to store information in an entry even with the
> valid bit unset. In a follow-up patch, we will take advantage of this
> feature to re-purpose the valid bit for generating a translation fault
> even if an entry contains valid
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
flight 129151 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129151/
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
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
>
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.
>
>
On Mon, 8 Oct 2018, Julien Grall wrote:
> Generate P2M table entry requires to set some default values which are
> worth to explain in a comment. At the moment, there are 2 places where
> such entry are created but only one as proper comment.
>
> Some move the code to generate P2M table entry in
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
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
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
>>> 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
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
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
>>> 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:
>>> ---
>>> 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
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 +-
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
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
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
flight 129105 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129105/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
This run is configured for baseline tests only.
flight 75535 xen-4.9-testing real [real]
http://osstest.xensource.com/osstest/logs/75535/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf
On 10/25/18 11:56 AM, Joe Jin wrote:
> I just discussed this patch with Boris in private, his opinions(Boris,
> please correct me if any misunderstood) are:
>
> 1. With/without the check, both are incorrect, he thought we need to
>prevented unalloc'd free at here.
> 2. On freeing, if upper
Hello,
We are using Hikey960 with Debian as Dom0 and DomU. This board has only
WiFi interface. We want to create bridge between Dom0 and DomU so that DomU
has internet access. We tried to create bridge using brtcl command, but it
is not working. Please provide pointers.
--
This
message
This run is configured for baseline tests only.
flight 75537 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75537/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 6 libvirt-build fail baseline untested
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-amd64-pvgrub
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
flight 129162 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129162/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c87ac38cf280fa969f1033de3c5b7a157aac8cbc
baseline version:
ovmf
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 independently
from the PC or Q35 machine types, we are moving a
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
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
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
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 ---
>>> 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
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
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
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
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
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:
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
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
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
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
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 ++---
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
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:
> @@ -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 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:
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
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
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
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
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
>>> 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
>>> 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
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)
>>> 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(_lock);
> }
>
> +static int acpi_c1e_quirk(int dir, unsigned int port, unsigned int bytes,
> +
>>> 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(
>
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
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
>>> 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
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
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
...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
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
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
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
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.
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.
>>> 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
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
>>
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
>>> 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
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
>>> 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
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 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
>>> 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
>
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
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
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
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:
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
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
94 matches
Mail list logo
