On 20/03/18 18:22, Andrew Cooper wrote:
> On 20/03/18 16:58, Jan Beulich wrote:
> On 19.03.18 at 20:13, wrote:
>>> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
>>> "x86/AMD: Add support for AMD's OSVW feature in guests".
>>>
>>> At the time, svm_handle_osvw() cou
Hello Julien,
As requested I am moving the conversation to email from IRC
To summarize my setup:
1. I am running a custom kernel on QEMU ARM64(without KVM) on my linux
machine
2. I have my custom implementation of Hypervisor
3. I am trying to run the same custom kernel as guest OS on top of my
H
flight 121014 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949
Tests which
On 03/20/2018 01:13 PM, Julien Grall wrote:
Hi,
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
Some Cavium Thunder CPUs suffer a problem where a Xen guest may
inadvertently cause the host kernel to quit receiving interrupts.
This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will
pr
Hi,
On 03/19/2018 07:13 PM, Andrew Cooper wrote:
This is a tools only hypercall so fine to change. Altering the name avoids
having confusing code such as config->config all over the hypervisor and
toolstack.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
---
CC: Jan Beulich
On 03/21/2018 04:58 AM, Manish Jaggi wrote:
Hi Julien,
On 03/20/2018 01:16 PM, Julien Grall wrote:
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]
The current RFC patchset is a subset of [1
Hi Julien,
On 03/20/2018 01:16 PM, Julien Grall wrote:
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]
The current RFC patchset is a subset of [1], as it handleing only
Group1 traps
as a PoC.
Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn because the
rest of the function use mfn_t.
So make page_to_mfn and mfn_to_page return mfn_t by default. The __*
version are now dropped as this patch will convert all t
The current prototype is slightly confusing because it takes a guest
physical address and a machine physical frame (not address!). Switching to
MFN will improve safety and reduce the chance to mistakenly invert the
2 parameters.
Signed-off-by: Julien grall
Reviewed-by: Wei Liu
Reviewed-by: Jan B
A new helper __copy_mfn_to_guest is introduced to easily to copy a MFN to
the guest memory.
Not functional change intended
Signed-off-by: Julien Grall
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
C
At the same time replace MFN 0 by INVALID_MFN or drop the initializer
when it is not necessary. This will make clearer that the MFN
initialized is not valid.
Other than MFN 0 -> INVALID_MFN, no functional change intended.
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
A few files override page_to_mfn/mfn_to_page but actually never use
those macros. So drop them.
Signed-off-by: Julien Grall
Acked-by: George Dunlap
Acked-by: Jan Beulich
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v5:
- Add George and Jan's acked-by
No functional change intended.
Signed-off-by: Julien Grall
Reviewed-by: Wei Liu
Reviewed-by: George Dunlap
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Cc: Julien Grall
Wei, I have
From: Wei Liu
In a follow-up patches, some callers will be switched to pass
INVALID_MFN instead of zero for non-present mappings. So skip
incrementing mfn if it is not a valid one.
Signed-off-by: Wei Liu
Signed-off-by: Julien Grall
[Rework the commit message]
--
Cc: Jan Beulich
Cc: Andrew C
Hi all,
This is v6 of the series. For all the changes see in each patch.
To avoid the last patch (#16) to be a huge patch some files are converted to
use typesafe upfront. I have tried my best to push _mfn/mfn_x as down as
possible in the callers. Some of them was not feasible without major rewor
The current prototype is slightly confusing because it takes a virtual
address and a physical frame (not address!). Switching to MFN will improve
safety and reduce the chance to mistakenly invert the 2 parameters.
Also, take the opportunity to switch (a - b) >> PAGE_SHIFT to
PFN_DOWN(a - b) in the
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Changes in v6:
- Remove the justification from the commit message
- Add George's reviewed-by
Changes in v4:
- Patch added
---
xen/arch/arm/mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
No functional change intended.
While we are here, use PFN_DOWN() rather than open coding it.
Signed-off Julien Grall
Acked-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v6:
- Add George's reviewed-by
- Add a word about using PFN_DOWN in the commit mess
relinquish_shared_pages is never called on Arm.
Signed-off-by: Julien Grall
Reviewed-by: George Dunlap
---
Cc: Stefano Stabellini
Changes in v6:
- Add George's reviewed-by
Changes in v4:
- Patch added
---
xen/include/asm-arm/mm.h | 4
1 file changed, 4 deletion
Arm does not have an M2P and very unlikely to get one in the future,
therefore don't keep defines that are not necessary in the common code.
At the same time move the remaining M2P define just above
set_gpfn_from_mfn to keep all the dummy helpers for M2P together.
Signed-off-by: Julien Grall
--
Signed-off-by: Julien Grall
Reviewed-by: George Dunlap
---
Cc: Stefano Stabellini
Changes in v6:
- Remove the justification from the commit message
- Add George's reviewed-by
Changes in v4:
- Patch added
---
xen/arch/arm/setup.c | 4 ++--
1 file changed, 2 ins
Other than MFN 0 -> INVALID_MFN, no functional change intended.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v6:
- s/_mfn(0)/MFN 0/
- Fix typo in the commit message
Changes in v5:
- Use INVALID_MFN instead
The function populate_pt_range is used to populate in advance the
page-table but it will not do the actual mapping. So passing the MFN in
parameter is pointless. Note that the only caller pass 0...
At the same time replace 0 by INVALID_MFNs. While this does not matter
as the entry will marked as n
This will avoid use of pfn_to_pdx(mfn_x(mfn)) over the code base.
Signed-off-by: Julien Grall
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Hi,
On 03/20/2018 03:15 PM, Roger Pau Monne wrote:
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, a
On 03/20/2018 05:11 PM, Andre Przywara wrote:
Hi,
On 20/03/18 01:17, Julien Grall wrote:
Hi Andre,
On 03/15/2018 08:30 PM, Andre Przywara wrote:
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 002fec57e6..4b9664f313 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch
Hi Andrew,
On 03/20/2018 07:55 PM, Andrew Cooper wrote:
On 20/03/18 19:48, osstest service owner wrote:
flight 121001 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121001/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which cou
Hi Jan,
On 03/20/2018 10:35 AM, Jan Beulich wrote:
On 15.03.18 at 21:30, wrote:
If we change something in a vCPU that affects its runnability or
otherwise needs the vCPU's attention, we might need to tell the scheduler
about it.
We are using this in one place (vIRQ injection) at the moment, bu
Commit 5cb00d1 "ARM: GIC: extend LR read/write functions to cover EOI
and source" extended gic_lr to cover the source. The new field was only
set for SGIs interrupt in the read function. However, the write function
is writing the field unconditionally for virtual interrupt.
This means that if the
flight 120957 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120957/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
12
Tests whi
Really early work on switching over to using GitLab CI over
Travis CI. GitLab is a competitor to GitHub with some advantages
such as an integrated CI system with a lot more flexibility
and control. It additionally is fully open sourced unlike GitHub
and Travis CI. We can even run an instance if tha
Created a new section just called 'CI' since this is adding GitLab CI
and still leaving the old Travis CI files around. This consolidates the
two sections and adds the new files as well as adding another Travis
file that was missing.
Signed-off-by: Doug Goldstein
Reviewed-by: Konrad Rzeszutek Wil
Add a basic README explaining the containers and how people can use them
to locally test with if they see an error in CI and want to reproduce it
locally. Added a makefile to help with building and pushing the
containers to the container registry.
Signed-off-by: Doug Goldstein
Reviewed-by: Konrad
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Ubuntu 16.04 system.
Signed-off-by: Doug Goldstein
Reviewed-by: Konrad Rzeszutek Wilk
---
automation/build/ubuntu/xenial.dockerfile | 47 -
1 file changed, 47 insertions(+)
create mode 10
Added a GitLab CI config which has a lot more flexibility to allow us to
test a lot more distro configurations than Travis can and even build
test on FreeBSD. This includes a modified copy of scripts/travis-build
that is expected to diverge future over time as we build more than what
Travis is curr
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Debian stretch system.
Signed-off-by: Doug Goldstein
Reviewed-by: Konrad Rzeszutek Wilk
---
automation/build/debian/stretch.dockerfile | 47 +++-
1 file changed, 47 insertions(+)
create mode
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a CentOS 7.2 system.
Signed-off-by: Doug Goldstein
Reviewed-by: Konrad Rzeszutek Wilk
---
change since v2:
- added missing checkpolicy
---
automation/build/centos/7.2.dockerfile | 42 ++-
a
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Ubuntu 14.04 system.
Signed-off-by: Doug Goldstein
Reviewed-by: Konrad Rzeszutek Wilk
---
automation/build/ubuntu/trusty.dockerfile | 47 -
1 file changed, 47 insertions(+)
create mode 10
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Debian jessie system.
Signed-off-by: Doug Goldstein
Reviewed-by: Konrad Rzeszutek Wilk
---
automation/build/debian/jessie.dockerfile | 47 -
1 file changed, 47 insertions(+)
create mode 1
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. It's not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20 vcpus), we observed an 200s+ delay
in construct_dom0.
By initializing u
flight 121009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949
Tests which
On Tue, 20 Mar 2018 08:50:48 +
Roger Pau Monné wrote:
>On Tue, Mar 20, 2018 at 05:49:22AM +1000, Alexey G wrote:
>> On Mon, 19 Mar 2018 15:58:02 +
>> Roger Pau Monné wrote:
>>
>> >On Tue, Mar 13, 2018 at 04:33:52AM +1000, Alexey Gerasimenko
>> >wrote:
>> >> Much like normal PCI BARs
flight 120952 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120952/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
test-amd64-i386-lib
flight 121004 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949
Tests which
On Tue, 20 Mar 2018 09:20:01 +
Roger Pau Monné wrote:
>On Tue, Mar 20, 2018 at 09:44:33AM +1000, Alexey G wrote:
>> On Mon, 19 Mar 2018 15:30:14 +
>> Roger Pau Monné wrote:
>>
>> >On Tue, Mar 13, 2018 at 04:33:51AM +1000, Alexey Gerasimenko
>> >wrote:
>> >> +{
>> >> +case 0x
On Tue, 20 Mar 2018 09:03:56 +
Roger Pau Monné wrote:
>On Tue, Mar 20, 2018 at 07:46:04AM +1000, Alexey G wrote:
>> On Mon, 19 Mar 2018 17:33:34 +
>> Roger Pau Monné wrote:
>>
>> >On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko
>> >wrote:
>> >> This adds construct_mcfg(
On 3/20/2018 12:23 PM, Randy Dunlap wrote:
Hi,
On 03/20/2018 12:18 PM, Maran Wilson wrote:
In order to pave the way for hypervisors other then Xen to use the PVH
than
entry point for VMs, we need to factor the PVH entry code into Xen specific
On Tue, 20 Mar 2018 03:36:57 -0600
"Jan Beulich" wrote:
On 19.03.18 at 22:20, wrote:
>> On Mon, 19 Mar 2018 17:49:09 +
>> Roger Pau Monné wrote:
>>>On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote:
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firm
On Mon, 19 Mar 2018 08:22:19 +0100,
Oleksandr Andrushchenko wrote:
>
> From: Oleksandr Andrushchenko
>
> Hello, all!
>
> In order to provide explicit synchronization between backend and
> frontend the following changes are introduced in the protocol:
> - bump protocol version to 2
> - add new
On 20/03/18 19:48, osstest service owner wrote:
> flight 121001 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/121001/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-arm64-arm64-xl-xsm
flight 121001 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121001/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949
Tests which
> On 19. Mar 2018, at 19:13, Andrew Cooper wrote:
>
> The underlying C function is about to make the same change, and the structure
> is going to gain extra fields.
>
> Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
___
Xen-devel mailin
> On 19. Mar 2018, at 19:13, Andrew Cooper wrote:
>
> This is a logarithm in disguise. Update the logic to match how
> x86_arch_emulation_flags works in c/s 9d683b5e37 and b38d96f596.
Acked-by: Christian Lindig
___
Xen-devel mailing list
Xen-deve
> On 19. Mar 2018, at 19:13, Andrew Cooper wrote:
>
> set_max_evtchn is somewhat weird. It was introduced with the event_fifo work,
> but has never been used. Still, it is a bounding on resources consumed by the
> event channel infrastructure, and should be part of createdomain, rather than
>
> On 19. Mar 2018, at 19:13, Andrew Cooper wrote:
>
> In future patches, the structure will be extended with further information,
> and this is far cleaner than adding extra parameters.
>
> The python stubs are the only user which passes NULL for the existing config
> option (which is actually
> On 19. Mar 2018, at 19:13, Andrew Cooper wrote:
>
> XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a
> toolstack from unpausing a domain with no vcpus.
>
> Originally, d->vcpus[] was an embedded array in struct domain, but c/s
> fb442e217 "x86_64: allow more vCP
> On 20. Mar 2018, at 10:11, Andrew Cooper wrote:
>
> That said, while ssidref might plausibly need a full 32 bits of range
> (and even then, I'm not entirely sure, but it is an opaque handle at the
> end of the day), none of the max_* fields do. vcpus is currently capped
> at 128, grant frame
On Tue, Mar 20, 2018 at 11:20 AM, Jan Beulich wrote:
On 20.03.18 at 13:58, wrote:
>> With that in place, I'm seeing Dom0 receive a general protection fault on
>> boot
>>
>> [ 25.460035] general protection fault: [#1] SMP
>> [ 25.460292] EIP: switch_mm_irqs_off+0xbe/0x600
>>
>> switc
On 03/19/2018 03:13 PM, Andrew Cooper wrote:
set_max_evtchn is somewhat weird. It was introduced with the event_fifo work,
but has never been used. Still, it is a bounding on resources consumed by the
event channel infrastructure, and should be part of createdomain, rather than
editable after t
On 03/19/2018 03:13 PM, Andrew Cooper wrote:
XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a
toolstack from unpausing a domain with no vcpus.
Originally, d->vcpus[] was an embedded array in struct domain, but c/s
fb442e217 "x86_64: allow more vCPU-s per guest" in X
On 03/19/2018 03:13 PM, Andrew Cooper wrote:
XEN_DOMCTL_set_gnttab_limits is a fairly new hypercall, and is strictly
mandatory. Adding support for it introduced a state where a domain has a
mostly un-constructed grant table, and there were cases where mis-ordering of
toolstack hypercalls could c
Hi,
On 03/20/2018 12:18 PM, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH
than
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The f
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.
Signed-off-by: Ma
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other hy
Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests. Mo
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.
Signed-off-by: Maran Wilson
---
arch/x86/platform/pvh/enlighten.c | 5 +
In order to pave the way for hypervisors other then Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
On Tue, Mar 20, 2018 at 11:07 AM, Alexandru Stefan ISAILA
wrote:
> On Ma, 2018-03-20 at 10:49 -0600, Tamas K Lengyel wrote:
>> On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila
>> wrote:
>> >
>> > At this moment the Debug events for the AMD architecture are not
>> > forwarded to the monitor layer
There has always been an intention in the ioreq server API that only the
domain that creates an ioreq server should be able to manipulate it.
However, so far, nothing has enforced this. This means that two domains
with DM_PRIV over a target domain can currently manipulate each others
ioreq servers.
Only in the legacy 'default server' case do we pass anything other than
current->domain->domain_id, and in that case we pass the value of
HVM_PARAM_DM_DOMAIN.
The only known user of HVM_PARAM_DM_DOMAIN is qemu-trad, which always sets
it to DOMID_SELF (ignoring the return value of xc_set_hvm_param)
When an ioreq server is created the code currently stores the id
of the emulating domain, but does not take a reference on that domain.
This patch modifies the code to hold a reference for the lifetime of the
ioreq server.
NOTE: ioreq servers are either destroyed explicitly or destroyed implicitl
This series tightens up permissions checking on ioreq server control plane
operations.
Paul Durrant (4):
x86/hvm: stop passing explicit domid to hvm_create_ioreq_server()
x86/hvm: take a reference on ioreq server emulating domain
x86/hvm: re-structure some of the ioreq server look-up loops
This patch is a cosmetic re-structuring of some of the loops with look up
an ioreq server based on target domain and server id.
The restructuring is done separately here to ease review of a subsquent
patch.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
v3:
- Tidy
On Tue, Mar 20, 2018 at 05:34:01PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> > > Using <> for system include files and "" for local include files is a
> > > convention, an
On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
>
> Very large projects often split in sub projects, maybe one of them
> describing the API. Then that API headers are similar to system headers
> and can be included using <>, although they still belong to the same
> larger project. Do
On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> > Using <> for system include files and "" for local include files is a
> > convention, and as far as I know most projects adhere to that
> > convention. So does QEMU
On 03/15/2018 01:04 PM, Jan Beulich wrote:
> Use hooks, just like done for other special purpose registers.
>
> This includes moving XCR0 checks from hvmemul_get_fpu() to the emulator
> itself as well as adding support for XGETBV emulation.
>
> For now fuzzer reads will obtain the real values (mi
On 20/03/18 16:58, Jan Beulich wrote:
On 19.03.18 at 20:13, wrote:
>> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
>> "x86/AMD: Add support for AMD's OSVW feature in guests".
>>
>> At the time, svm_handle_osvw() could have seen an unexpected change in OSVW
>> (n
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 20 March 2018 16:37
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 2/4] x86/hvm: take a reference on ioreq server
> emulating domain
>
> >>> On 16.03.18 at 17:5
On 20/03/18 16:49, Tamas K Lengyel wrote:
> On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila
> wrote:
>> At this moment the Debug events for the AMD architecture are not
>> forwarded to the monitor layer.
>>
>> This patch adds the Debug event to the common capabilities, adds
>> the VMEXIT_ICEBP t
On Tue, Mar 20, 2018 at 02:54:37PM +0100, Max Reitz wrote:
> But I guess the main advantage with using this rule I see is that it's
> better for people reading the code. It's just nice to know whether a
> file belongs to qemu or not by just looking at the #include statement.
> (Note that this impl
Hi,
On 20/03/18 01:17, Julien Grall wrote:
> Hi Andre,
>
> On 03/15/2018 08:30 PM, Andre Przywara wrote:
>> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
>> index 002fec57e6..4b9664f313 100644
>> --- a/xen/arch/arm/vgic/vgic.c
>> +++ b/xen/arch/arm/vgic/vgic.c
>> @@ -946,6 +946
On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> Using <> for system include files and "" for local include files is a
> convention, and as far as I know most projects adhere to that
> convention. So does QEMU currently. Such conventions are not only
> important for humans, but also f
On Ma, 2018-03-20 at 10:49 -0600, Tamas K Lengyel wrote:
> On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila
> wrote:
> >
> > At this moment the Debug events for the AMD architecture are not
> > forwarded to the monitor layer.
> >
> > This patch adds the Debug event to the common capabilities, add
>>> On 20.03.18 at 17:48, wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to shar
>>> On 19.03.18 at 20:13, wrote:
> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
> "x86/AMD: Add support for AMD's OSVW feature in guests".
>
> At the time, svm_handle_osvw() could have seen an unexpected change in OSVW
> (not the case now, due to the new CPUID Polic
From: Boris Ostrovsky
We will later copy it to hvm_start_info.
(Also remove stale comment claming that xc_dom_image.start_info_seg is
only used for HVMlite guests)
Signed-off-by: Boris Ostrovsky
---
tools/libxc/include/xc_dom.h | 7 ++-
tools/libxl/libxl_x86.c | 4
2 files chang
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.
Signed-off-by: Ma
From: Boris Ostrovsky
Signed-off-by: Boris Ostrovsky
Signed-off-by: Maran Wilson
---
tools/libxc/xc_dom_x86.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0b65dab..b2d8403 100644
---
Here is the patch series for updating the canonical definition of the
hvm_start_info struct corresponding to the discussion happening on the
linux-kernel and kvm mailing lists regarding Qemu/KVM use of the PVH
entry point:
KVM: x86: Allow Qemu/KVM to use PVH entry point
https://lkml.org/lkml
>>> On 19.03.18 at 20:13, wrote:
> This is a tools only hypercall so fine to change. Altering the name avoids
> having confusing code such as config->config all over the hypervisor and
> toolstack.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
_
flight 120993 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120993/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949
Tests which
From: Boris Ostrovsky
Since hvm_start_info has now been expanded to include memory map (i.e.
e820) we need to know size of this map by the time we create
dom->start_info_seg in alloc_magic_pages_hvm().
To do so we have to call libxl__arch_domain_construct_memmap() earlier,
before xc_dom_build_im
On Tue, Mar 20, 2018 at 11:12:00AM -0500, Eric Blake wrote:
>
> Why can't we fix Makefile to include BOTH the build and the source
> directories (to pick up generated files first, and then version-controlled
> files), and possibly include logic to simplify to a single -I instead of two
> when doin
On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila
wrote:
> At this moment the Debug events for the AMD architecture are not
> forwarded to the monitor layer.
>
> This patch adds the Debug event to the common capabilities, adds
> the VMEXIT_ICEBP then forwards the event to the monitor layer.
>
> Ch
>>> On 20.03.18 at 17:14, wrote:
> On 20/03/18 16:05, Jan Beulich wrote:
> On 20.03.18 at 16:53, wrote:
>>> Please could you delete this function and use:
>>>
>>> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
>>> index 2376ed6..843dafe 100644
>>> --- a/xen/include
>>> On 16.03.18 at 17:58, wrote:
> There has always been an intention in the ioreq server API that only the
> domain that creates an ioreq server should be able to manipulate it.
> However, so far, nothing has enforced this. This means that two domains
> with DM_PRIV over a target domain can curre
1 - 100 of 220 matches
Mail list logo
