I noticed this the other day and had a quick scout around.
"Mozilla not accepted for Google Summer of Code 2015"
http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Summer-of-Code-2015
"Google’s program is enormously popular, and over-subscribed, meaning Google
has had to rotat
>>> On 05.03.15 at 05:45, wrote:
> On Feb 18, 2015 17:03, Jan Beulich wrote:
>> In order for commit cbeeaa7d ("x86/nmi: fix shootdown of pcpus
>> running in VMX non-root mode")'s re-use of that fixmap entry to not
>> cause undesirable (in crash context) cross-CPU TLB flushes, invalidate
>> the fix
>>> On 05.03.15 at 06:04, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, March 04, 2015 11:19 PM
>> >>> 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_vec
flight 35867 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35867/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 35702
Regressions which
>>> On 3/4/2015 at 10:41 PM, in message <54f71992.5080...@eu.citrix.com>, George
Dunlap wrote:
> 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
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, March 05, 2015 2:48 AM
> To: Wu, Feng; xen-devel@lists.xen.org
> Cc: Zhang, Yang Z; Tian, Kevin; Jan Beulich
> Subject: Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN
>
> On 04/03/1
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, March 04, 2015 11:19 PM
> To: Wu, Feng
> Cc: Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org
> Subject: Re: VT-d Posted-interrupt (PI) design for XEN
>
> >>> On 04.03.15 at 14:30, wrote:
> > - Int
>>> On 3/4/2015 at 08:33 PM, in message <1425472438.25940.147.ca...@citrix.com>,
Ian Campbell wrote:
> 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
On Feb 18, 2015 17:03, Jan Beulich wrote:
> There's no need for more than one variable, no need for casts, and no
> point in using the type-safe xmalloc_array() here.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/tboot.c
> +++ b/xen/arch/x86/tboot.c
> @@ -435,13 +435,12 @@ int __init tb
On Feb 18, 2015 17:03, Jan Beulich wrote:
> In order for commit cbeeaa7d ("x86/nmi: fix shootdown of pcpus
> running in VMX non-root mode")'s re-use of that fixmap entry to not
> cause undesirable (in crash context) cross-CPU TLB flushes, invalidate
> the fixmap entry right after use.
>
> Signed-o
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, March 5, 2015 3:43 AM
> To: Wang, Xiaoming
> Cc: ch...@chris-wilson.co.uk; david.vra...@citrix.com;
> lau...@codeaurora.org; heiko.carst...@de.ibm.com; li...@horizon.com;
> l...@aserp2030.o
Hi, all:
I want to learn how the emulated NICs work in XEN. So I boot a DomU with an
emulated rtl8139 NIC, ping host from DomU and capture the trace info using
xentrace tool, and then check the log of qemu-dm and trace info analyzed by
xenalyze tool. I have enabled debug in rtl8139.c and added
On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin wrote:
> On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote:
>> If it is like that - then just using what had to be implemented
>> for the stack protection as a template ought to pave most of the
>> work?
>
> Probably. I think I could make this work
flight 35860 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35860/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Regressions which are
On 03/05/2015 05:21 AM, Konrad Rzeszutek Wilk wrote:
>>> David assertion that better performance and scalbility can be gained
>>> with grant table locking and TLB flush avoidance is interesting - as
>>> 1). The grant locking is going in Xen 4.6 but not earlier - so when running
>>> on older hy
On Wed, Mar 04, 2015 at 10:07:56AM +, Ian Campbell wrote:
> 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 Campb
On Tuesday, March 03, 2015 02:54:50 PM Mike Latimer wrote:
> Thanks for all the help and patience as we've worked through this. Ack to
> the whole series:
>
> Acked-by: Mike Latimer
I guess the more correct response is:
Reviewed-by: Mike Latimer
Tested-by: Mike Latimer
-Mike
_
flight 35863 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35863/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs. 35524
Regressions which are reg
On 03/04/2015 03:06 PM, Tamas K Lengyel wrote:
>> Right. The key observation is that at any single point in time, a given
>> hardware thread can be fetching an instruction or reading data, but not
>> both.
>
> Fine, as long as an instruction reading itself isn't going to lead to
> Right. The key observation is that at any single point in time, a given
> hardware thread can be fetching an instruction or reading data, but not
> both.
Fine, as long as an instruction reading itself isn't going to lead to
a live lock.
>>>
>>> That's not how the h
> > David assertion that better performance and scalbility can be gained
> > with grant table locking and TLB flush avoidance is interesting - as
> > 1). The grant locking is going in Xen 4.6 but not earlier - so when running
> > on older hypervisors this gives an performance benefit.
> >
> >
On Tue, Mar 03, 2015 at 04:11:09PM +0800, Wang Xiaoming wrote:
> The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
> And the size of IO_TLB_DEFAULT_SIZE is limited to (64UL<<20) 64M now.
> While in different platform and different requirement this seems improper.
> So modifing the IO_TLB_SEGSI
On 04/03/15 13:30, Wu, Feng wrote:
> VT-d Posted-interrupt (PI) design for XEN
Thankyou very much for this!
>
> Background
> ==
> With the development of virtualization, there are more and more device
> assignment requirements. However, today when a VM is running with
> assigned devices (
flight 35847 linux-3.16 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35847/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167
test-amd64-i386-pair
On Wed, Mar 04, 2015 at 01:51:53PM +0100, Stefan Bader wrote:
> 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. Hop
> On 4 Mar 2015, at 17:40, Amir Chaudhry wrote:
>
> I noticed this the other day and had a quick scout around.
>
> "Mozilla not accepted for Google Summer of Code 2015"
> http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Summer-of-Code-2015
>
> "Google’s program is enormous
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
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
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 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 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
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
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
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
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 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 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 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
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 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
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 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 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 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 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 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
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 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
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 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 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 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
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 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
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 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/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
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 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
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 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 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 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 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,
> >
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 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.
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 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 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,
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 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
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 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: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 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 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 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
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 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
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
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
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
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
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 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 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 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 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 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 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, 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 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
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 +
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
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 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
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
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
1 - 100 of 126 matches
Mail list logo
