>>> On 04.03.15 at 05:53, wrote:
> On 03/03/2015 08:20 PM, Luis R. Rodriguez wrote:
>> On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel wrote:
>>> On 03/03/15 09:40, Luis R. Rodriguez wrote:
if X86_64 && SPARSEMEM_VMEMMAP
Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to
>>> On 04.03.15 at 04:26, wrote:
> flight 35810 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/35810/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-rumpuserxen-amd64 5 xen-boot
(re-adding xen-devel to Cc)
>>> On 04.03.15 at 08:59, wrote:
> FYI, I no longer work on tboot (haven't for 4+ years). Jimmy is still Mr.
> tboot, however ;-)
Thanks for letting us know. I'll send a patch to update
./MAINTAINERS then.
Jan
___
Xen-d
... because of him indicating that he hasn't been working on it for the
past 4+ years.
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -180,7 +180,6 @@
F: tools/debugger/kdd/
INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
-M: Joseph Cihula
M: Gang Wei
M: Sh
>>> On 3/4/2015 at 01:15 AM, in message <54f5ec4e.6020...@eu.citrix.com>, George
Dunlap wrote:
> On 01/19/2015 08:28 AM, Chunyan Liu wrote:
> > To attach a usb device, a virtual usb controller should be created first.
> > This patch defines usbctrl and usbdevice related structs.
> >
> > Si
>>> On 03.03.15 at 11:32, wrote:
> On 03/03/2015 11:27 AM, Jan Beulich wrote:
> On 03.03.15 at 10:29, <"jgr...@suse.com".non-mime.internet> wrote:
>>> In order to indicate the Xen tools capability to support the virtual
>>> mapped linear p2m list instead the 3 level mfn tree add a flag to the
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Tuesday, February 17, 2015 6:47 PM
> To: Hu, Robert
> Cc: Wei Liu; Ian Jackson; xen-devel@lists.xen.org; jfeh...@suse.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 11/12] Changes on te
On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote:
> python-dev is not installed. Although I have libpython-dev installed.
And this used to work I suppose?
As I said in <1425404173.25940.82.ca...@citrix.com>:
m4/python_devel.m4 seems to suggest it was made optional on
purpose
... making more obvious what its so far open coded users intend.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -310,7 +310,7 @@ void free_vcpu_guest_context(struct vcpu
{
if ( !per_cpu(vgc_pages[i], cpu) )
continue;
-__se
From: Vijaya Kumar K
On x86, for the pages mapped with PAGE_HYPERVISOR attribute
non-leaf page tables are allocated with valid pte entries.
and with MAP_SMALL_PAGES attribute only non-leaf page tables are
allocated with invalid (valid bit set to 0) pte entries.
However on arm this is not the case
As pointed out in the discussion of the patch at
http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg03256.html
generalizing the conditions here means code elsewhere doesn't need to
take into consideration internals of how load balancing in the credit
scheduler works.
Signed-off-by: Ja
On 03/03/15 20:29, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 03, 2015 at 03:20:41PM -0500, Konrad Rzeszutek Wilk wrote:
>> Most of the APIC code that use APIC_LDR is not used on
>> 64-bit. On 32-bit it is bit of an hack - and the mechanism
>> it is uses is to "setup" the APIC_LDR via apci->init_ap
On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote:
> >>> On 03.03.15 at 11:32, wrote:
> > On 03/03/2015 11:27 AM, Jan Beulich wrote:
> > On 03.03.15 at 10:29, <"jgr...@suse.com".non-mime.internet> wrote:
> >>> In order to indicate the Xen tools capability to support the virtual
> >>> mapped
>>> On 04.03.15 at 10:35, wrote:
> On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote:
>> >>> On 03.03.15 at 11:32, wrote:
>> > On 03/03/2015 11:27 AM, Jan Beulich wrote:
>> > On 03.03.15 at 10:29, <"jgr...@suse.com".non-mime.internet> wrote:
>> >>> In order to indicate the Xen tools capabi
flight 35819 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 5 xen-boot fail REGR. vs. 35572
Regressions which a
On Tue, 2015-03-03 at 16:26 +, David Vrabel wrote:
> Every time a VIF is destroyed up-to 256 pages may be leaked if packets
> with more than MAX_SKB_FRAGS frags where transmitted from the guest.
> Even worse, if another user of ballooned pages allocated one of these
> ballooned pages it would n
On Wed, 2015-03-04 at 08:17 +, Jan Beulich wrote:
> >>> On 04.03.15 at 04:26, wrote:
> > flight 35810 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/35810/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which
On 04/03/15 09:48, Ian Campbell wrote:
> On Tue, 2015-03-03 at 16:26 +, David Vrabel wrote:
>> Every time a VIF is destroyed up-to 256 pages may be leaked if packets
>> with more than MAX_SKB_FRAGS frags where transmitted from the guest.
>> Even worse, if another user of ballooned pages allocat
On 04/03/15 09:10, Jan Beulich wrote:
> ... making more obvious what its so far open coded users intend.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -310,7 +310,7 @@ void free_vcpu_guest_context(struct vcpu
>
On Wed, 2015-03-04 at 00:26 -0700, Chun Yan Liu wrote:
>
> >>> On 3/3/2015 at 07:10 PM, in message
> >>> <1425381019.24959.87.ca...@citrix.com>, Ian
> Campbell wrote:
> > On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote:
> >
> > Sorry for the long delay in replying.
> >
> > > To attac
On Wed, 2015-03-04 at 09:56 +, David Vrabel wrote:
> On 04/03/15 09:48, Ian Campbell wrote:
> > On Tue, 2015-03-03 at 16:26 +, David Vrabel wrote:
> >> Every time a VIF is destroyed up-to 256 pages may be leaked if packets
> >> with more than MAX_SKB_FRAGS frags where transmitted from the g
Add Memory Bandwidth Monitoring(MBM) for VMs. Two types of monitoring
are supported: total and local memory bandwidth monitoring. To use it,
CMT should be enabled in hypervisor.
Signed-off-by: Chao Peng
---
Changes in v11:
1. term change: *_MEM_BANDWIDTH => *_MEM_COUNT.
2. Add assert(nr <= ARRAY_
On Wed, 2015-03-04 at 09:42 +, Jan Beulich wrote:
> >>> On 04.03.15 at 10:35, wrote:
> > On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote:
> >> >>> On 03.03.15 at 11:32, wrote:
> >> > On 03/03/2015 11:27 AM, Jan Beulich wrote:
> >> > On 03.03.15 at 10:29, <"jgr...@suse.com".non-mime.i
On Wed, 2015-03-04 at 09:04 +0800, Chao Peng wrote:
> On Tue, Mar 03, 2015 at 10:09:39AM +, Ian Campbell wrote:
> > On Tue, 2015-03-03 at 16:00 +0800, Chao Peng wrote:
> > > On Mon, Mar 02, 2015 at 01:48:43PM +, Ian Campbell wrote:
> > > > On Thu, 2015-02-26 at 16:45 +0800, Chao Peng wrote:
On Tue, 3 Mar 2015, Gordan Bobic wrote:
> Hi,
>
> I've been looking into custom e820 maps for domUs again, and
> found that functionality to provide QEMU with hints regarding
> e820 mapping has been upstream since some time in
> 2010 (FW_CFG_E820_TABLE) with more finely grained control
> (usable r
On Tue, 3 Mar 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 03/03/2015 18:07, Stefano Stabellini wrote:
> > I would like to see a more generic handling of virq != physical irq.
> > This is not specific to LPIs but to any scenario where the physical irq
> > differs from the virtual irq.
>
> I tho
On Tue, 2015-03-03 at 10:51 +, Jan Beulich wrote:
> >>> On 27.02.15 at 15:54, wrote:
> > The idea is that, whether the mask is full because no one touched this
> > default, or because it has been manually set like that, there is nothing
> > to do at the soft affinity balancing level.
>
> In
On 03/04/2015 11:06 AM, Ian Campbell wrote:
On Wed, 2015-03-04 at 09:42 +, Jan Beulich wrote:
On 04.03.15 at 10:35, wrote:
On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote:
On 03.03.15 at 11:32, wrote:
On 03/03/2015 11:27 AM, Jan Beulich wrote:
On 03.03.15 at 10:29, <"jgr...@suse.c
Hi Jan,
I am sorry, But had the impression you were somehow the owner of these
feature. My mistake.
I understand the feature is in preview, But are you feeling intense
presure when I ask for some status every 2 months? :-))
BR,
Jeroen
Jan Beulich schreef op 27-2-2015 om 09:08:
On 26.02.15
Stefano,
Many thanks for responding to this. Resplies inline below.
On 2015-03-04 10:11, Stefano Stabellini wrote:
On Tue, 3 Mar 2015, Gordan Bobic wrote:
Hi,
I've been looking into custom e820 maps for domUs again, and
found that functionality to provide QEMU with hints regarding
e820 mappin
Hi, Juergen.
Thanks for your advice. I will send a v2 patch based on your suggested
modifications.
On 2015/3/3 17:52, Juergen Gross wrote:
On 03/03/2015 09:37 AM, Tao Chen wrote:
Replace the string of {xen-pvscsi:} in the pr sentences with DRV_PFX,
it makes the code easier to read.
I'm not
Defined the string of {xen-pvscsi: } as DRV_PFX, then use it in the pr
sentences and DPRINTK.
Also fixed up some comments just as eliminate redundant white spaces and format
the code.
These will make the code easier to read.
Signed-off-by: Tao Chen
---
drivers/xen/xen-scsiback.c | 70 +
On 04/03/15 18:32, Tao Chen wrote:
> Defined the string of {xen-pvscsi: } as DRV_PFX, then use it in the pr
> sentences and DPRINTK.
> Also fixed up some comments just as eliminate redundant white spaces and
> format the code.
> These will make the code easier to read.
I have already said you ne
On Wed, 4 Mar 2015, Gordan Bobic wrote:
> Stefano,
>
> Many thanks for responding to this. Resplies inline below.
>
> On 2015-03-04 10:11, Stefano Stabellini wrote:
> > On Tue, 3 Mar 2015, Gordan Bobic wrote:
> > > Hi,
> > >
> > > I've been looking into custom e820 maps for domUs again, and
> >
On 2015-03-04 10:33, Stefano Stabellini wrote:
On Wed, 4 Mar 2015, Gordan Bobic wrote:
Stefano,
Many thanks for responding to this. Resplies inline below.
On 2015-03-04 10:11, Stefano Stabellini wrote:
> On Tue, 3 Mar 2015, Gordan Bobic wrote:
> > Hi,
> >
> > I've been looking into custom e820
On Wed, 2015-03-04 at 10:38 +, Gordan Bobic wrote:
> > I don't follow you here: what is the etc/e820 interface?
>
> See the 2nd patch I mentioned above, which supposedly
> adds "etc/e820 fw_cfg file" (whatever that means).
The problem here is that hvmloader controls and can make modifications
On Wed, 4 Mar 2015, Gordan Bobic wrote:
> On 2015-03-04 10:33, Stefano Stabellini wrote:
> > On Wed, 4 Mar 2015, Gordan Bobic wrote:
> > > Stefano,
> > >
> > > Many thanks for responding to this. Resplies inline below.
> > >
> > > On 2015-03-04 10:11, Stefano Stabellini wrote:
> > > > On Tue, 3 M
On Wed, 2015-03-04 at 11:20 +0100, Juergen Gross wrote:
> On 03/04/2015 11:06 AM, Ian Campbell wrote:
> > On Wed, 2015-03-04 at 09:42 +, Jan Beulich wrote:
> > On 04.03.15 at 10:35, wrote:
> >>> On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote:
> >>> On 03.03.15 at 11:32, wrote:
>
On 04/03/15 10:20, Juergen Gross wrote:
>
> I could, of course, wait with the flag bit until xl is ready and post
> another kernel patch then. Unfortunately this would delay Linux support
> for automatically be able to run as a pv-domain >500GB further, so I
> strongly recommend accepting the inte
On Tue, 2015-03-03 at 09:12 +, Jan Beulich wrote:
> >>> On 03.03.15 at 04:15, wrote:
> > On Sun, 2015-02-08 at 17:45 -1000, Justin T. Weaver wrote:
> >> +#define csched2_cpumask cpumask[smp_processor_id()]
> >> +
> > I like the idea, but put the right side between parentheses.
>
> Parenthese
On Wed, 2015-03-04 at 10:50 +, Stefano Stabellini wrote:
> On Wed, 4 Mar 2015, Gordan Bobic wrote:
> > On 2015-03-04 10:33, Stefano Stabellini wrote:
> > > On Wed, 4 Mar 2015, Gordan Bobic wrote:
> > > > Stefano,
> > > >
> > > > Many thanks for responding to this. Resplies inline below.
> > >
On 03/04/2015 11:59 AM, David Vrabel wrote:
On 04/03/15 10:20, Juergen Gross wrote:
I could, of course, wait with the flag bit until xl is ready and post
another kernel patch then. Unfortunately this would delay Linux support
for automatically be able to run as a pv-domain >500GB further, so I
When handling a from-guest frag list, xenvif_handle_frag_list()
replaces the frags before calling the destructor to clean up the
original (foreign) frags. Whilst this is safe (the destructor doesn't
actually use the frags), it looks odd.
Reorder the function to be less confusing.
Signed-off-by:
Use correct pointer arithmetic to get the pointer to each stat.
Signed-off-by: David Vrabel
---
drivers/net/xen-netback/interface.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index f38227a..3
Every time a VIF is destroyed up to 256 pages may be leaked if packets
with more than MAX_SKB_FRAGS frags were transmitted from the guest.
Even worse, if another user of ballooned pages allocated one of these
ballooned pages it would not handle the unexpectedly >1 page count
(e.g., gntdev would dea
A couple of bug fixes for netback:
- make ethool stats to report the correct values.
- don't leak 1 MiB every time a VIF is destroyed.
Changes in v2:
- Split 2nd patch into leak fix and refactor patches
David
___
Xen-devel mailing list
Xen-devel@lists
On 04/03/15 11:09, Juergen Gross wrote:
> On 03/04/2015 11:59 AM, David Vrabel wrote:
>> On 04/03/15 10:20, Juergen Gross wrote:
>>>
>>> I could, of course, wait with the flag bit until xl is ready and post
>>> another kernel patch then. Unfortunately this would delay Linux support
>>> for automati
At 10:52 + on 04 Mar (1425462776), Ian Campbell wrote:
> On Wed, 2015-03-04 at 11:20 +0100, Juergen Gross wrote:
> > I'd like to do an appropriate change in xl, but I've been told this
> > would make sense only for migration protocol V2. OTOH I don't want to
> > wait for an undefined amount of
On Tue, Mar 3, 2015 at 5:02 PM, Ian Campbell wrote:
> libxl is intended to be an LGPL 2.1 licensed library, however this
> file inadvertently got given a GPL header.
>
> The following people have touched this file, although all but Machon's
> contributions are trivial and/or mechanical an Ack from
On 03/04/2015 12:18 PM, Tim Deegan wrote:
At 10:52 + on 04 Mar (1425462776), Ian Campbell wrote:
On Wed, 2015-03-04 at 11:20 +0100, Juergen Gross wrote:
I'd like to do an appropriate change in xl, but I've been told this
would make sense only for migration protocol V2. OTOH I don't want to
On Wed, 2015-03-04 at 11:14 +, David Vrabel wrote:
All three patches:
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, 2015-03-04 at 12:22 +0100, Juergen Gross wrote:
> It would either be used like intended,
Which is how? That is what is really missing here.
So far this appears to be a bit which enables some as yet unspecified[0]
behaviour in one particular OS kernel with some as yet undiscussed
potential
On Wed, 2015-03-04 at 09:16 +, Jan Beulich wrote:
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -292,11 +292,9 @@ __runq_remove(struct csched_vcpu *svc)
> static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
>
On Tue, 3 Mar 2015, Stefano Stabellini wrote:
> On Mon, 2 Mar 2015, vijay.kil...@gmail.com wrote:
> > @@ -94,19 +95,29 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu
> > *v, mmio_info_t *info,
> > switch ( gicr_reg )
> > {
> > case GICR_CTLR:
> > -/* We have not imp
On 03/04/2015 10:00 AM, Ian Campbell wrote:
> On Wed, 2015-03-04 at 00:26 -0700, Chun Yan Liu wrote:
>>
> On 3/3/2015 at 07:10 PM, in message
> <1425381019.24959.87.ca...@citrix.com>, Ian
>> Campbell wrote:
>>> On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote:
>>>
>>> Sorry for th
Hi Ian,
On 04/03/15 09:07, Ian Campbell wrote:
> On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote:
>> python-dev is not installed. Although I have libpython-dev installed.
>
> And this used to work I suppose?
>
> As I said in <1425404173.25940.82.ca...@citrix.com>:
>
> m4/python_de
On Wed, 2015-03-04 at 12:26 +, George Dunlap wrote:
> On 03/04/2015 10:00 AM, Ian Campbell wrote:
> > On Wed, 2015-03-04 at 00:26 -0700, Chun Yan Liu wrote:
> >>
> > On 3/3/2015 at 07:10 PM, in message
> > <1425381019.24959.87.ca...@citrix.com>, Ian
> >> Campbell wrote:
> >>> On Mon,
On Wed, 2015-03-04 at 12:27 +, Julien Grall wrote:
> Hi Ian,
>
> On 04/03/15 09:07, Ian Campbell wrote:
> > On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote:
> >> python-dev is not installed. Although I have libpython-dev installed.
> >
> > And this used to work I suppose?
> >
> > As I
On 04/03/15 12:35, Ian Campbell wrote:
> On Wed, 2015-03-04 at 12:27 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 04/03/15 09:07, Ian Campbell wrote:
>>> On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote:
python-dev is not installed. Although I have libpython-dev installed.
>>>
>>> And t
>>> On 04.03.15 at 12:03, wrote:
> I see the point you're making, and I can live with _choose_cpu(), but
> the result would look a bit inconsistent, IMO.
I'm tempted to ask for a cleanup patch then.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.
Hello.
On 3/3/2015 7:26 PM, David Vrabel wrote:
Use correct pointer arithmetic to get the pointer to each stat.
Signed-off-by: David Vrabel
---
drivers/net/xen-netback/interface.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface
On Tue, 2015-03-03 at 08:55 +, Jan Beulich wrote:
> >>> On 03.03.15 at 04:42, wrote:
> > Indeed. It tells Xen: < > could not come up with any sane vnode-to-pnode mapping, please figure
> > that out yourself>>.
> >
> > That makes the code, IMO, simpler at any level. In fact, at Xen level,
> >
On 04.03.2015 07:14, Greg Kroah-Hartman wrote:
> 3.18-stable review patch. If anyone has any objections, please let me know.
I thought I replied earlier today but I cannot seem to find it coming back via
the mailing list. Hope this is not duplicating too much... There was a
regression with that p
>>> On 04.03.15 at 13:08, wrote:
> On Wed, 2015-03-04 at 09:16 +, Jan Beulich wrote:
>> --- a/xen/common/sched_credit.c
>> +++ b/xen/common/sched_credit.c
>> @@ -292,11 +292,9 @@ __runq_remove(struct csched_vcpu *svc)
>> static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
>>
On Wed, 2015-03-04 at 12:47 +, Julien Grall wrote:
> On 04/03/15 12:35, Ian Campbell wrote:
> > On Wed, 2015-03-04 at 12:27 +, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 04/03/15 09:07, Ian Campbell wrote:
> >>> On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote:
> python-dev is
On Wed, 2015-03-04 at 12:50 +, Jan Beulich wrote:
> >>> On 04.03.15 at 12:03, wrote:
> > I see the point you're making, and I can live with _choose_cpu(), but
> > the result would look a bit inconsistent, IMO.
>
> I'm tempted to ask for a cleanup patch then.
>
Yep, and I'd be fine with that.
>>> On 04.03.15 at 14:08, wrote:
> On Wed, 2015-03-04 at 12:50 +, Jan Beulich wrote:
>> >>> On 04.03.15 at 12:03, wrote:
>> > I see the point you're making, and I can live with _choose_cpu(), but
>> > the result would look a bit inconsistent, IMO.
>>
>> I'm tempted to ask for a cleanup patch
VT-d Posted-interrupt (PI) design for XEN
Background
==
With the development of virtualization, there are more and more device
assignment requirements. However, today when a VM is running with
assigned devices (such as, NIC), external interrupt handling for the assigned
devices always need
On 03/02/2015 12:39 PM, David Vrabel wrote:
On 26/02/15 13:35, Juergen Gross wrote:
Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that domU. The
communication is all done via the pvUSB backend in a driver domain
(usually D
On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote:
> >> - move module to appropriate location in kernel tree
> >
> > drivers/xen/ is the correct location for this driver.
>
> Hmm, so you regard placement of xen-netback under drivers/net and
> xen-blkback under drivers/block as wrong? I've jus
On 03/04/2015 02:41 PM, Ian Campbell wrote:
On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote:
- move module to appropriate location in kernel tree
drivers/xen/ is the correct location for this driver.
Hmm, so you regard placement of xen-netback under drivers/net and
xen-blkback under d
On 04/03/15 13:31, Juergen Gross wrote:
> On 03/02/2015 12:39 PM, David Vrabel wrote:
>> On 26/02/15 13:35, Juergen Gross wrote:
>>> Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
>>> domU to communicate with a USB device assigned to that domU. The
>>> communication is all do
El 04/03/15 a les 14.00, Ian Campbell ha escrit:
> On Wed, 2015-03-04 at 12:47 +, Julien Grall wrote:
>> On 04/03/15 12:35, Ian Campbell wrote:
>>> On Wed, 2015-03-04 at 12:27 +, Julien Grall wrote:
Hi Ian,
On 04/03/15 09:07, Ian Campbell wrote:
> On Tue, 2015-03-03 at 19
On Wed, 2015-03-04 at 15:02 +0100, Roger Pau Monné wrote:
> Yes, I think so, for python versions > 2.4 we should require
> python-config.
ACK.
> IMHO python_fortify_noopt.m4 should also be fixed to deal
> with older python version that don't have python-config.
That would be ideal, but unless so
On 03/04/2015 02:53 PM, David Vrabel wrote:
On 04/03/15 13:31, Juergen Gross wrote:
On 03/02/2015 12:39 PM, David Vrabel wrote:
On 26/02/15 13:35, Juergen Gross wrote:
Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that d
On 04/03/15 14:09, Juergen Gross wrote:
>
> The main question whether it is worth to consider this alternative is
> the performance aspect. Does anyone have an idea which USB devices would
> typically be used via pvusb? I'd suspect memory sticks and USB disks
> and perhaps webcams being the most p
On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote:
> On 04/03/15 14:09, Juergen Gross wrote:
> >
> > The main question whether it is worth to consider this alternative is
> > the performance aspect. Does anyone have an idea which USB devices would
> > typically be used via pvusb? I'd suspect m
On Wed, 2015-03-04 at 15:41 +0100, Juergen Gross wrote:
> On 03/04/2015 03:29 PM, Ian Campbell wrote:
> > On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote:
> >> On 04/03/15 14:09, Juergen Gross wrote:
> >>>
> >>> The main question whether it is worth to consider this alternative is
> >>> the p
flight 35854 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35854/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
build-amd64-rumpuserx
On Tue, Mar 03, 2015 at 02:31:51PM -0800, Paul E. McKenney wrote:
> On Tue, Mar 03, 2015 at 05:06:50PM -0500, Boris Ostrovsky wrote:
> > On 03/03/2015 04:26 PM, Paul E. McKenney wrote:
> > >On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote:
> > >>On 03/03/2015 02:42 PM, Paul E. McKenn
>>> On 04.03.15 at 15:37, wrote:
> I looked to the interface of XENDOMCTL_bind_pt_irq and I'm not sure
> about the meaning of machine_irq and isa_irq.
>
> AFAIU the code:
> machine_irq => guest PIRQ
Yes (i.e. the Xen assigned representation of an IRQ the guest has
been granted access to).
On 03/04/2015 08:28 AM, Chun Yan Liu wrote:
>
>
On 3/4/2015 at 01:15 AM, in message <54f5ec4e.6020...@eu.citrix.com>,
George
> Dunlap wrote:
>> On 01/19/2015 08:28 AM, Chunyan Liu wrote:
>>> To attach a usb device, a virtual usb controller should be created first.
>>> This patch de
On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 03, 2015 at 06:38:20PM +0300, Andrey Ryabinin wrote:
>> On 03/03/2015 05:16 PM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Mar 03, 2015 at 04:15:06PM +0300, Andrey Ryabinin wrote:
On 03/03/2015 12:40 PM, Luis R. Rodriguez wrote:
Hi,
On 23/02/15 16:02, Ian Campbell wrote:
> On Mon, 2015-02-23 at 15:51 +, Julien Grall wrote:
>> On 20/02/15 16:53, Ian Campbell wrote:
>
>>> Are we absolutely 100% sure that we will never ever want to map hardware
>>> IRQs to guests on ARMs using pirq-type event channels? Because that is
>
On 03/04/2015 03:29 PM, Ian Campbell wrote:
On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote:
On 04/03/15 14:09, Juergen Gross wrote:
The main question whether it is worth to consider this alternative is
the performance aspect. Does anyone have an idea which USB devices would
typically be
On 04/03/15 14:55, Jan Beulich wrote:
On 04.03.15 at 15:37, wrote:
>> I looked to the interface of XENDOMCTL_bind_pt_irq and I'm not sure
>> about the meaning of machine_irq and isa_irq.
>>
>> AFAIU the code:
>> machine_irq => guest PIRQ
>
> Yes (i.e. the Xen assigned representation of
On 03/04/2015 09:43 AM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 02:31:51PM -0800, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 05:06:50PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 04:26 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote:
O
Juergen Gross wrote:
> Do you have another feeling about the probability of a need to do usb 3?
> If it is already on the horizon I wouldn't want to do the user space
> backend now and the kernel one next year. :-)
One year is pretty long in kernel time.
//Peter
>>> On 04.03.15 at 14:30, wrote:
> - Introduce a new global vector which is used to wake up the HLT'ed vCPU.
> Currently, there is a global vector 'posted_intr_vector', which is used as
> the
> global notification vector for all vCPUs in the system. This vector is
> stored in
> VMCS and CPU cons
On Wed, Mar 04, 2015 at 09:55:11AM -0500, Boris Ostrovsky wrote:
> On 03/04/2015 09:43 AM, Paul E. McKenney wrote:
> >On Tue, Mar 03, 2015 at 02:31:51PM -0800, Paul E. McKenney wrote:
> >>On Tue, Mar 03, 2015 at 05:06:50PM -0500, Boris Ostrovsky wrote:
> >>>On 03/03/2015 04:26 PM, Paul E. McKenney
On Wed, Mar 04, 2015 at 02:31:08PM +0100, Juergen Gross wrote:
> On 03/02/2015 12:39 PM, David Vrabel wrote:
> >On 26/02/15 13:35, Juergen Gross wrote:
> >>Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
> >>domU to communicate with a USB device assigned to that domU. The
> >>
On 03/04/2015 04:27 PM, Greg KH wrote:
On Wed, Mar 04, 2015 at 02:31:08PM +0100, Juergen Gross wrote:
On 03/02/2015 12:39 PM, David Vrabel wrote:
On 26/02/15 13:35, Juergen Gross wrote:
Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
domU to communicate with a USB device
On 04/03/15 14:55, Boris Ostrovsky wrote:
>
> In the meantime, it turned out that HVM guests are broken by this patch
> (with our without changes that we've been discussing), because HVM CPUs
> die with
>
> static void xen_hvm_cpu_die(unsigned int cpu)
> {
> xen_cpu_die(cpu);
> na
flight 35825 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35825/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 35673
Tests which did not succeed, but are
Ian Campbell writes ("Re: "./configure: line 7058: python-config: command not
found" after commit 0013245"):
> On Wed, 2015-03-04 at 15:02 +0100, Roger Pau Monné wrote:
> > Yes, I think so, for python versions > 2.4 we should require
> > python-config.
>
> ACK.
>
> > IMHO python_fortify_noopt.m4
On 27/02/15 11:33, Roger Pau Monne wrote:
> iommu_share_p2m_table should not prevent PVH guests from using a shared page
> table between the IOMMU and EPT. Clean the code by removing the asserts in
> the vendor specific implementations (amd_iommu_share_p2m, iommu_set_pgd),
> and moving the hap_enab
On 03/04/2015 10:45 AM, David Vrabel wrote:
On 04/03/15 14:55, Boris Ostrovsky wrote:
In the meantime, it turned out that HVM guests are broken by this patch
(with our without changes that we've been discussing), because HVM CPUs
die with
static void xen_hvm_cpu_die(unsigned int cpu)
{
On Wed, 2015-03-04 at 16:07 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: "./configure: line 7058: python-config: command not
> found" after commit 0013245"):
> > That would be ideal, but unless someone shows me/us a system with Python
> > <=2.4 which suffers from this issue I'd also be in
On Wed, 2015-03-04 at 18:32 +, Tao Chen wrote:
> Defined the string of {xen-pvscsi: } as DRV_PFX, then use it in the pr
> sentences and DPRINTK.
> Also fixed up some comments just as eliminate redundant white spaces and
> format the code.
> These will make the code easier to read.
It'd proba
Hi folks,
just a quick note to let you know that we were not accepted for GSoC this year.
Do note that the Linux Foundation, OpenStack Foundation and many of the other
usual suspects have not been accepted this year. We will find out more why on
Friday. However, there are at least 4 Xen related
1 - 100 of 126 matches
Mail list logo
