>>> On 22.01.18 at 22:19, wrote:
> Jan, All,
>
>> On 10 Jan 2018, at 16:02, Jan Beulich wrote:
>>
> On 10.01.18 at 16:14, wrote:
>>> In the early steps of compilation, the asm header files are created, such
>>> as include/asm-$(TARGET_ARCH)/asm-offsets.h. These files depend on the
>>> asse
>>> On 22.01.18 at 20:02, wrote:
> On 22/01/18 18:48, George Dunlap wrote:
>> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
>>> Jan: As to the things not covered by the current XPTI, hiding most of
>>> the .text section is important to prevent fingerprinting or ROP
>>> scanning. This is a defence-
>>> On 23.01.18 at 06:50, wrote:
> On 22/01/18 17:51, Jan Beulich wrote:
>> But isn't that model having the same synchronization issues upon
>> guest L4 updates which Andrew was fighting with?
>
> I don't think so, as the number of shadows will always only be max. 1
> with my approach.
How can I
>>> On 23.01.18 at 07:34, wrote:
> On 22/01/18 19:39, Andrew Cooper wrote:
>> One of my concerns is that this patch series moves further away from the
>> secondary goal of my KAISER series, which was to have the IDT and GDT
>> mapped at the same linear addresses on every CPU so a) SIDT/SGDT don't
flight 118272 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118272/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt broken in 118266
test-amd6
>>> On 22.01.18 at 18:28, wrote:
> I only see 1 CPU core on Xen 4.9 when booted via grub instead of 8.
>
> It's may be related to :
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820807
> - https://xenproject.atlassian.net/browse/XEN-42
While this suggests you've indeed tried to look ar
>>> On 22.01.18 at 19:31, wrote:
> On Mon, Jan 22, 2018 at 06:19:43PM +, Andrew Cooper wrote:
>> On 22/01/18 18:17, Wei Liu wrote:
>> > So you want reloc.o to contain pvh_info_reloc unconditionally?
>> >
>> > Fundamentally I don't think I care enough about all the bikeshedding so
>> > if Jan a
Hi all,
just a quick note that I submitted the application for GSoC.
The project list is not perfect and I removed a number of projects because I
believe they were completed (or at least started by others). A Thank You to
Mirage OS and Unikraft folks for adding new projects
If we do get accept
>>> On 23.01.18 at 01:41, wrote:
> On 23/01/2018 00:38, Stefano Stabellini wrote:
>> On Tue, 23 Jan 2018, Andrew Cooper wrote:
>>> On 22/01/2018 23:48, Stefano Stabellini wrote:
Hi all,
Running Xen inside QEMU x86 without KVM acceleartion and without VMX
emulation leads to the
On 23/01/18 09:53, Jan Beulich wrote:
On 23.01.18 at 07:34, wrote:
>> On 22/01/18 19:39, Andrew Cooper wrote:
>>> One of my concerns is that this patch series moves further away from the
>>> secondary goal of my KAISER series, which was to have the IDT and GDT
>>> mapped at the same linear ad
>>> On 22.01.18 at 13:32, wrote:
> show_guest_stack() and compat_show_guest_stack() stop dumping the
> stack of the guest whenever its virtual address reaches the same
> alignment which is used for the hypervisor stacks.
>
> Remove this arbitrary limit and try to dump a fixed number of lines
> in
>>> On 23.01.18 at 10:24, wrote:
> On 23/01/18 09:53, Jan Beulich wrote:
> On 23.01.18 at 07:34, wrote:
>>> On 22/01/18 19:39, Andrew Cooper wrote:
One of my concerns is that this patch series moves further away from the
secondary goal of my KAISER series, which was to have the IDT
>>> On 09.11.17 at 12:13, wrote:
> Change gcov to cov (for internal interfaces) or coverage (for the
> public ones).
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Ian Jackson
> Cc: Wei Liu
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano
... your report is very likely duplicating earlier ones where the
ACPI root point cannot be found without it being properly
propagated through by grub from EFI to Xen. Iirc the only
way around that is to chainload xen.efi, if the grub used
doesn't support the extensions needed to boot Xen via the
On 23/01/18 09:40, Jan Beulich wrote:
On 23.01.18 at 06:50, wrote:
>> On 22/01/18 17:51, Jan Beulich wrote:
>>> But isn't that model having the same synchronization issues upon
>>> guest L4 updates which Andrew was fighting with?
>>
>> I don't think so, as the number of shadows will always on
As XSAs 246 and 247 have shown, not doing so is rather dangerous.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Acked-by: Kevin Tian
---
v3: Make sure vm_event_cancel_slot() is called from the new error path in
p2m_mem_paging_populate(). Downgrade Kevin's R-b to an ack for that
rea
On 23/01/18 10:26, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> show_guest_stack() and compat_show_guest_stack() stop dumping the
>> stack of the guest whenever its virtual address reaches the same
>> alignment which is used for the hypervisor stacks.
>>
>> Remove this arbitrary limit a
1: replace vCPU's dirty CPU mask by numeric ID
2: x86: avoid explicit TLB flush when saving exec state
3: drop "domain_" prefix from struct domain's dirty CPU mask
Signed-off-by: Jan Beulich
---
v2: Addressing review comments - see individual patches.
___
>>> On 23.01.18 at 10:39, wrote:
>> ... your report is very likely duplicating earlier ones where the
>> ACPI root point cannot be found without it being properly
>> propagated through by grub from EFI to Xen. Iirc the only
>> way around that is to chainload xen.efi, if the grub used
>> doesn't s
On 23/01/18 10:31, Jan Beulich wrote:
On 23.01.18 at 10:24, wrote:
>> On 23/01/18 09:53, Jan Beulich wrote:
>> On 23.01.18 at 07:34, wrote:
On 22/01/18 19:39, Andrew Cooper wrote:
> One of my concerns is that this patch series moves further away from the
> secondary goal of
>>> On 23.01.18 at 10:58, wrote:
> On 23/01/18 10:26, Jan Beulich wrote:
> On 22.01.18 at 13:32, wrote:
>>> show_guest_stack() and compat_show_guest_stack() stop dumping the
>>> stack of the guest whenever its virtual address reaches the same
>>> alignment which is used for the hypervisor sta
At most one bit can be set in the masks, so especially on larger systems
it's quite a bit of unnecessary memory and processing overhead to track
the information as a mask. Store the numeric ID of the respective CPU
instead, or VCPU_CPU_CLEAN if no dirty state exists.
Signed-off-by: Jan Beulich
--
Now that it's obvious that only a single dirty CPU can exist for a vCPU,
it becomes clear that flush_mask() doesn't need to be invoked when
sync_local_execstate() was already run. And with the IPI handler
clearing FLUSH_TLB from the passed flags anyway if
__sync_local_execstate() returns true, it a
It being a field of struct domain is sufficient to recognize its
purpose.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by: George Dunlap
Reviewed-by: Andrew Cooper
---
v2: White space changes (consolidate split line statements into single
line ones). Re-base.
--- a/xen/arch/ar
On 23/01/2018 10:07, Jan Beulich wrote:
> 1: replace vCPU's dirty CPU mask by numeric ID
> 2: x86: avoid explicit TLB flush when saving exec state
> 3: drop "domain_" prefix from struct domain's dirty CPU mask
Much clearer.
Reviewed-by: Andrew Cooper
On 23/01/18 11:11, Jan Beulich wrote:
On 23.01.18 at 10:58, wrote:
>> On 23/01/18 10:26, Jan Beulich wrote:
>> On 22.01.18 at 13:32, wrote:
show_guest_stack() and compat_show_guest_stack() stop dumping the
stack of the guest whenever its virtual address reaches the same
al
>>> On 04.12.17 at 13:46, wrote:
> At least Linux kernels have been able to work with gzip-ed initrd for
> quite some time; initrd compressed with other methods aren't even being
> attempted to unpack. Furthermore the unzip-ing routine used here isn't
> capable of dealing with various forms of con
On 23/01/2018 10:12, Jan Beulich wrote:
> @@ -803,6 +803,11 @@ static inline int vcpu_runnable(struct v
> atomic_read(&v->domain->pause_count));
> }
>
> +static inline bool vcpu_cpu_dirty(const struct vcpu *v)
> +{
Oh - one extra through. BUILD_BUG_ON(NR_CPUS >= VCPU_CPU_CLEAN) ?
Prereq: x86: slightly reduce Meltdown band-aid overhead
(https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01609.html)
The overall effect of this series is smaller than that of the single
patch above (up to 1% in my measurements, but again instead
of the almost 40% loss of performanc
CR3 is - during normal operation - only ever loaded from v->arch.cr3,
so there's no need to read the actual control register. For CR4 we can
generally use the cached value on all synchronous entry end exit paths.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x
Introduce a synthetic feature flag to use alternative instruction
patching to NOP out all code on entry/exit paths other than those
involved in NMI/#MC handling (the patching logic can't properly handle
those paths yet). Having NOPs here is generally better than using
conditional branches.
Also ch
When XPTI is active, the CR3 load in restore_all_guest is sufficient
when switching to user mode, improving in particular system call and
page fault exit paths for the guest.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -220,10 +220,20 @@ int pv_dom
toggle_guest_mode() is only ever being called for 64-bit PV vCPU-s -
replace the 32-bit PV conditional by an ASSERT().
Introduce a local helper without 32-bit PV conditional, to be used by
both pre-existing functions.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/
On Wed, Dec 20, 2017 at 09:13:34AM -0700, Jan Beulich wrote:
> >>> On 18.10.17 at 13:40, wrote:
> > +if ( new_enabled && !new_masked && (!msix->enabled || msix->masked) )
> > +{
> > +for ( i = 0; i < msix->max_entries; i++ )
> > +{
> > +if ( msix->entries[i].mas
On 01/23/2018 04:06 AM, Simon Gaiser wrote:
> George Dunlap:
>> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
>> the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people
>> able to run PVH kernels to switch their PV guests directly to PVH
>> guests; and second, eve
On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote:
> At least Linux kernels have been able to work with gzip-ed initrd for
> quite some time; initrd compressed with other methods aren't even being
> attempted to unpack. Furthermore the unzip-ing routine used here isn't
> capable of dealin
Hi Jan,
On 23/01/18 10:16, Jan Beulich wrote:
It being a field of struct domain is sufficient to recognize its
purpose.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by: George Dunlap
Reviewed-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
---
v2: White space changes (cons
Hi Jan,
On 23/01/18 10:12, Jan Beulich wrote:
At most one bit can be set in the masks, so especially on larger systems
it's quite a bit of unnecessary memory and processing overhead to track
the information as a mask. Store the numeric ID of the respective CPU
instead, or VCPU_CPU_CLEAN if no di
On 01/22/2018 07:02 PM, Andrew Cooper wrote:
> On 22/01/18 18:48, George Dunlap wrote:
>> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
>>> On 22/01/18 16:51, Jan Beulich wrote:
>>> On 22.01.18 at 16:00, wrote:
> On 22/01/18 15:48, Jan Beulich wrote:
> On 22.01.18 at 15:38, wrote:
Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 for-next 3/9] gcov: rename
sysctl and functions"):
> On 09.11.17 at 12:13, wrote:
> > Change gcov to cov (for internal interfaces) or coverage (for the
> > public ones).
...
> Btw., I still have this (and subsequent patches in the series) on my
> lis
Hi,
I have configured Xen to boot directly from EFI (with `efibootmgr`).
As explained on the Xen_EFI wiki page, I have added a line "options="
into my file "/boot/efi/EFI/xen/xen.cfg" :
```
# cat /boot/efi/EFI/xen/xen.cfg :
[global]
default=xen
[xen]
options=dom0_mem=1G,max:1G
kernel=vmlinuz
On 23/01/18 08:36, Jan Beulich wrote:
On 22.01.18 at 20:02, wrote:
>> On 22/01/18 18:48, George Dunlap wrote:
>>> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
Jan: As to the things not covered by the current XPTI, hiding most of
the .text section is important to prevent fingerprinti
flight 118282 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118282/
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 Tue, Jan 23, 2018 at 03:09:19AM -0700, Jan Beulich wrote:
> >>> On 23.01.18 at 10:39, wrote:
> >> ... your report is very likely duplicating earlier ones where the
> >> ACPI root point cannot be found without it being properly
> >> propagated through by grub from EFI to Xen. Iirc the only
> >>
Hi Sameer,
On 19/12/17 03:16, Sameer Goel wrote:
Port WARN_ON_ONCE macro from Linux.
Signed-off-by: Sameer Goel
---
xen/include/xen/lib.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index ed00ae1379..83206c0848 100644
--- a/
Hi Sameer,
On 19/12/17 03:16, Sameer Goel wrote:
Changing the name of the macro from LOG_2 to ilog2.This makes the function name
similar to its Linux counterpart. Since, this is not used in mutiple places, so
the code churn is minimal.
s/mutiple/multiple/
This change helps in porting unchan
On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote:
> diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
> index e2019b02a3..a103e49089 100644
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -223,7 +223,7 @@ static inline __u32 ror32(__u32 word, unsigne
Hi Sameer,
On 19/12/17 03:16, Sameer Goel wrote:
Modify the SMMU code to use generic device instead of dt_device_node for
functions that can be used for ACPI based systems too.
Signed-off-by: Sameer Goel
Acked-by: Julien Grall
Cheers,
---
xen/drivers/passthrough/arm/smmu.c | 12 ++-
On Tue, Jan 23, 2018 at 02:14:51AM -0700, Jan Beulich wrote:
> >>> On 22.01.18 at 19:31, wrote:
> > On Mon, Jan 22, 2018 at 06:19:43PM +, Andrew Cooper wrote:
> >> On 22/01/18 18:17, Wei Liu wrote:
> >> > So you want reloc.o to contain pvh_info_reloc unconditionally?
> >> >
> >> > Fundamentall
Hi Roger,
On 23/01/18 11:39, Roger Pau Monné wrote:
On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote:
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index e2019b02a3..a103e49089 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -223,7 +223,7 @@
On 23/01/18 10:10, Juergen Gross wrote:
> On 23/01/18 10:31, Jan Beulich wrote:
> On 23.01.18 at 10:24, wrote:
>>> On 23/01/18 09:53, Jan Beulich wrote:
>>> On 23.01.18 at 07:34, wrote:
> On 22/01/18 19:39, Andrew Cooper wrote:
>> One of my concerns is that this patch series moves
Hi Mirela,
Just some remarks regarding the scope of work:
+In addition, the following have to be implemented:
+* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
+* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), including:
+ * Disable wathdog on suspend, enable it
On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:
> Hi Mirela,
>
> Just some remarks regarding the scope of work:
>
> +In addition, the following have to be implemented:
> +* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
> +* Suspend/resume Xen (triggered by vSYSTEM_
On Tue, Jan 23, 2018 at 11:44:30AM +, Julien Grall wrote:
> Hi Roger,
>
> On 23/01/18 11:39, Roger Pau Monné wrote:
> > On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote:
> > > diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
> > > index e2019b02a3..a103e49089 100644
Hi Roger,
On 23/01/18 12:10, Roger Pau Monné wrote:
On Tue, Jan 23, 2018 at 11:44:30AM +, Julien Grall wrote:
Hi Roger,
On 23/01/18 11:39, Roger Pau Monné wrote:
On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote:
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
The following errors are generated when compiling Xen with clang 6:
In file included from x86_64/asm-offsets.c:9:
In file included from /root/src/xen/xen/include/xen/sched.h:8:
In file included from /root/src/xen/xen/include/xen/shared.h:6:
In file included from /root/src/xen/xen/include/compat/ar
On Thu, Jan 18, 2018 at 07:13:21AM -0700, Jan Beulich wrote:
> >>> On 03.01.18 at 09:26, wrote:
> > The previous aes insns only support legacy and AVX128.
> > Icelake added AVX256 support.
>
> Same remark here as for the pclmulqdq patch.
>
> > Signed-off-by: Yang Zhong
> > ---
>
> Please provi
>>> On 23.01.18 at 12:44, wrote:
> On Tue, Jan 23, 2018 at 02:14:51AM -0700, Jan Beulich wrote:
>> >>> On 22.01.18 at 19:31, wrote:
>> > On Mon, Jan 22, 2018 at 06:19:43PM +, Andrew Cooper wrote:
>> >> On 22/01/18 18:17, Wei Liu wrote:
>> >> > So you want reloc.o to contain pvh_info_reloc unc
flight 118276 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
118250
Tests which
>>> On 23.01.18 at 11:55, wrote:
> On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote:
>> At least Linux kernels have been able to work with gzip-ed initrd for
>> quite some time; initrd compressed with other methods aren't even being
>> attempted to unpack. Furthermore the unzip-ing rout
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hey, Hi!
On Mon, 2018-01-22 at 18:39 +, Andrew Cooper wrote:
> > > > On 22.01.18 at 15:38, wrote:
> > > I'm quite sure the performance will be much better as it doesn't
> > > require
> > > per physical cpu L4 page tables, but just a shadow L4 t
>>> On 23.01.18 at 13:56, wrote:
> I did below TEMP patch, please help me check whther this patch meet your
> requirements, many thanks!
Looks reasonable at the first glance, provided you add a proper
fall-through annotation to the new fall-through.
Jan
___
On 23/01/18 12:45, Andrew Cooper wrote:
> On 23/01/18 10:10, Juergen Gross wrote:
>> On 23/01/18 10:31, Jan Beulich wrote:
>> On 23.01.18 at 10:24, wrote:
On 23/01/18 09:53, Jan Beulich wrote:
On 23.01.18 at 07:34, wrote:
>> On 22/01/18 19:39, Andrew Cooper wrote:
>>> On
>>> On 23.01.18 at 13:38, wrote:
> Fix this by using pragma push/pop in order to store the current pragma
> value in the compiler stack and later restoring it.
For Linux this is fine all the way back to gcc 4.1 afaict, but what
about other OSes using gcc? In 4.1, only config/linux.h and a few
spe
>>> On 23.01.18 at 12:18, wrote:
> As explained on the Xen_EFI wiki page, I have added a line "options="
> into my file "/boot/efi/EFI/xen/xen.cfg" :
>
> ```
> # cat /boot/efi/EFI/xen/xen.cfg :
> [global]
> default=xen
>
> [xen]
> options=dom0_mem=1G,max:1G
> kernel=vmlinuz root=/dev/md2 ro roo
As long as our patching logic isn't safe against concurrently occurring
NMI or #MC we should avoid patching those paths. For sanity's sake also
avoid this on the #DF entry path.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -698,7 +698,7 @@ ENT
On Tue, Jan 23, 2018 at 06:34:44AM -0700, Jan Beulich wrote:
> >>> On 23.01.18 at 13:38, wrote:
> > Fix this by using pragma push/pop in order to store the current pragma
> > value in the compiler stack and later restoring it.
>
> For Linux this is fine all the way back to gcc 4.1 afaict, but wha
>>> On 23.01.18 at 14:54, wrote:
> On Tue, Jan 23, 2018 at 06:34:44AM -0700, Jan Beulich wrote:
>> >>> On 23.01.18 at 13:38, wrote:
>> > Fix this by using pragma push/pop in order to store the current pragma
>> > value in the compiler stack and later restoring it.
>>
>> For Linux this is fine al
On 01/23/2018 05:16 AM, Jan Beulich wrote:
> It being a field of struct domain is sufficient to recognize its
> purpose.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
> Reviewed-by: George Dunlap
> Reviewed-by: Andrew Cooper
> ---
> v2: White space changes (consolidate split line statem
The following errors are generated when compiling Xen with clang 6:
In file included from x86_64/asm-offsets.c:9:
In file included from /root/src/xen/xen/include/xen/sched.h:8:
In file included from /root/src/xen/xen/include/xen/shared.h:6:
In file included from /root/src/xen/xen/include/compat/ar
George Dunlap:
> On 01/23/2018 04:06 AM, Simon Gaiser wrote:
>> George Dunlap:
>>> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
>>> the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people
>>> able to run PVH kernels to switch their PV guests directly to PVH
>>> g
Hello,
The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses
to the PCI configuration space and react accordingly.
Why is this needed? IMHO, there are two main points of doing all this
emulation inside of Xen,
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
---
Changes since v6:
- Remove the rom local variable.
Changes since v5:
- Use the flags field.
- Introduce a mask local variable.
- Simplify return.
Changes since v4:
- New in this version.
---
xen/drivers/passt
When a MSI device with per-vector masking capabilities is detected or
added to Xen all the vectors are masked when initializing it. This
implies that the first time the interrupt is bound to a domain it's
masked.
This however only applies to the first time the interrupt is bound
because neither th
So that MMCFG regions not present in the MCFG ACPI table can be added
at run time by the hardware domain.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v7:
- Add newline in hvm_physdev_op for non-fallthrough case.
Changes sinc
This function allows to iterate over a rangeset while removing the
processed regions.
This will be used in order to split processing of large memory areas
when mapping them into the guest p2m.
Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
---
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Be
Add handlers for accesses to the MSI-X message control field on the
PCI configuration space, and traps for accesses to the memory region
that contains the MSI-X table and PBA. This traps detect attempts from
the guest to configure MSI-X interrupts and properly sets them up.
Note that accesses to t
So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
---
Changes since v7:
- Do not return error from pci_size_mem_bar in order to
This functionality is going to reside in vpci.c (and the corresponding
vpci.h header), and should be arch-agnostic. The handlers introduced
in this patch setup the basic functionality required in order to trap
accesses to the PCI config space, and allow decoding the address and
finding the correspo
Introduce a set of handlers for the accesses to the MMCFG areas. Those
areas are setup based on the contents of the hardware MMCFG tables,
and the list of handled MMCFG areas is stored inside of the hvm_domain
struct.
The read/writes are forwarded to the generic vpci handlers once the
address is d
Add handlers for the MSI control, address, data and mask fields in
order to detect accesses to them and setup the interrupts as requested
by the guest.
Note that the pending register is not trapped, and the guest can
freely read/write to it.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durra
Introduce a set of handlers that trap accesses to the PCI BARs and the
command register, in order to snoop BAR sizing and BAR relocation.
The command handler is used to detect changes to bit 2 (response to
memory space accesses), and maps/unmaps the BARs of the device into
the guest p2m. A rangese
This is needed for MSI-X, since MSI-X will need to be initialized
before parsing the BARs, so that the header BAR handlers are aware of
the MSI-X related holes and make sure they are not mapped in order for
the trap handlers to work properly.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulic
Modify early boot code to relocate pvh info as well, so that we can be
sure __va in __start_xen works.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Roger Pau Monné
v5: Include kconfig.h. Use IS_ENABLED. Adjust code.
---
xen/arch/x86/boot/Makefile | 3 ++-
xen/arch/x86/bo
Hi Sameer,
On 19/12/17 03:17, Sameer Goel wrote:
This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifica
On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote:
> At least Linux kernels have been able to work with gzip-ed initrd for
> quite some time; initrd compressed with other methods aren't even being
> attempted to unpack. Furthermore the unzip-ing routine used here isn't
> capable of dealin
On 23/01/18 15:13, Wei Liu wrote:
> @@ -226,14 +259,27 @@ static multiboot_info_t *mbi2_reloc(u32 mbi_in)
> return mbi_out;
> }
>
> -multiboot_info_t __stdcall *reloc(u32 mb_magic, u32 mbi_in, u32 trampoline)
> +void __stdcall *reloc(u32 magic, u32 in, u32 trampoline)
As an final observati
Make it global in preparation to be called by a new dmop.
Signed-off-by: Ross Lagerwall
Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
---
xen/common/memory.c | 5 ++---
xen/include/xen/mm.h | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/common/memory.c b/xen/com
Provide XEN_DMOP_pin_memory_cacheattr to allow a deprivileged QEMU to
pin the caching type of RAM after moving the VRAM. It is equivalent to
XEN_DOMCTL_pin_memory_cacheattr.
Signed-off-by: Ross Lagerwall
Reviewed-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Changed in v2:
* Check pad is 0.
Signed-off-by: Ross Lagerwall
Acked-by: Ian Jackson
Reviewed-by: Paul Durrant
---
Changed in v4:
* Rename add_to_physmap to relocate_memory to match hypervisor
interface.
Changed in v3:
* Match width of size with updated hypervisor interface.
* Match description with the one for the hypervis
The recently added support for restricting QEMU prevents use of the VGA
console. This series addresses that by adding a couple of new dmops.
A corresponding patch for QEMU is needed to make use of the new dmops.
Changes in v4:
* Rename add_to_physmap -> relocate_memory.
* Use continutation instead
Signed-off-by: Ross Lagerwall
Acked-by: Ian Jackson
Reviewed-by: Paul Durrant
---
tools/libs/devicemodel/core.c | 19 +++
tools/libs/devicemodel/include/xendevicemodel.h | 14 ++
tools/libs/devicemodel/libxendevicemodel.map| 1 +
3 files change
Provide XEN_DMOP_relocate_memory, a limited version of
XENMEM_add_to_physmap to allow a deprivileged QEMU to move VRAM when a
guest programs its BAR. It is equivalent to XENMEM_add_to_physmap with
space == XENMAPSPACE_gmfn_range.
Signed-off-by: Ross Lagerwall
Reviewed-by: Paul Durrant
---
Chang
Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and
have it call the new dmop. Leave the definitions of
XEN_DOMCTL_MEM_CACHEATTR_* since the
Hi Sameer,
On 19/12/17 03:17, Sameer Goel wrote:
Add a new config item to control compilation for legacy arm SMMU.
Signed-off-by: Sameer Goel
---
xen/drivers/passthrough/arm/Kconfig | 6 ++
xen/drivers/passthrough/arm/Makefile | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
d
Hi Sameer,
On 19/12/17 03:17, Sameer Goel wrote:
Pull common defines for SMMU drivers in a local header.
I was expected to see this patch before SMMUv3 is added. But I am ok
with that too.
However, if you want to do some renaming this should be done separately.
So it will be easier to know
On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote:
> Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
> been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
> that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and
> have it call the
flight 118277 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118277/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118270
test-armhf-armhf-libvirt 14 sav
On 01/23/2018 03:44 PM, Wei Liu wrote:
On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote:
Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
that it is only defined when XC_WANT_COMPAT_DEVICEMODE
On Tue, Jan 23, 2018 at 03:47:52PM +, Ross Lagerwall wrote:
> On 01/23/2018 03:44 PM, Wei Liu wrote:
> > On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote:
> > > Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
> > > been replaced by a dmop. Change xc_domain_p
1 - 100 of 133 matches
Mail list logo
