Hi Julien,
On 2017/3/22 20:29, Julien Grall wrote:
> Hi Wei,
>
> On 22/03/17 08:53, Wei Chen wrote:
>> Hi Stefano,
>>
>> On 2017/3/21 5:46, Stefano Stabellini wrote:
>>> On Mon, 13 Mar 2017, Wei Chen wrote:
If there is a pending SError while we are doing context switch, if the
SError han
This patch series is the first part for adding support of large EFI
memory maps (> the current limit of 128 entries) while reducing
trampoline size.
I'm not posting the final patch for making the trampoline size
reduction effective in order not to add major rebase work to Daniel's
multiboot2 serie
Use a larger e820 map buffer for non-BIOS memory map sources. This
requires to have different defines for the maximum number of E820 map
entries for the raw BIOS buffer and the later used struct e820map.
Signed-off-by: Juergen Gross
---
V2: - define E820_BIOS_MAX in assembly code only (Jan Beulic
The hypervisor needs a trampoline in low memory for early boot and
later for bringing up cpus and during wakeup from suspend. Today this
trampoline is kept completely even if most of it isn't needed later.
Split the trampoline into a permanent part and a temporary part needed
at early boot only. I
Instead of using the E820 raw buffer for BIOS, EFI and multiboot based
memory map information use it for the BIOS interface only. This will
enable us to support more E820 entries than the limited trampoline
located buffer can.
Add a new raw e820 table for common purpose and copy the BIOS buffer
to
flight 106828 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106828/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106793
test-amd64-i386-xl-qemuu-w
flight 106825 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106825/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-li
On 3/22/2017 10:21 PM, Jan Beulich wrote:
On 21.03.17 at 03:52, wrote:
---
xen/arch/x86/hvm/dm.c| 37 ++--
xen/arch/x86/hvm/emulate.c | 65 ---
xen/arch/x86/hvm/ioreq.c | 38 +
xen/arch/x86/mm/h
On 3/22/2017 10:39 PM, Jan Beulich wrote:
On 21.03.17 at 03:52, wrote:
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -385,16 +385,51 @@ static int dm_op(domid_t domid,
case XEN_DMOP_map_mem_type_to_ioreq_server:
{
-const struct xen_dm_op_map_mem_type_to_io
On 3/22/2017 10:29 PM, Jan Beulich wrote:
On 21.03.17 at 03:52, wrote:
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -949,6 +949,14 @@ int hvm_map_mem_type_to_ioreq_server(struct domain *d,
ioservid_t id,
spin_unlock_recursive(&d->arch.hvm_domain.ioreq_server.lock
flight 106829 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106829/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106800
test-armhf-armhf-libvirt 13
Hi Stefano,
On 2017/3/23 6:22, Stefano Stabellini wrote:
> On Wed, 22 Mar 2017, Julien Grall wrote:
>> Hi Wei,
>>
>> On 22/03/17 08:49, Wei Chen wrote:
>>> Hi Stefano,
>>>
>>> On 2017/3/21 5:38, Stefano Stabellini wrote:
On Mon, 13 Mar 2017, Wei Chen wrote:
> Currently, we masked the Abor
> Il giorno 23 mar 2017, alle ore 01:55, Stefano Stabellini
> ha scritto:
>
> On Thu, 23 Mar 2017, Luca Miccio wrote:
>>> Il giorno 23 mar 2017, alle ore 01:27, Stefano Stabellini
>>> ha scritto:
>>>
>>> On Thu, 23 Mar 2017, Luca Miccio wrote:
Hi Stefano and Julien,
> Il giorn
On 03/22/2017 05:16 PM, Dan Streetman wrote:
I have a question about a problem introduced by this commit:
c275a57f5ec3056f732843b11659d892235faff7
"xen/balloon: Set balloon's initial state to number of existing RAM pages"
It changed the xen balloon current_pages calculation to start with the
n
Execute the clean target for both arm and x86 architecture.
When trying to build Xen for a different architecture in the same
tree, the command make clean will only remove temporary files for
the host architecture.
This will lead a compilation error when trying to build ARM64 and
ARM32 Xen in the
flight 106851 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106851/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Thu, 23 Mar 2017, Zhongze Liu wrote:
> Back to the GSoC task.
> Do I need to meet any special hardware requirements to complete the task?
No special hardware requirements, what you have below is more than
enough. However, if you have some spare time, it would be helpful for
you to setup an ARM
On Thu, 23 Mar 2017, Luca Miccio wrote:
> > Il giorno 23 mar 2017, alle ore 01:27, Stefano Stabellini
> > ha scritto:
> >
> > On Thu, 23 Mar 2017, Luca Miccio wrote:
> >> Hi Stefano and Julien,
> >>
> >>> Il giorno 22 mar 2017, alle ore 22:38, Stefano Stabellini
> >>> ha scritto:
> >>>
> >>>
> Il giorno 23 mar 2017, alle ore 01:27, Stefano Stabellini
> ha scritto:
>
> On Thu, 23 Mar 2017, Luca Miccio wrote:
>> Hi Stefano and Julien,
>>
>>> Il giorno 22 mar 2017, alle ore 22:38, Stefano Stabellini
>>> ha scritto:
>>>
>>> Hi Luca,
>>>
>>> please don't use HTML emails.
>>>
>>>
On Thu, 23 Mar 2017, Luca Miccio wrote:
> Hi Stefano and Julien,
>
> > Il giorno 22 mar 2017, alle ore 22:38, Stefano Stabellini
> > ha scritto:
> >
> > Hi Luca,
> >
> > please don't use HTML emails.
> >
> >
> Sorry for that.
>
> > On Wed, 22 Mar 2017, Julien Grall wrote:
> >> On 22/03/2017
flight 106826 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106826/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5920a9d16b1ab887c2858224316a98e961d71b05
baseline version:
ovmf 5d5a19028a55a1fb42c9e
Back to the GSoC task.
Do I need to meet any special hardware requirements to complete the task?
Currently I have 12G RAM and 128G SSD + 1T HDD.
The output of "lscpu" on my test machine is as follows:
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:
Hi Stefano and Julien,
> Il giorno 22 mar 2017, alle ore 22:38, Stefano Stabellini
> ha scritto:
>
> Hi Luca,
>
> please don't use HTML emails.
>
>
Sorry for that.
> On Wed, 22 Mar 2017, Julien Grall wrote:
>> On 22/03/2017 19:45, Luca Miccio wrote:
>>> Hi Stefano,
>>
>> Hello Luca,
>>
>>
On Fri, 3 Mar 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 03/03/17 19:34, Stefano Stabellini wrote:
> > On Fri, 3 Mar 2017, Julien Grall wrote:
> > > On 01/03/17 23:24, Julien Grall wrote:
> > > > On 01/03/2017 22:15, Stefano Stabellini wrote:
> > > > > This patch fixes a potential race that co
On Thu, 16 Mar 2017, Andre Przywara wrote:
> For the same reason that allocating a struct irq_desc for each
> possible LPI is not an option, having a struct pending_irq for each LPI
> is also not feasible. However we actually only need those when an
> interrupt is on a vCPU (or is about to be injec
On Thu, 16 Mar 2017, Andre Przywara wrote:
> The number of LPIs on a host can be potentially huge (millions),
> although in practise will be mostly reasonable. So prematurely allocating
> an array of struct irq_desc's for each LPI is not an option.
> However Xen itself does not care about LPIs, as
flight 106824 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106824/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs.
102531
On Wed, 22 Mar 2017, Julien Grall wrote:
> Hi Andre,
>
> On 16/03/17 11:20, Andre Przywara wrote:
> > For some reason (probably because there was no user before) the 64-bit
> > atomic access wrappers were commented out so far.
> > As we will need them in the next patch, active (and fix) them now.
On Thu, 16 Mar 2017, Andre Przywara wrote:
> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
> those IDs, which we directly pass on to the host.
> For this we have to map each device that Dom0 may request to a host
> ITS device with the same identifier.
> Allocate the respectiv
On Wed, 22 Mar 2017, Julien Grall wrote:
> Hi Wei,
>
> On 22/03/17 08:49, Wei Chen wrote:
> > Hi Stefano,
> >
> > On 2017/3/21 5:38, Stefano Stabellini wrote:
> > > On Mon, 13 Mar 2017, Wei Chen wrote:
> > > > Currently, we masked the Abort/SError bit in Xen exception entries.
> > > > So Xen coul
On Wed, 22 Mar 2017, Mark Rutland wrote:
> On Wed, Mar 22, 2017 at 10:54:11AM -0700, Stefano Stabellini wrote:
> > When we receive an SError in Xen, we determine if it should be injected
> > into the guest or "handled" in Xen (by "handle" I mean crash the
> > system). In case it should be injected
Hi Luca,
please don't use HTML emails.
On Wed, 22 Mar 2017, Julien Grall wrote:
> On 22/03/2017 19:45, Luca Miccio wrote:
> > Hi Stefano,
>
> Hello Luca,
>
> > aarch64-linux-gnu-gcc -DCNTFRQ=0x0180-DUART_BASE=0x1c09
> > -DSYSREGS_BASE=0x1c01 -DGIC_DIST_BASE=0x2c001000
> > -DGIC_CP
flight 106819 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106819/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106663
test-armhf-armhf-libvirt
I have a question about a problem introduced by this commit:
c275a57f5ec3056f732843b11659d892235faff7
"xen/balloon: Set balloon's initial state to number of existing RAM pages"
It changed the xen balloon current_pages calculation to start with the
number of physical pages in the system, instead of
On 22/03/2017 19:45, Luca Miccio wrote:
> Hi Stefano,
Hello Luca,
> aarch64-linux-gnu-gcc -DCNTFRQ=0x0180-DUART_BASE=0x1c09
> -DSYSREGS_BASE=0x1c01 -DGIC_DIST_BASE=0x2c001000
> -DGIC_CPU_BASE=0x2c002000 -c -o boot.xen.o boot.S -DXEN
> aarch64-linux-gnu-gcc -DPHYS_OFFSET=0x8000
On 22/03/17 10:33, Jan Beulich wrote:
On 21.03.17 at 14:59, wrote:
This version of this patch removes the need for the 'offset' parameter,
by instead reducing nr_extents, and working backwards from the end of
the array.
This patch also removes the need to ever write back the passed array of
ex
flight 106822 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106822/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 106183
test-amd64-amd64-xl-qemu
Hi Stefano,
2017-03-21 21:36 GMT+01:00 Stefano Stabellini :
> On Tue, 21 Mar 2017, Luca Miccio wrote:
> > Hi,
> > I'm an undergraduate student from the Computer Science Bachelor's Degree
> > of the University of Modena and Reggio Emilia (Italy).
> >
> > I'm very interested in the "Xen on ARM: cre
On 22/03/17 20:03, Stefano Stabellini wrote:
> Implement struct p9_trans_module create and close functions by looking
> at the available Xen 9pfs frontend-backend connections. We don't expect
> many frontend-backend connections, thus walking a list is OK.
>
> Send requests to the backend by copyin
On 22/03/17 20:03, Stefano Stabellini wrote:
> Implement functions to handle the xenbus handshake. Upon connection,
> allocate the rings according to the protocol specification.
>
> Initialize a work_struct and a wait_queue. The work_struct will be used
> to schedule work upon receiving an event c
It uses the new ring.h macros to declare rings and interfaces.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org
---
include/xen/interface/io/9pfs.h | 42 +
1 file changed, 42
Implement functions to handle the xenbus handshake. Upon connection,
allocate the rings according to the protocol specification.
Initialize a work_struct and a wait_queue. The work_struct will be used
to schedule work upon receiving an event channel notification from the
backend. The wait_queue wi
Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org
---
NB: The new macros have not been commi
Implement struct p9_trans_module create and close functions by looking
at the available Xen 9pfs frontend-backend connections. We don't expect
many frontend-backend connections, thus walking a list is OK.
Send requests to the backend by copying each request to one of the
available rings (each fron
Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
register as a xenbus driver and add struct p9_trans_module to register
as v9fs driver.
All functions are empty stubs for now.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
CC: gr...
This patch adds a Kconfig option and Makefile support for building the
9pfs Xen driver.
Signed-off-by: Stefano Stabellini
Reviewed-by: Juergen Gross
CC: gr...@kaod.org
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Eric Van Hensbergen
CC: Ron Minnich
CC: Latchesar Ionkov
CC: v9fs-deve
Upon receiving a notification from the backend, schedule the
p9_xen_response work_struct. p9_xen_response checks if any responses are
available, if so, it reads them one by one, calling p9_client_cb to send
them up to the 9p layer (p9_client_cb completes the request). Handle the
ring following the
Hi all,
This patch series implements a new transport for 9pfs, aimed at Xen
systems.
The transport is based on a traditional Xen frontend and backend drivers
pair. This patch series implements the frontend, which typically runs in
a regular unprivileged guest.
I also sent a series that implement
On Wed, Mar 22, 2017 at 5:54 PM, Jan Beulich wrote:
On 15.03.17 at 21:05, wrote:
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -177,36 +177,8 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
>>
>> register_keyhandler('o', &iommu_dump_p2m_
On Wed, 22 Mar 2017, Paul Durrant wrote:
> This patch adds a command-line option (-xen-domid-restrict) which will
> use the new libxendevicemodel API to restrict devicemodel [1] operations
> to the specified domid. (Such operations are not applicable to the xenpv
> machine type).
>
> This patch al
On Wed, 22 Mar 2017, Greg Kurz wrote:
> On Tue, 21 Mar 2017 13:14:02 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > On Tue, 21 Mar 2017, Greg Kurz wrote:
> > > On Mon, 20 Mar 2017 11:18:46 -0700 (PDT)
> > > Stefano Stabellini wrote:
> > >
> > > > Hi all,
> > > >
> > > > This patch series impl
This stops Coverity complaining.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
---
xen/arch/x86/hvm/viridian.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index b740224..75f165f 100644
--- a/x
On Wed, Mar 22, 2017 at 10:54:11AM -0700, Stefano Stabellini wrote:
> When we receive an SError in Xen, we determine if it should be injected
> into the guest or "handled" in Xen (by "handle" I mean crash the
> system). In case it should be injected into the guest, we set the
> relevant bit in vcpu
On Wed, 22 Mar 2017, Juergen Gross wrote:
> On 21/03/17 19:54, Stefano Stabellini wrote:
> > On Tue, 21 Mar 2017, Juergen Gross wrote:
> >> On 17/03/17 19:33, Stefano Stabellini wrote:
> >>> On Fri, 17 Mar 2017, Juergen Gross wrote:
> On 16/03/17 21:20, Stefano Stabellini wrote:
> > On Thu
Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only external access should be allowed, requiring
the user to compile Xen with XSM enabled to be able to appropri
Hi Stefano,
On 22/03/17 17:54, Stefano Stabellini wrote:
On Wed, 22 Mar 2017, Marc Zyngier wrote:
On 22/03/17 12:45, Mark Rutland wrote:
On Wed, Mar 22, 2017 at 12:16:20PM +, Julien Grall wrote:
(CC Mark for the TLB question)
[Adding Marc since he should understand this better than I do
Hi Jan
On Wed, Mar 22, 2017 at 5:44 PM, Jan Beulich wrote:
On 15.03.17 at 21:05, wrote:
>> From: Oleksandr Tyshchenko
>>
>> Extend the IOMMU code with new APIs and platform callbacks.
>> These new map_pages/unmap_pages API do almost the same thing
>> as existing map_page/unmap_page ones ex
On 2017-03-22 02:05 AM, Stanislaw Gruszka wrote:
On Tue, Mar 21, 2017 at 03:43:38PM -0700, Ankur Arora wrote:
This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4.
do_suspend (from xen/manage.c) and thus xen_resume_notifier never get
called on the initial-domain at resume (it is if
On Wed, 22 Mar 2017, Marc Zyngier wrote:
> On 22/03/17 12:45, Mark Rutland wrote:
> > On Wed, Mar 22, 2017 at 12:16:20PM +, Julien Grall wrote:
> >> (CC Mark for the TLB question)
> >
> > [Adding Marc since he should understand this better than I do]
> >
> > I've trimmed a lot of context here
Paul Durrant writes ("RE: [PATCH RESEND] tools/libxl: add support for emulated
NVMe drives"):
> > I guess that was with xapi rather than libxl ?
>
> Nope. It was libxl.
That's weird. You specify it as xvda in the config file ?
> Windows PV drivers treat hd*, sd* and xvd* numbering in the same
flight 106823 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106823/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestore.2 fail REGR. vs. 105976
Regre
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 22 March 2017 17:32
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Wei Liu
> Subject: RE: [PATCH RESEND] tools/libxl: add support for emulated NVMe
> drives
>
> Paul Durrant writes ("RE: [PATCH
Paul Durrant writes ("RE: [PATCH RESEND] tools/libxl: add support for emulated
NVMe drives"):
> This is my VM:
>
> root@brixham:~# xenstore-ls "/libxl/3"
> device = ""
> vbd = ""
> 51712 = ""
...
>params = "qcow2:/root/winrs2-pv1.qcow2"
> No problem using xvda... still ends up as IDE prim
Hi Andre,
On 16/03/17 11:20, Andre Przywara wrote:
For some reason (probably because there was no user before) the 64-bit
atomic access wrappers were commented out so far.
As we will need them in the next patch, active (and fix) them now.
Signed-off-by: Andre Przywara
Reviewed-by: Julien Gra
Hi Andre,
On 16/03/17 11:20, Andre Przywara wrote:
The ITS uses device IDs to map LPIs to a device. Dom0 will later use
those IDs, which we directly pass on to the host.
For this we have to map each device that Dom0 may request to a host
ITS device with the same identifier.
Allocate the respecti
On 03/21/2017 07:02 PM, Jan Beulich wrote:
On 21.03.17 at 17:44, wrote:
>> On 03/21/2017 06:29 PM, Jan Beulich wrote:
>> On 21.03.17 at 16:38, wrote:
On 03/15/2017 06:57 PM, Jan Beulich wrote:
On 15.03.17 at 17:46, wrote:
>> On 03/15/2017 06:30 PM, Jan Beulich wrote:
>
On Wed, Mar 22, 2017 at 9:40 AM, Tamas K Lengyel
wrote:
> On Wed, Mar 22, 2017 at 2:06 AM, Jan Beulich wrote:
> On 21.03.17 at 18:25, wrote:
>>> On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich wrote:
Hmm, the original (abstract) VMFUNC use case, as I have
understood it, allows a gue
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 22 March 2017 17:03
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Wei Liu
> Subject: RE: [PATCH RESEND] tools/libxl: add support for emulated NVMe
> drives
>
> Paul Durrant writes ("RE: [PATCH
Paul Durrant writes ("RE: [PATCH RESEND] tools/libxl: add support for emulated
NVMe drives"):
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > That's not my point. The purpose of this table is to advise guests
> > what the conventional in-guest device name ought to be for a certain
>
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 22 March 2017 16:32
> To: Ian Jackson
> Cc: xen-de...@lists.xenproject.org; Wei Liu
> Subject: Re: [Xen-devel] [PATCH RESEND] tools/libxl: add support for
> emulated NVMe dr
Hi Andre,
On 22/03/17 16:31, André Przywara wrote:
On 22/03/17 15:23, Julien Grall wrote:
On 16/03/17 11:20, Andre Przywara wrote:
+
LIST_HEAD(host_its_list);
bool gicv3_its_host_has_its(void)
@@ -56,6 +59,55 @@ static uint64_t encode_propbaser_phys_addr(paddr_t
addr, unsigned int page_bits
On 22/03/17 16:08, André Przywara wrote:
Hi,
Hi Andre,
On 22/03/17 13:52, Julien Grall wrote:
Hi Andre,
On 03/16/2017 11:20 AM, Andre Przywara wrote:
Each ITS maps a pair of a DeviceID (for instance derived from a PCI
b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 22 March 2017 16:03
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Wei Liu
> Subject: RE: [PATCH RESEND] tools/libxl: add support for emulated NVMe
> drives
>
> Paul Durrant writes ("RE: [PATCH
On 22/03/17 15:23, Julien Grall wrote:
> Hi Andre,
>
> On 16/03/17 11:20, Andre Przywara wrote:
>> Instead of directly manipulating the tables in memory, an ITS driver
>> sends commands via a ring buffer in normal system memory to the ITS h/w
>> to create or alter the LPI mappings.
>> Allocate mem
Hi,
On 22/03/17 13:52, Julien Grall wrote:
> Hi Andre,
>
> On 03/16/2017 11:20 AM, Andre Przywara wrote:
>> Each ITS maps a pair of a DeviceID (for instance derived from a PCI
>> b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
>> pair of LPI number and collection ID, which po
Paul Durrant writes ("RE: [PATCH RESEND] tools/libxl: add support for emulated
NVMe drives"):
> > Oh, wait, I have just noticed that you have reused an entry in this
> > table!
> >
> >1 << 28 | disk << 8 | partition xvd, disks or partitions 16 onwards
> > ...
> > > +1 << 28 | disk <
Hi Andre,
On 16/03/17 11:20, Andre Przywara wrote:
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush t
>>> On 15.03.17 at 21:05, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -66,6 +66,9 @@ struct xen_domctl_createdomain {
> /* Is this a xenstore domain? */
> #define _XEN_DOMCTL_CDF_xs_domain 5
> #define XEN_DOMCTL_CDF_xs_domain (1U<<_XEN_DOMCTL_CD
>>> On 15.03.17 at 21:05, wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -177,36 +177,8 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
>
> register_keyhandler('o', &iommu_dump_p2m_table, "dump iommu p2m table",
> 0);
> d->need_iomm
On Wed 2017-03-22 13:06:54, Jiri Slaby wrote:
> Hi,
>
> On 03/21/2017, 03:08 PM, Pavel Machek wrote:
> >> -ENTRY(saved_rbp) .quad 0
> >> -ENTRY(saved_rsi) .quad 0
> >> -ENTRY(saved_rdi) .quad 0
> >> -ENTRY(saved_rbx) .quad 0
> >> +SYM_DATA_START(saved_rbp) .quad 0
> >> +SYM_D
>>> On 15.03.17 at 21:05, wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -181,6 +181,7 @@ struct iommu_ops {
> int __must_check (*unmap_page)(struct domain *d, unsigned long gfn);
> int __must_check (*unmap_pages)(struct domain *d, unsigned long gfn,
>
flight 106820 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106820/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl 11 guest-start fail REGR. vs. 106738
test-amd64-amd6
>>> On 15.03.17 at 21:05, wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -129,7 +129,7 @@ static void __init parse_iommu_param(char *s)
> } while ( ss );
> }
>
> -int iommu_domain_init(struct domain *d)
> +int iommu_domain_init(struct domain *d,
On 03/22/2017, 03:26 PM, Josh Poimboeuf wrote:
> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
>> Somewhere END was used to end a function, elsewhere, nothing was used.
>> So unify it and mark them all by SYM_FUNC_END.
>>
>> Signed-off-by: Jiri Slaby
>
> For me these patches would b
>>> On 15.03.17 at 21:05, wrote:
> From: Oleksandr Tyshchenko
>
> Extend the IOMMU code with new APIs and platform callbacks.
> These new map_pages/unmap_pages API do almost the same thing
> as existing map_page/unmap_page ones except the formers can
> handle the number of pages. So do new platf
On Wed, Mar 22, 2017 at 2:06 AM, Jan Beulich wrote:
On 21.03.17 at 18:25, wrote:
>> On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich wrote:
>>> Hmm, the original (abstract) VMFUNC use case, as I have
>>> understood it, allows a guest to actively select between EPT
>>> variants without having (
>>> On 22.03.17 at 16:28, wrote:
> The Hypervisor Top Level Functional Specification v5.0a states in section
> 2.5:
>
> "The hypervisor version information is encoded in leaf 0x4002. Two
> version numbers are provided: the main version and the service version.
> The main version includes a ma
On Wed, Mar 22, 2017 at 04:01:08PM +0100, Jiri Slaby wrote:
> On 03/22/2017, 03:11 PM, Josh Poimboeuf wrote:
> > Or, here's a much easier way to do it, without involving objtool:
> >
> > --- a/include/linux/linkage.h
> > +++ b/include/linux/linkage.h
> > @@ -138,9 +138,17 @@
> > name:
> > #en
The current threshold before the guest issues the hypercall is, and always
has been, hard-coded to 2047. It is not clear where this number came
from so, to at least allow for ease of experimentation, this patch makes
the threshold tunable via the Xen command line.
Signed-off-by: Paul Durrant
Revi
Section 2.4.4 of the Hypervisor Top Level Functional Specification states
that enabling bit 10 in EDX of CPUID leaf 3 advertises to Windows a set
of MSRs into which it can write crash information.
This patch advertises that bit and implements the MSRs such that Xen can
log the information if a Win
Paul Durrant (3):
x86/viridian: don't put Xen version information in CPUID leaf 2
x86/viridian: make the threshold for HvNotifyLongSpinWait tunable
x86/viridian: implement the crash MSRs
docs/man/xl.cfg.pod.5.in| 10 ++-
docs/misc/xen-command-line.markdown | 16
tools/lib
The Hypervisor Top Level Functional Specification v5.0a states in section
2.5:
"The hypervisor version information is encoded in leaf 0x4002. Two
version numbers are provided: the main version and the service version.
The main version includes a major and minor version number and a build
numbe
On 22/03/17 16:23, Jan Beulich wrote:
On 22.03.17 at 16:01, wrote:
>> On 22/03/17 14:12, Jan Beulich wrote:
>> On 21.03.17 at 14:10, wrote:
@@ -194,10 +194,10 @@ static void __init
efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
type = E820_NVS;
>>
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 22 March 2017 15:02
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Wei Liu
> Subject: RE: [PATCH RESEND] tools/libxl: add support for emulated NVMe
> drives
>
> Paul Durrant writes ("RE: [PATCH
Hi Andre,
On 16/03/17 11:20, Andre Przywara wrote:
Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer in normal system memory to the ITS h/w
to create or alter the LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be abl
>>> On 22.03.17 at 16:01, wrote:
> On 22/03/17 14:12, Jan Beulich wrote:
> On 21.03.17 at 14:10, wrote:
>>> @@ -194,10 +194,10 @@ static void __init
>>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>> type = E820_NVS;
>>> break;
>>> }
>>> -
On 22/03/17 16:17, Alex Thorlton wrote:
> On Tue, Mar 21, 2017 at 02:10:20PM +0100, Juergen Gross wrote:
>> This patch series is the first part for adding support of large EFI
>> memory maps (> the current limit of 128 entries) while reducing
>> trampoline size.
>>
>> I'm not posting the final patc
On Tue, Mar 21, 2017 at 02:10:20PM +0100, Juergen Gross wrote:
> This patch series is the first part for adding support of large EFI
> memory maps (> the current limit of 128 entries) while reducing
> trampoline size.
>
> I'm not posting the final patch for making the trampoline size
> reduction e
Paul Durrant writes ("RE: [PATCH RESEND] tools/libxl: add support for emulated
NVMe drives"):
> [Ian:]
> > If and when qemu supports multiple namespaces, how will this be
> > specified ?
>
> I'd guess a vdev of the form nvmeXnY would follow convention.
Right. Sorry, I was unclear. I meant here
On 22/03/17 14:19, Jan Beulich wrote:
On 21.03.17 at 14:10, wrote:
>> Use a larger e820 map buffer for non-BIOS memory map sources. This
>> requires to have different defines for the maximum number of E820 map
>> entries for the raw BIOS buffer and the later used struct e820map.
>>
>> While a
1 - 100 of 204 matches
Mail list logo
