-- Forwarded message --
From: "Xuehan Xu"
Date: Apr 29, 2015 10:11 AM
Subject: How to get real time in a xen vm?
To:
Cc:
Hi, everyone
Recently, I got a need to measure the latency of the I/O operation of
TAPDISK on dom0, in comparison with that latency on a phyisical machine.
I
On Wed, 2015-04-15 at 11:35 +0100, Ian Campbell wrote:
> diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> index cfd5144..95fce9a 100755
> --- a/ts-debian-hvm-install
> +++ b/ts-debian-hvm-install
> @@ -77,6 +77,9 @@ d-i preseed/late_command string \\
> in-target mkdir -p /root
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 25 April 2015 01:19
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [PATCH 2/3] x86/hvm: introduce functions for
> HVMOP_get/set_param allowance checks
>
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 25 April 2015 01:12
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [PATCH 1/3] x86/hvm: give HVMOP_set_param and
> HVMOP_get_param their own functions
>
On Tue, Apr 28, 2015 at 9:45 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 28/04/15 12:36, Vijay Kilari wrote:
>> On Tue, Apr 28, 2015 at 4:05 PM, Julien Grall
>> wrote:
>>> If you properly manage the device with struct pci_dev or struct device
>>> (which is, as talked earlier, obviously required f
On Tue, Apr 28, 2015 at 05:50:43PM +0100, Julien Grall wrote:
> On 27/04/15 10:24, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Hi,
>
> Hi Edgar,
>
> > This is a first try at fixing the issue I'm seeing on ZynqMP with
> > missmatched setup of the SMMU and the shared page-table
On 29/04/2015 08:11, Jan Beulich wrote
> >>> "Wang, Wei W" 04/28/15 3:41 PM >>>
> >Please have a check my conclusion of the changes.
>
> These look all correct, with ...
>
> >NO.2
> >The xenpm "get-cpufreq-para" will display the following things:
> >cpu id: 0
> >affec
On 28/04/15 8:02 pm, Julien Grall wrote:
From: Julien Grall
This new function will correctly initialize the IOMMU page table for the
current domain.
Also use it in iommu_assign_dt_device even though the current IOMMU
implementation on ARM shares P2M with the processor.
Signed-off-by: Julien
On 29/04/2015 07:10, Jan Beulich wrote
> >>> "Wang, Wei W" 04/28/15 4:38 PM >>>
> >On 28/04/2015 21:29, Jan Beulich wrote
> > "Wang, Wei W" 04/28/15 3:24 PM >>>
> >> >On 28/04/2015 21:14, Jan Beulich wrote
> >> >> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
> >> >> >> How will this aff
On Tue, Apr 28, 2015 at 03:14:51PM -0400, Robert VanVossen wrote:
> Hello,
>
> I was wondering, what is the current state of running a 32-bit ARM guest
> running
> on a 64-bit Xen for ARM. I was working on getting the minios from
> https://github.com/talex5/xen/commits/next built and running as a
>>> David Vrabel 04/28/15 6:16 PM >>>
>On 23/04/15 12:58, Jan Beulich wrote:
>>> +typedef union {
>>> +u32 head_tail;
>>> +struct {
>>> +u16 head;
>>> +u16 tail;
>>> +};
>>> +} spinlock_tickets_t;
>>> +
>>> typedef struct spinlock {
>>> -raw_spinlock_t raw;
>>> +
>>> "Wang, Wei W" 04/28/15 4:38 PM >>>
>On 28/04/2015 21:29, Jan Beulich wrote
> "Wang, Wei W" 04/28/15 3:24 PM >>>
>> >On 28/04/2015 21:14, Jan Beulich wrote
>> >> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
>> >> >> How will this affect AMD processors which can use the cpufreq?
>> >>
>>> "Wang, Wei W" 04/28/15 3:41 PM >>>
>Please have a check my conclusion of the changes.
These look all correct, with ...
>NO.2
>The xenpm "get-cpufreq-para" will display the following things:
>cpu id: 0
>affected_cpus : 0
>cpuinfo frequency : max [37000
Commit 77e32c89a711 ("clockevents: Manage device's state separately for
the core") decouples clockevent device's modes from states. With this
change when a Xen guest tries to resume, it won't be calling its
set_mode op which needs to be done on each VCPU in order to make the
hypervisor aware that w
flight 52628 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/52628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 30511
test-amd64-i386-xl-qemu
Commit 77e32c89a711 ("clockevents: Manage device's state separately for
the core") decouples clockevent device's modes from states. With this
change when a Xen guest tries to resume, it won't be calling its
set_mode op which needs to be done on each VCPU in order to make the
hypervisor aware that w
Jim Fehlig wrote:
> wei.l...@citrix.com wrote:
>
>> Hi all
>>
>> We are now three months into 4.6 development window. This is an email to keep
>> track of all the patch series I gathered. It is by no means complete and / or
>> acurate. Feel free to reply this email with new projects or correct m
CMPXCHG sets CF, PF, AF, SF, and OF flags according to the results of the
comparison the rAX with the operand of the instruction.
rAX must be the first argument of the comparison (a minuend), the operand
must be the second one (a subtrahend).
Due to improper order of comparison arguments, CF, PF,
CMPXCHG: in the case of inequality of the rAX and the operand,
need to check CF, PF, AF, SF and OF flags as well.
This adjustment covers the fix of incorrect comparison during
CMPXCHG emulation.
Signed-off-by: Eugene Korenevsky
---
tools/tests/x86_emulator/test_x86_emulator.c | 2 +-
1 file cha
On 28/04/2015 20:14, Robert VanVossen wrote:
Hello,
Hi Robert,
I was wondering, what is the current state of running a 32-bit ARM guest running
on a 64-bit Xen for ARM. I was working on getting the minios from
https://github.com/talex5/xen/commits/next built and running as a guest on an
emul
Hello,
I was wondering, what is the current state of running a 32-bit ARM guest running
on a 64-bit Xen for ARM. I was working on getting the minios from
https://github.com/talex5/xen/commits/next built and running as a guest on an
emulated Cortex-A53. I have gotten Xen and 64-bit Linux guests run
On 04/28/2015 12:28 PM, David Vrabel wrote:
On 28/04/15 16:52, Boris Ostrovsky wrote:
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask
wei.l...@citrix.com wrote:
> Hi all
>
> We are now three months into 4.6 development window. This is an email to keep
> track of all the patch series I gathered. It is by no means complete and / or
> acurate. Feel free to reply this email with new projects or correct my
> misunderstanding.
>
[.
On 27/04/15 10:24, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Hi,
Hi Edgar,
> This is a first try at fixing the issue I'm seeing on ZynqMP with
> missmatched setup of the SMMU and the shared page-tables with p2m.
>
> I've only handled the case of having an SMMU that supports larg
On 28/04/15 16:52, Boris Ostrovsky wrote:
> After a resume the hypervisor/tools may change xenbus event
> channel number. We should re-query it.
[...]
> @@ -793,6 +818,9 @@ static int __init xenbus_init(void)
> goto out_error;
> }
>
> + if (!xen_initial_domain())
> +
On 28/04/15 16:52, Boris Ostrovsky wrote:
> When a guest is resumed, the hypervisor may change event channel
> assignments. If this happens and the guest uses 2-level events it
> is possible for the interrupt to be claimed by wrong VCPU since
> cpu_evtchn_mask bits may be stale. This can happen eve
On 28/04/15 16:52, Boris Ostrovsky wrote:
> .. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
> 'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
Reviewed-by: David Vrabel
David
___
Xen-devel mailing list
Xen-devel@lists.xen.or
On 28/04/15 16:52, Boris Ostrovsky wrote:
> After a resume the hypervisor/tools may change console event
> channel number. We should re-query it.
Reviewed-by: David Vrabel
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/x
Hi Vijay,
On 28/04/15 12:36, Vijay Kilari wrote:
> On Tue, Apr 28, 2015 at 4:05 PM, Julien Grall wrote:
>> If you properly manage the device with struct pci_dev or struct device
>> (which is, as talked earlier, obviously required for security) you
>> should avoid your so-called "dummy device". BT
On 23/04/15 12:58, Jan Beulich wrote:
>
>> +typedef union {
>> +u32 head_tail;
>> +struct {
>> +u16 head;
>> +u16 tail;
>> +};
>> +} spinlock_tickets_t;
>> +
>> typedef struct spinlock {
>> -raw_spinlock_t raw;
>> +spinlock_tickets_t tickets;
>
> At least for x
Fixes for issues that we discovered during live migration when source and
target systems have different event channel assignments for guests.
Boris Ostrovsky (4):
xen/events: Clear cpu_evtchn_mask before resuming
xen/xenbus: Update xenbus event channel on resume
xen/console: Update console e
After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky
---
drivers/xen/xenbus/xenbus_probe.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_p
.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
Signed-off-by: Boris Ostrovsky
Tested-by: Annie Li
---
drivers/xen/events/events_base.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/x
After a resume the hypervisor/tools may change console event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky
---
drivers/tty/hvc/hvc_xen.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even though
evtchn_2l_bind_to_cpu() attempts to clear
Since a PVH hardware domain has access to the physical hardware create a
custom more permissive IO bitmap. The permissions set on the bitmap are
populated based on the contents of the ioports rangeset.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: Sur
From: Julien Grall
A device node is described by a path. It will be used to retrieve the
node in the device tree and assign the related device to the domain.
Only non-PCI devices protected by an IOMMU can be assigned to a guest.
Also document the behavior of XEN_DOMCTL_deassign_device in the pu
From: Julien Grall
ARM and x86 use a different hypercall to map an IRQ to a domain.
The hypercall to give IRQ permission to the domain has also been moved
to be an x86 specific function as ARM guest won't be able to manage the IRQ.
We may want to support it later.
Signed-off-by: Julien Grall
A
From: Julien Grall
Allow the user to pass additional nodes to the guest device tree. For
this purpose, everything in the node /passthrough from the partial
device tree will be copied into the guest device tree.
The node /aliases will be also copied to allow the user to define
aliases which can b
From: Julien Grall
This is a follow-up of commit 525ee49 "xsm: add device tree labeling
support" which add support for device tree labelling in flask.
Those helpers will be use latter when non-pci passthrough (i.e device
tree) will be added.
Signed-off-by: Julien Grall
Acked-by: Daniel De Graa
From: Julien Grall
On ARM, every non-PCI device are described in the device tree. Each of
them can be found via a path.
This patch introduces a very basic support, only the IOMMU will be set
up correctly. The user will have to:
- Describe the device in the partial device tree
- Map manua
From: Julien Grall
The functions fdt_{fisrt,next}_subnode may not be available because:
* It has been introduced in 2013 => Doesn't work on Wheezy
* The prototype exists but the functions are not exposed. Don't ask
why...
The later has been fixed recently in the dtc repo [1]
When th
From: Julien Grall
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
Acked-by: Ian Campbell
---
Changes in v4:
- Add Ian's ack
Changes in v3:
- Add Stefano's ack
Changes in v2:
- Don't move the call in common code.
---
xen/arch/arm/domctl.c | 11 +
From: Julien Grall
Note that the example is done on Midway whose SMMU driver is not
supported on Xen upstream.
Currently, I don't have other platform where I can test Device Tree
passthrough.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v6:
- Typo in the doc
From: Julien Grall
The option "dtdev" will be used to passthrough a device described
in the device tree to a guest.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
Cc: Ian Jackson
Cc: Wei Liu
---
Changes in v5:
- Drop "non-PCI" in the commit message
- Add Ian's ack
From: Julien Grall
The partial device tree may contains phandle. The Device Tree Compiler
tends to allocate the phandle from 1.
Reserve the ID 65000 for the GIC phandle. I think we can safely assume
that the partial device tree will never contain a such ID.
Signed-off-by: Julien Grall
Acked-by
From: Julien Grall
Currently, when the device is deassigned from a domain, we directly reassign
to DOM0.
As the device may not have been correctly reset, this may lead to corruption or
expose some part of DOM0 memory. Also, we may have no way to reset some
platform devices.
If Xen reassigns the
On 28/04/2015 21:29, Jan Beulich wrote
"Wang, Wei W" 04/28/15 3:24 PM >>>
> >On 28/04/2015 21:14, Jan Beulich wrote
> >> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
> >> >> How will this affect AMD processors which can use the cpufreq?
> >> >> Would the ondemand feature go away?
> >> >
flight 52627 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/52627/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail REGR. vs. 36764
build-amd64-pvops
From: Julien Grall
The maximum size of the copied string has been chosen based on the value
use by XSM in similar case.
Furthermore, Linux seems to allow path up to 4096 characters. Though
this could vary from one OS to another.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Chan
From: Julien Grall
Xen has to release IRQ routed to a domain in order to reuse later.
Currently only SPIs can be routed to the guest so we only need to
browse SPIs for a specific domain.
Furthermore, a guest can crash and leave the IRQ in an incorrect state
(i.e has not been EOIed). Xen will hav
From: Julien Grall
On x86, an IRQ is assigned in 2 steps to an HVM guest:
- The toolstack is calling PHYSDEVOP_map_pirq in order to create a
guest PIRQ (IRQ bound to an event channel)
- The emulator (QEMU) is calling DOMCTL_bind_pt_irq in order to
bind the IRQ
On ARM, there is no
From: Julien Grall
Flask code already provides a helper to copy a string from guest. In a later
patch, the new DT hypercalls will need a similar function.
To avoid code duplication, copy the flask helper (flask_copying_string) to
common code:
- Rename into safe_copy_string_from_guest
- A
Hello all,
This is the sixth version of this patch series to add support for platform
device passthrough on ARM.
In order to passthrough a non-PCI device, the user will have to:
- Map manually MMIO/IRQ
- Describe the device in the newly partial device tree support
- Specify the list o
From: Julien Grall
Each domain may have a different number of IRQs depending on the devices
assigned to it.
Rather than re-using the number of IRQs used by the hardwared GIC, let
the toolstack specify the number of SPIs when the domain is created.
This will avoid wasting memory.
To calculate th
From: Julien Grall
This new function will correctly initialize the IOMMU page table for the
current domain.
Also use it in iommu_assign_dt_device even though the current IOMMU
implementation on ARM shares P2M with the processor.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
Acked-by: Ian
From: Julien Grall
The toolstack may not have deassigned every device used by a guest.
Therefore we have to go through the device list and remove them before
asking the IOMMU drivers to release memory for this domain.
This can be done by moving the call to the release function when we
relinquish
From: Julien Grall
Introduce spi_to_pending in order retrieve the irq_pending structure for
a specific SPI.
It's not possible to re-use irq_to_pending because it's required a VCPU
and some call of the new function may during domain destruction after
the VCPUs are freed.
Signed-off-by: Julien Gr
On 28/04/2015 21:29, Jan Beulich wrote
> >>> "Wang, Wei W" 04/28/15 3:24 PM >>>
> >On 28/04/2015 21:14, Jan Beulich wrote
> >> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
> >> >> How will this affect AMD processors which can use the cpufreq?
> >> >> Would the ondemand feature go away?
> >>
Hi Ian,
On 09/04/15 17:13, Ian Jackson wrote:
> Julien Grall writes ("[PATCH v5 p2 15/19] tools/(lib)xl: Add partial device
> tree support for ARM"):
>> Let the user to pass additional nodes to the guest device tree. For
>> this purpose, everything in the node /passthrough from the partial
>> dev
>>> "Wang, Wei W" 04/28/15 3:24 PM >>>
>On 28/04/2015 21:14, Jan Beulich wrote
>> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
>> >> How will this affect AMD processors which can use the cpufreq? Would
>> >> the ondemand feature go away?
>> >
>> >No, this won't affect them. When the "intel_p
On 28/04/2015 21:14, Jan Beulich wrote
> >On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
> >> How will this affect AMD processors which can use the cpufreq? Would
> >> the ondemand feature go away?
> >
> >No, this won't affect them. When the "intel_pstate=disable" is added to
> >the booting par
>>> Julien Grall 04/26/15 7:33 PM >>>
>On 26/04/2015 05:32, Wang, Wei W wrote:
>> Thanks for your comments. But I saw "int powernow_cpufreq_init(void);" is
>> put there.
>
>FWIW, this prototype doesn't have any implementation even on x86.
>
>While currently some drivers (such as the x86 powernow)
>>> "Wang, Wei W" 04/24/15 6:32 PM >>>
>On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
>> How will this affect AMD processors which can use the cpufreq? Would the
>> ondemand feature go away?
>
>No, this won't affect them. When the "intel_pstate=disable" is added to the
> booting parameter list
On Tue, Apr 28, 2015 at 4:05 PM, Julien Grall wrote:
> Hi,
>
> On 28/04/15 10:56, Stefano Stabellini wrote:
>> On Tue, 28 Apr 2015, Vijay Kilari wrote:
>>> Approach 1: (Using completion interrupt)
>>>
>>> 1) Create dummy device for each virtual ITS when virtual its is
>>> created
On Tue, Apr 28, Dario Faggioli wrote:
> On Tue, 2015-04-28 at 11:26 +0800, 蒋雄伟(蒋冲) wrote:
> > The xen we used is 4.0.1, but xenalyze –version tells me “xenalyze -
> > Open-source xen-unstable (3.4)” . can I use it?
This version string is just cosmetic.
Olaf
Hi,
On 28/04/15 10:56, Stefano Stabellini wrote:
> On Tue, 28 Apr 2015, Vijay Kilari wrote:
>> Approach 1: (Using completion interrupt)
>>
>> 1) Create dummy device for each virtual ITS when virtual its is
>> created for a domain
>> OR Allocate one interrupt number for each vi
Hi Stefano,
On 28/04/15 11:00, Stefano Stabellini wrote:
> On Mon, 27 Apr 2015, Julien Grall wrote:
>> diff --git a/xen/include/asm-arm/gic_v3_defs.h
>> b/xen/include/asm-arm/gic_v3_defs.h
>> index b8a1c2e..556f114 100644
>> --- a/xen/include/asm-arm/gic_v3_defs.h
>> +++ b/xen/include/asm-arm/gic
On Tue, 2015-04-28 at 11:26 +0800, 蒋雄伟(蒋冲) wrote:
> Hi, everyone
>
Hi,
> The xen we used is 4.0.1, but xenalyze –version tells me “xenalyze -
> Open-source xen-unstable (3.4)” . can I use it?
>
You can. Or, at least, I've always been able to, although it may depend
on what you're tracing. Have yo
On Mon, 27 Apr 2015, Julien Grall wrote:
> Currently, the GICv3 drivers is only able to send an SGI when the cpumask
> is provided. Although with the modes SGI_TARGET_OTHERS and SGI_TARGET_SELF,
> no cpumask is provided. Any usage of those modes will crash the hypersivor.
>
> Move the rename gicv3
On Tue, 28 Apr 2015, Vijay Kilari wrote:
> On Thu, Apr 2, 2015 at 7:17 PM, Julien Grall
> wrote:
> > Hi Ian,
> >
> > On 02/04/2015 12:18, Ian Campbell wrote:
> >>
> >> On Thu, 2015-04-02 at 12:06 +0100, Julien Grall wrote:
> >>
> Can we just enqueue with the hardware and use the guest vcpu p
From: Gerd Hoffmann
Avoid using deprecated gnutls functions with recent gnutls versions.
Fixes build failure on Fedora 16. Keep the old way for compatibility
with old installations such as RHEL-5 (gnutls 1.4.x).
Based on a patch from Raghavendra D Prabhu
Upstream commit f40d55081667a716312b9a
From: Andre Przywara
In my installation of GNU-TLS (v3.0.23) the type
gnutls_anon_server_credentials is marked deprecated, so -Werror
breaks compilation.
Simply replacing it with the newer ..._t version fixed the compilation
on my machine (Slackware 14.0). I cannot tell how far back this "new"
ty
Building qemu-traditional fails with current gnutls:
../libqemu_common.a(vnc.o): In function `vnc_start_tls':
/home/abuild/rpmbuild/BUILD/xen-4.6.30745/non-dbg/tools/qemu-xen-traditional-dir/vnc.c:2164:
undefined reference to `gnutls_kx_set_priority'
/home/abuild/rpmbuild/BUILD/xen-4.6.30745/non-
From: Arnd Bergmann
Use pci_scan_root_bus() instead of deprecated function
pci_scan_bus_parented().
Signed-off-by: Arnd Bergmann
Signed-off-by: Yijing Wang
CC: Konrad Rzeszutek Wilk
CC: xen-de...@lists.xenproject.org
---
drivers/pci/xen-pcifront.c | 16 +---
1 files changed, 13
No one uses pci_scan_bus_parented() any more,
remove it.
Signed-off-by: Yijing Wang
---
drivers/pci/probe.c | 19 ---
include/linux/pci.h |2 --
2 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6675a7a..7d6a61c
On Thu, Apr 2, 2015 at 7:17 PM, Julien Grall wrote:
> Hi Ian,
>
> On 02/04/2015 12:18, Ian Campbell wrote:
>>
>> On Thu, 2015-04-02 at 12:06 +0100, Julien Grall wrote:
>>
Can we just enqueue with the hardware and use the guest vcpu polling
loop to trigger us to check for completion?
>>>
Hello Christoph,
Il 28/04/2015 09:36, Christoph Hellwig ha scritto:
What happened to this patchset?
It was passed on to Bob Liu, who published a follow-up patchset here:
https://lkml.org/lkml/2015/2/15/46
Thanks,
Arianna
___
Xen-devel mailing l
On Mon, 2015-04-27 at 17:36 +0800, Robert Hu wrote:
> On Thu, 2015-04-23 at 00:34 +, Hu, Robert wrote:
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Wednesday, April 22, 2015 8:50 PM
> > > To: Ian Campbell
> > > Cc: Pang, LongtaoX; xen-d
On Fri, 2015-04-24 at 08:45 +, Pang, LongtaoX wrote:
>
>
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Thursday, April 23, 2015 7:30 PM
> > To: Hu, Robert
> > Cc: Pang, LongtaoX; xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> > wei.l..
What happened to this patchset?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
81 matches
Mail list logo
