On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
Hi everyone,
I saw some people passingly mention this on the list before but just in
case it has been missed, my serial is also being spammed with the following
printouts with both Xen 4.6 RC1 and the latest staging build:
...
(XEN) [VT-D]DMAR:[DMA Re
flight 60835 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60835/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf b199d9418820b873d0e05190fe5dc947a6f72b14
baseline version:
ovmf 70bd69912ad2fb6e99271b418f87b98ebb3
Hi Andrew,
Thank you so much for your suggestion! I tried but have some questions.
2015-08-24 4:10 GMT-04:00 Andrew Cooper :
>
> On 24/08/2015 04:01, Meng Xu wrote:
>
> Hi,
>
> I'm trying to use a PV guest VM on Xen to help debug Linux.
> I was using VirtualBox to help debug Linux kernel by redir
Hi Rafal,
Please have a try adding "--iodepth_batch=32 --iodepth_batch_complete=32" to
the fio command line.
I didn't see this issue any more, neither for domU.
Thanks,
-Bob
On 08/21/2015 04:46 PM, Rafal Mielniczuk wrote:
> On 19/08/15 12:12, Bob Liu wrote:
>> Hi Jens & Christoph,
>>
>> Rafal r
This patch adds the following arch hooks in scheduler:
- vmx_pre_ctx_switch_pi():
It is called before context switch, we update the posted
interrupt descriptor when the vCPU is preempted, go to sleep,
or is blocked.
- vmx_post_ctx_switch_pi()
It is called after context switch, we update the posted
When guest changes its interrupt configuration (such as, vector, etc.)
for direct-assigned devices, we need to update the associated IRTE
with the new guest vector, so external interrupts from the assigned
devices can be injected to guests without VM-Exit.
For lowest-priority interrupts, we use ve
This patch initializes the VT-d Posted-interrupt Descriptor.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
---
v3:
- Move pi_desc_init() to xen/arch/x86/hvm/vmx/vmcs.c
- Remove the 'inline' fla
This patch adds some helper functions to manipulate the
Posted-Interrupts Descriptor.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Reviewed-by: Konrad Rzeszutek Wilk
---
v4:
- Newly added
xen/include/asm-x86/hvm/vmx/vmx.h | 21
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
This patch adds variable 'iommu_intpost' to contr
This patch adds cmpxchg16b support for x86-64, so software
can perform 128-bit atomic write/read.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
---
v6:
- Fix a typo
v5:
- Change back the parameters of __cmpxchg16b() to __uint128_t *
- Remove pointless cast for 'ptr'
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
You can find the VT-d Posted-Interrtups Spec. in
This patch adds an API which is used to update the IRTE
for posted-interrupt when guest changes MSI/MSI-X information.
CC: Yang Zhang
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Acked-by: Kevin Tian
---
v6:
- In some error cases, the desc->lock wi
Add the design doc for VT-d PI.
CC: Kevin Tian
CC: Yang Zhang
CC: Jan Beulich
CC: Keir Fraser
CC: Andrew Cooper
CC: George Dunlap
Signed-off-by: Feng Wu
Reviewed-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
---
v6:
- Better description in English
docs/misc/vtd-pi.txt | 332
Enable VT-d Posted-Interrupts and add a command line
parameter for it.
Signed-off-by: Feng Wu
Reviewed-by: Kevin Tian
---
v6:
- Change the default value to 'false' in xen-command-line.markdown
docs/misc/xen-command-line.markdown | 9 -
xen/drivers/passthrough/iommu.c | 3 +++
2 fil
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Fe
Currently, we don't support urgent interrupt, all interrupts
are recognized as non-urgent interrupt, so we cannot send
posted-interrupt when 'SN' is set.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Reviewed-by: Konrad Rzeszutek Wilk
---
v6:
- Add s
When a vCPU is running in Root mode and a notification event
has been injected to it. we need to set VCPU_KICK_SOFTIRQ for
the current cpu, so the pending interrupt in PIRR will be
synced to vIRR before VM-Exit in time.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-of
This patch includes the following aspects:
- Add a global vector to wake up the blocked vCPU
when an interrupt is being posted to it (This
part was sugguested by Yang Zhang ).
- Adds a new per-vCPU tasklet to wakeup the blocked
vCPU. It can be used in the case vcpu_unblock
cannot be called
Add the utility to dump the posted format IRTE.
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Feng Wu
---
v6:
- Fix a typo
v4:
- Newly added
xen/drivers/passthrough/vtd/utils.c | 43 +++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/xen/drive
Move some APIC related macros to apicdef.h, so they can be used
outside of vlapic.c.
Signed-off-by: Feng Wu
---
v6:
- Newly introduced.
xen/arch/x86/hvm/vlapic.c | 5 -
xen/include/asm-x86/apicdef.h | 4
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hv
Remove pointless casts.
Signed-off-by: Feng Wu
Reviewed-by: Konrad Rzeszutek Wilk
---
v5:
- Newly added.
xen/drivers/passthrough/vtd/utils.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/utils.c
b/xen/drivers/passthrough/vtd/u
Extend struct iremap_entry according to VT-d Posted-Interrupts Spec.
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Feng Wu
Acked-by: Kevin Tian
---
v4:
- res_4 is not a bitfiled, correct it.
- Expose 'im' to remapped irte as well.
v3:
- Use u32 instead of u64 to define the bitfields in 'struct
Extend struct pi_desc according to VT-d Posted-Interrupts Spec.
CC: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Feng Wu
Reviewed-by: Andrew Cooper
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
---
v3:
- Use u32 instead of u64 for the bitfield in 's
Hi everyone,
I saw some people passingly mention this on the list before but just in
case it has been missed, my serial is also being spammed with the following
printouts with both Xen 4.6 RC1 and the latest staging build:
...
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33
>> @@ -1768,7 +1768,7 @@ static void vmx_enable_msr_exit_interception(struct
>> domain *d)
>>
>> static bool_t vmx_is_singlestep_supported(void)
>> {
>> -return cpu_has_monitor_trap_flag;
>> +return cpu_has_monitor_trap_flag ? 1 : 0;
>
> Prevailing style would tend towards !!cpu_has_moni
On 08/25/2015 12:52 AM, Andrew Cooper wrote:
On 24/08/2015 20:27, Juergen Gross wrote:
On 08/24/2015 07:37 PM, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
---
docs/Makefile |2 +-
docs/features/template.pandoc | 55
+
2
On 24/08/2015 20:55, Tamas K Lengyel wrote:
> The function supposed to return a boolean but instead it returned
> the value 0x800 which is the Intel internal flag for MTF. This has
> caused various checks using this function to falsely report no MTF
> capability.
Ouch. Given than bool_t is cu
On 24/08/2015 20:27, Juergen Gross wrote:
> On 08/24/2015 07:37 PM, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> docs/Makefile |2 +-
>> docs/features/template.pandoc | 55
>> +
>> 2 files changed, 56 insertions(+)
flight 60829 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 60773
test-armhf-armhf-xl-cu
On Mon, Aug 24, 2015 at 05:35:21AM -0600, Jan Beulich wrote:
> >>> On 22.08.15 at 15:59, wrote:
> > On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote:
> >> >>> On 20.07.15 at 16:29, wrote:
> >> > Build xen.gz with EFI code. We need this to support multiboot2
> >> > protocol on EFI platf
The function supposed to return a boolean but instead it returned
the value 0x800 which is the Intel internal flag for MTF. This has
caused various checks using this function to falsely report no MTF
capability.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/hvm/vmx/vmx.c | 2 +-
1 file cha
On Mon, Aug 24, 2015 at 06:29:31AM -0600, Jan Beulich wrote:
> >>> On 21.08.15 at 19:51, wrote:
> > I don't think we can rev ipxe.git to the latest in Xen 4.6 time-frame.
> > But having that patch should help with compile issues, like mine.
>
> Agreed.
>
> > So how do we want to fix this in 4.6
Specificially we are pulling in the upstream patch (commit
1b56452121672e6408c38ac8926bdd6998a39004)):
[ath9k] Remove confusing logic inversion in an ANI variable
Signed-off-by: Konrad Rzeszutek Wilk
---
tools/firmware/etherboot/patches/build_fix_4.patch | 225 +
tools/firmwa
On 08/24/2015 07:37 PM, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
---
docs/Makefile |2 +-
docs/features/template.pandoc | 55 +
2 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 docs/features/template.
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure th
From: "Luis R. Rodriguez"
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that also
ensure the ioremapped area is requested as write-combining.
There are a
From: "Luis R. Rodriguez"
This lets drivers take advantage of PAT when available. It should help
with the transition of converting video drivers over to ioremap_wc()
to help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache(), see:
de33c442ed2
From: "Luis R. Rodriguez"
Ingo,
This is my pending series of patches for both write-combining and moving
Linux' use of MTRR into the grave. It combines three set of straggler patch
series which have been pending integration for a while now. The rename patches
do not depend in any way with the MT
From: "Luis R. Rodriguez"
The crusade to replace mtrr_add() with architecture agnostic
arch_phys_wc_add() is complete, this will ensure write-combining
implementations (PAT on x86) is taken advantage instead of using
MTRR. With the crusade done now, hide direct MTRR access for
drivers.
Update x8
From: "Luis R. Rodriguez"
dma_alloc_writecombine()'s call and return value check is tangled in all
in one call. Untangle both calls according to kernel coding style.
Signed-off-by: Luis R. Rodriguez
Acked-by: Vinod Koul
Cc: Vinod Koul
Cc: Dan Williams
Cc: dmaeng...@vger.kernel.org
Cc: x...@k
From: "Luis R. Rodriguez"
Rename dma_*_writecombine() to dma_*_wc(), so that the naming
is coherent across the various write-combining APIs.
The following Coccinelle SmPL patch was used for this simple
transformation:
@ rename_dma_alloc_writecombine @
expression dev, size, dma_addr, gfp;
@@
-d
From: "Luis R. Rodriguez"
PCI BARs tell us whether prefetching is safe, but they don't say
anything about write combining (WC). WC changes ordering rules and
allows writes to be collapsed, so it's not safe in general to use it on
a prefetchable region.
Add pci_iomap_wc() and pci_iomap_wc_range()
From: "Luis R. Rodriguez"
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRR if
write-combining is available, in order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a
From: "Luis R. Rodriguez"
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRR if
write-combining is available, in order to take advantage of that also
ensure the ioremapped area is requested as write-combining.
There are a
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but since we
know the framebuffer is isolated already on an ioremap() we can take
advantage of write combining for performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure th
On Fri, Aug 21, 2015 at 06:53:20PM +0200, Roger Pau Monne wrote:
> Place the calls to xc_vcpu_setcontext and the allocation of the hypercall
> buffer into the arch-specific vcpu hooks. This is needed for the next patch,
s/next patch/$title/ please
> so x86 HVM guests can initialize the BSP using
Signed-off-by: Andrew Cooper
---
docs/Makefile |2 +-
docs/features/template.pandoc | 55 +
2 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 docs/features/template.pandoc
diff --git a/docs/Makefile b/docs/Makefile
Signed-off-by: Andrew Cooper
---
docs/features/migration.pandoc | 90
1 file changed, 90 insertions(+)
create mode 100644 docs/features/migration.pandoc
diff --git a/docs/features/migration.pandoc b/docs/features/migration.pandoc
new file mode 100644
i
An issue which Xen has is an uncertain support statement for features.
Given the success seen with docs/misc/xen-command-line.markdown, and in
particular keeping it up to date, introduce a similar system for
features.
Patch 1 introduces a proposed template (and a makefile tweak to include
the new
Guys, especially GRUB2 maintainers,
On Mon, Jul 20, 2015 at 04:35:48PM +0200, Daniel Kiper wrote:
> Hi,
>
> This patch series:
> - enables EFI boot services usage in loaded images
> by multiboot2 protocol,
> - add support for multiboot2 protocol compatible
> relocatable images,
> - f
El 21/08/15 a les 23.00, Andrew Cooper ha escrit:
> On 21/08/15 17:53, Roger Pau Monne wrote:
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -784,6 +784,25 @@ struct start_info {
>> };
>> typedef struct start_info start_info_t;
>>
>> +/*
>> + * Start of day structure
Hi,
While the Developer Summit was happening in Seattle, I set up a
XenServer nightly test on -rc1(ish).
There were no identified issues, which is a clear testament to quality
of the 4.6, and shows a substantial improvement over previous releases.
As 4.6 has matched our quality bars for inclusio
On 24/08/15 12:47, Jan Beulich wrote:
On 24.08.15 at 12:36, wrote:
>> The infrastructure around xenheap_max_mfn() is supposed cause all
>> xenheap page allocations to fall within the Xen direct mapped region,
>> but experimentally doesn't work correctly.
>>
>> In all cases I have seen, the ba
>>> On 21.08.15 at 19:51, wrote:
> I don't think we can rev ipxe.git to the latest in Xen 4.6 time-frame.
> But having that patch should help with compile issues, like mine.
Agreed.
> So how do we want to fix this in 4.6 time-frame?
Pull the one patch (or a few more hand selected ones if need b
>>> On 21.08.15 at 19:51, wrote:
> This essentially reverts c/s 2037f2adb "x86: introduce
> alloc_vcpu_guest_context()", including the newer arm bits, but achieves
> the same end goal by using the newer vmalloc() infrastructure.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
_
>>> On 21.08.15 at 20:10, wrote:
> On 21/08/15 18:55, Konrad Rzeszutek Wilk wrote:
>> On Fri, Aug 21, 2015 at 06:51:46PM +0100, Andrew Cooper wrote:
>>> This essentially reverts c/s 2037f2adb "x86: introduce
>>> alloc_vcpu_guest_context()", including the newer arm bits, but achieves
>>> the same e
On 24/08/15 11:43, Roger Pau Monné wrote:
> El 21/08/15 a les 22.36, Andrew Cooper ha escrit:
>> On 21/08/15 17:53, Roger Pau Monne wrote:
>>> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
>>> VCPUOP_is_up hypercalls from HVM guests.
>>>
>>> This patch introduces a new struct
>>> On 24.08.15 at 12:36, wrote:
> The infrastructure around xenheap_max_mfn() is supposed cause all
> xenheap page allocations to fall within the Xen direct mapped region,
> but experimentally doesn't work correctly.
>
> In all cases I have seen, the bad xenheap allocations have been from
> call
>>> On 22.08.15 at 15:59, wrote:
> On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > Build xen.gz with EFI code. We need this to support multiboot2
>> > protocol on EFI platforms.
>> >
>> > If we wish to load not ELF file using multiboot (v1) or
>>> On 22.08.15 at 14:33, wrote:
> On Thu, Aug 20, 2015 at 09:18:17AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > --- a/xen/arch/x86/efi/stub.c
>> > +++ b/xen/arch/x86/efi/stub.c
>> > @@ -4,9 +4,14 @@
>> > #include
>> > #include
>> >
>> > -#ifndef efi_enabled
>> > -cons
El 21/08/15 a les 22.36, Andrew Cooper ha escrit:
> On 21/08/15 17:53, Roger Pau Monne wrote:
>> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
>> VCPUOP_is_up hypercalls from HVM guests.
>>
>> This patch introduces a new structure (vcpu_hvm_context) that should be used
>> in
(Following up from a discussion at the Seattle Summit).
While the theoretical Xen x86 host memory limit is 16TB (or 123TB with
CONFIG_BIGMEM), Xen doesn't actually function correctly if host ram
exceeds the addressable range in the directmap region, which is at the
5TB boundary (or 3.5TB with CONF
On Wed, Aug 19, 2015 at 9:23 PM, Julien Grall wrote:
> Hi,
>
> On 19/08/2015 06:25, Murilo Opsfelder Araujo wrote:
>>
>> The commit 091208a676dfdabb2b8fe86ee155c6fc80081b69 "xen/tmem: Use
>> xen_page_to_gfn rather than pfn_to_gfn" left behind a call to
>> xen_tmem_get_page() receiving pfn instead
On Thu, Aug 20, 2015 at 8:27 AM, David Vrabel wrote:
> On 19/08/15 14:25, Murilo Opsfelder Araujo wrote:
>> The commit 091208a676dfdabb2b8fe86ee155c6fc80081b69 "xen/tmem: Use
>> xen_page_to_gfn rather than pfn_to_gfn" left behind a call to
>> xen_tmem_get_page() receiving pfn instead of page.
>>
>
From: Andy Lutomirski
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under certain loads, this c
On 24/08/2015 04:01, Meng Xu wrote:
> Hi,
>
> I'm trying to use a PV guest VM on Xen to help debug Linux.
> I was using VirtualBox to help debug Linux kernel by redirecting the
> output of the serial port of the VM to a file in the host. I can do it
> in VirtualBox.
>
> [Why do I want to achieve th
67 matches
Mail list logo
