Hi,
About rx zerocopy, I have a question:
If some application make a socket, then listen and accept, the client
sends packets to it, but it doesn't recv from this socket right now, all
persistent grant page would be in used.
So other application cannot receive any packets. Is m
On Wed, 20 May 2015, Major Hayden wrote:
> On 05/20/2015 05:41 AM, Jan Beulich wrote:
> > Considering that no-one else is seeing this - is this perhaps connected
> > to you building Xen with pre-release gcc 5.0.1? This is also because in
> > order for the above to indeed occur, mmio_ro_do_page_fau
On 29/05/15 03:36, Luis R. Rodriguez wrote:
> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez wrote:
>> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>>> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn He
flight 57454 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
56941
Tests which
On Fri, May 29, 2015 at 01:10:44AM +0200, Luis R. Rodriguez wrote:
> Great, thanks. This seems to be in alignment with those who have all along
> said
> they've used EXPORT_SYMBOL() to mean what EXPORT_SYMBOL_GPL() users now use it
> for. Nevertheless -- maintainers should know that some stubborn
flight 57448 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57448/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 57362 REGR.
vs. 56831
Tests whi
On 26/05/2015 21:17, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > +extern int cpufreq_register_driver(struct cpufreq_driver
> > +*driver_data); extern int cpufreq_unregister_driver(struct
> > +cpufreq_driver *driver);
>
> Oh, btw, please also get rid of "extern" on function declaratio
On 26/05/2015 21:06, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > Register/unregister the CPU hotplug notifier when the driver is
> > registered, and move the driver register/unregister function to the
> > cpufreq.c.
>
> Without saying why I'm afraid I don't even see much reason to re
On Thu, May 28, 2015 at 02:26:03PM +0100, Jan Beulich wrote:
>
> > --- a/xen/include/public/sysctl.h
> > +++ b/xen/include/public/sysctl.h
> > @@ -694,6 +694,20 @@ struct xen_sysctl_pcitopoinfo {
> > typedef struct xen_sysctl_pcitopoinfo xen_sysctl_pcitopoinfo_t;
> > DEFINE_XEN_GUEST_HANDLE(xen_
On Thu, May 28, 2015 at 02:17:54PM +0100, Jan Beulich wrote:
> >>> On 21.05.15 at 10:41, wrote:
> > For each socket, a COS to CBM mapping structure is maintained for each
> > COS. The mapping is indexed by COS and the value is the corresponding
> > CBM. Different VMs may use the same CBM, a refere
On Thu, May 28, 2015 at 01:54:39PM +0100, Jan Beulich wrote:
> >>> On 21.05.15 at 10:41, wrote:
> > +
> > +if ( !cpu_has(c, X86_FEATURE_CAT) )
> > +return;
> > +
> > +socket = cpu_to_socket(cpu);
> > +if ( test_bit(socket, cat_socket_enable) )
> > +return;
> > +
> > +
On Thu, May 28, 2015 at 01:38:05PM +0100, Jan Beulich wrote:
> >>> On 21.05.15 at 10:41, wrote:
> > --- a/xen/arch/x86/mpparse.c
> > +++ b/xen/arch/x86/mpparse.c
> > @@ -87,6 +87,18 @@ void __init set_nr_cpu_ids(unsigned int max_cpus)
> > #endif
> > }
> >
> > +void __init set_nr_sockets(void)
flight 57442 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57442/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 57123
test-amd64-i386-libvirt 1
On Thu, May 28, 2015 at 1:56 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> Current documentation over use case for EXPORT_SYMBOL_GPL()
> only acknowledges functions which are "an internal implementation
> issue, and not really an interface".
I.E. a statement of intent that this sy
On 2015/5/28 20:27, Jan Beulich wrote:
On 22.05.15 at 11:35, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -898,6 +898,36 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long
gfn, mfn_t mfn,
return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct, access);
}
On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez wrote:
> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
>> > On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
>> > >
>> > > I tentatively put this
On Thu, May 28, 2015 at 10:56:19PM +0100, Al Viro wrote:
> On Thu, May 28, 2015 at 11:17:36PM +0200, Luis R. Rodriguez wrote:
> > > ... while some of us consider that as pointless posturing and will refuse
> > > to merge such exports regardless.
> >
> > Can you elaborate why, for those maintainers
flight 57436 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57436/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
flight 57427 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57427/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
test-amd64-i386-xl-qemuu-win
On Thu, May 28, 2015 at 11:17:36PM +0200, Luis R. Rodriguez wrote:
> > ... while some of us consider that as pointless posturing and will refuse
> > to merge such exports regardless.
>
> Can you elaborate why, for those maintainers not aware of such positions?
*shrug*
Either one states that all
On Thu, May 21, 2015 at 11:32 AM, Luis R. Rodriguez wrote:
> On Thu, May 21, 2015 at 04:20:27PM +0800, Michal Marek wrote:
>> Dne 21.5.2015 v 02:53 Luis R. Rodriguez napsal(a):
>> > From: "Luis R. Rodriguez"
>> >
>> > Michal Marek, Xen folks (David Vrabel, Konrad, Ian), which tree should
>> > the
On Thu, May 28, 2015 at 09:07:49PM +0100, Al Viro wrote:
> On Thu, May 28, 2015 at 11:56:01AM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > Current documentation over use case for EXPORT_SYMBOL_GPL()
> > only acknowledges functions which are "an internal implementation
> >
flight 57444 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57444/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 53854
test-amd64-amd64-libvirt
Change frontswap single pointer to a singly linked list of frontswap
implementations. Update Xen tmem implementation as register no longer
returns anything.
Frontswap only keeps track of a single implementation; any implementation
that registers second (or later) will replace the previously regis
On Thu, May 28, 2015 at 11:56:01AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Current documentation over use case for EXPORT_SYMBOL_GPL()
> only acknowledges functions which are "an internal implementation
> issue, and not really an interface". In practice these days
> though
On Thu, May 28, 2015 at 01:09:23PM -0600, Jonathan Corbet wrote:
> On Thu, 28 May 2015 11:56:01 -0700
> "Luis R. Rodriguez" wrote:
>
> > +Some maintainers and developers may however have a preference to
> > +require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality.
>
> As a
flight 57420 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken in 57345 REGR. vs. 57312
test-amd64-i386-xl-qem
From: "Luis R. Rodriguez"
Current documentation over use case for EXPORT_SYMBOL_GPL()
only acknowledges functions which are "an internal implementation
issue, and not really an interface". In practice these days
though we have some maintainers taking on preferences to require
all new functionalit
On 05/28/2015 05:10 AM, Michal Privoznik wrote:
On 09.05.2015 00:31, Jim Fehlig wrote:
This series provides support for SPICE graphics in the libxl driver.
The first patch is mostly code movement. The second patch is a trivial
name change of a structure member. Patch3 populates the
libxl_domai
flight 57419 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57419/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 56375
test-amd64-i386-freebsd10-amd
On 05/28/2015 07:06 PM, Lengyel, Tamas wrote:
>
>
> On Thu, May 28, 2015 at 10:33 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> On 05/28/2015 05:12 PM, Lengyel, Tamas wrote:
> > diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
> > index 9
Koushik Chakravarty writes ("[tools/libxl]: Possible bug in ao_cancel"):
> I spotted a possible bug in ao_cancel (libxl_event.c) and wanted to run it
> through you.
Hi, sure. (Sorry for the delay replying, I have been away. And I'm
going away again for the whole of next week...)
> In the ao_ca
On 28/05/15 15:55, Jan Beulich wrote:
On 26.05.15 at 20:00, wrote:
>> @@ -254,23 +254,23 @@ double_gt_lock(struct grant_table *lgt, struct
>> grant_table *rgt)
>> {
>> if ( lgt < rgt )
>> {
>> -spin_lock(&lgt->lock);
>> -spin_lock(&rgt->lock);
>> +write_loc
On 28/05/15 16:39, Jan Beulich wrote:
On 26.05.15 at 20:00, wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -57,7 +57,7 @@ integer_param("gnttab_max_frames", max_grant_frames);
>> * New options allow to set max_maptrack_frames and
>> * map_grant_table_fram
On Thu, May 28, 2015 at 10:33 AM, Razvan Cojocaru wrote:
> On 05/28/2015 05:12 PM, Lengyel, Tamas wrote:
> > diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
> > index 9d5f9f3..a13195d 100644
> > --- a/xen/arch/x86/hvm/event.c
> > +++ b/xen/arch/x86/hvm/event.c
> >
On 28.05.2015 17:45, Jim Fehlig wrote:
>
>
>> On May 28, 2015, at 4:07 AM, Michal Privoznik wrote:
>>
>>> On 09.05.2015 00:31, Jim Fehlig wrote:
>>> Signed-off-by: Jim Fehlig
>>> ---
>>> src/libxl/libxl_conf.c | 72
>>> +-
>>> 1 file changed, 66 i
> On May 28, 2015, at 4:07 AM, Michal Privoznik wrote:
>
>> On 09.05.2015 00:31, Jim Fehlig wrote:
>> Signed-off-by: Jim Fehlig
>> ---
>> src/libxl/libxl_conf.c | 72
>> +-
>> 1 file changed, 66 insertions(+), 6 deletions(-)
>>
>> diff --git a/s
On Thu, May 28, 2015 at 08:57:16AM +0100, Jan Beulich wrote:
> >>> On 27.05.15 at 21:56, wrote:
> > On Tue, May 26, 2015 at 10:46:30AM +0100, Jan Beulich wrote:
> >> >>> On 23.05.15 at 03:27, wrote:
> >> > @@ -658,6 +661,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
> >> >
>>> On 26.05.15 at 20:00, wrote:
> v10:
> - Divide max_maptrack_frames evenly amongst the VCPUs.
> - Increase default max_maptrack_frames to compensate.
I'm not really happy about this, but also can't immediately suggest
a better model (without removing maptrack frames from vCPU-s). I'd
really li
On 05/28/2015 11:05 AM, Aravind Gopalakrishnan wrote:
On 5/26/2015 1:09 PM, Boris Ostrovsky wrote:
On 05/26/2015 12:24 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, wrote:
@@ -188,27 +189,52 @@ static inline void context_load(struct vcpu *v)
}
}
-static void amd_vpmu_load(struct vcpu
On 5/26/2015 1:09 PM, Boris Ostrovsky wrote:
On 05/26/2015 12:24 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, wrote:
@@ -188,27 +189,52 @@ static inline void context_load(struct vcpu *v)
}
}
-static void amd_vpmu_load(struct vcpu *v)
+static int amd_vpmu_load(struct vcpu *v, bool_t f
>>> On 28.05.15 at 15:53, wrote:
> Tim Deegan writes:
>> BTW having looked at how messy this is ending up, and how it's still
>> incomplete, I'd agree with Jan that resetting the domain state might
>> be a better approach.
>
> Even with the 'reset-everything' approach the function from this patc
>>> On 26.05.15 at 20:00, wrote:
> @@ -254,23 +254,23 @@ double_gt_lock(struct grant_table *lgt, struct
> grant_table *rgt)
> {
> if ( lgt < rgt )
> {
> -spin_lock(&lgt->lock);
> -spin_lock(&rgt->lock);
> +write_lock(&lgt->lock);
> +write_lock(&rgt->lock
On 05/28/2015 05:12 PM, Lengyel, Tamas wrote:
> diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
> index 9d5f9f3..a13195d 100644
> --- a/xen/arch/x86/hvm/event.c
> +++ b/xen/arch/x86/hvm/event.c
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#inc
flight 57411 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57411/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail REGR. vs.
56796
Regressions wh
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
> index 9d5f9f3..a13195d 100644
> --- a/xen/arch/x86/hvm/event.c
> +++ b/xen/arch/x86/hvm/event.c
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#include
> #include
>
> static void hvm_event_fill_regs(vm_event_request_t *req)
Tim Deegan writes:
> At 15:11 +0200 on 28 May (1432825919), Vitaly Kuznetsov wrote:
>> Tim Deegan writes:
>> > At 13:56 +0200 on 28 May (1432821360), Vitaly Kuznetsov wrote:
>> >> Tim Deegan writes:
>> >> >> +while ( next_page && !is_xen_heap_page(next_page) &&
>> >> >> +
>>> On 26.05.15 at 20:00, wrote:
> Split grant table lock into two separate locks. One to protect
> maptrack state (maptrack_lock) and one for everything else (lock).
>
> Based on a patch originally by Matt Wilson .
>
> Signed-off-by: David Vrabel
Reviewed-by: Jan Beulich
__
>>> On 26.05.15 at 20:00, wrote:
> @@ -514,18 +534,19 @@ static int grant_map_exists(const struct domain *ld,
> nr_grant_entries(rgt));
> for ( ref = *ref_count; ref < max_iter; ref++ )
> {
> -act = &active_entry(rgt, ref);
> +struct active_grant_entry
"Jan Beulich" writes:
On 28.05.15 at 14:27, wrote:
>> "Jan Beulich" writes:
>>
>> On 27.05.15 at 17:25, wrote:
This patch series provides x86 PVHVM domains with an ability to perform
kexec/kdump-style operations.
>>>
>>> Before I get to look at this latest version, may I go
At 15:11 +0200 on 28 May (1432825919), Vitaly Kuznetsov wrote:
> Tim Deegan writes:
> > At 13:56 +0200 on 28 May (1432821360), Vitaly Kuznetsov wrote:
> >> Tim Deegan writes:
> >> >> +while ( next_page && !is_xen_heap_page(next_page) &&
> >> >> +page_to_mfn(next_page) == m
>>> On 21.05.15 at 10:41, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -216,6 +216,38 @@ void psr_ctxt_switch_to(struct domain *d)
> }
> }
>
> +static int get_cat_socket_info(unsigned int socket,
> + struct psr_cat_socket_info **info)
> +{
>>> On 21.05.15 at 10:41, wrote:
> For each socket, a COS to CBM mapping structure is maintained for each
> COS. The mapping is indexed by COS and the value is the corresponding
> CBM. Different VMs may use the same CBM, a reference count is used to
> indicate if the CBM is available.
>
> Signed-
Tim Deegan writes:
> At 13:56 +0200 on 28 May (1432821360), Vitaly Kuznetsov wrote:
>> Tim Deegan writes:
>> >> +last_gmfn = domain_get_maximum_gpfn(source_d);
>> >> +gmfn = *gmfn_start;
>> >> +while ( gmfn <= last_gmfn )
>> >> +{
>> >> +page = get_page_from_gfn(source_d,
>>> On 28.05.15 at 14:27, wrote:
> "Jan Beulich" writes:
>
> On 27.05.15 at 17:25, wrote:
>>> This patch series provides x86 PVHVM domains with an ability to perform
>>> kexec/kdump-style operations.
>>
>> Before I get to look at this latest version, may I go a step back and
>> ask for clar
>>> On 21.05.15 at 10:41, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -19,14 +19,25 @@
> #include
>
> #define PSR_CMT(1<<0)
> +#define PSR_CAT(1<<1)
> +
> +struct psr_cat_socket_info {
> +unsigned int cbm_len;
> +unsigned int cos_max;
> +};
>
>
At 13:56 +0200 on 28 May (1432821360), Vitaly Kuznetsov wrote:
> Tim Deegan writes:
> >> +last_gmfn = domain_get_maximum_gpfn(source_d);
> >> +gmfn = *gmfn_start;
> >> +while ( gmfn <= last_gmfn )
> >> +{
> >> +page = get_page_from_gfn(source_d, gmfn, &p2mt, 0);
> >
> > In
On 28/05/15 13:25, Tim Deegan wrote:
> At 12:34 +0100 on 28 May (1432816489), Andrew Cooper wrote:
>> Memory management is hard[citation needed]. Furthermore, it isn't helped by
>> the inconsistent use of terms through the code, or that some terms have
>> changed meaning over time.
>>
>> Describe
>>> On 21.05.15 at 10:41, wrote:
> --- a/xen/arch/x86/mpparse.c
> +++ b/xen/arch/x86/mpparse.c
> @@ -87,6 +87,18 @@ void __init set_nr_cpu_ids(unsigned int max_cpus)
> #endif
> }
>
> +void __init set_nr_sockets(void)
> +{
> +unsigned int cpus = bitmap_weight(phys_cpu_present_map.mask,
> +
flight 57409 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-winxpsp3 16 guest-stop fail REGR. vs. 53018
test-amd64-i386-x
>>> On 22.05.15 at 11:35, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -898,6 +898,36 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long
> gfn, mfn_t mfn,
> return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct, access);
> }
>
> +int set_identity_p2m_en
"Jan Beulich" writes:
On 27.05.15 at 17:25, wrote:
>> This patch series provides x86 PVHVM domains with an ability to perform
>> kexec/kdump-style operations.
>
> Before I get to look at this latest version, may I go a step back and
> ask for clarification whether all of these (seemingly fr
At 12:34 +0100 on 28 May (1432816489), Andrew Cooper wrote:
> Memory management is hard[citation needed]. Furthermore, it isn't helped by
> the inconsistent use of terms through the code, or that some terms have
> changed meaning over time.
>
> Describe the currently-used terms in a more practica
>>> On 28.05.15 at 14:12, wrote:
> On Thu, 28 May 2015, Jan Beulich wrote:
>> >>> On 28.05.15 at 12:58, wrote:
>> > Let's take a closer look at this table. After the boilierplate, these
>> > are the interesting fields:
>> >
>> > GNT Start, GNT Size
>> > Evtchn Intr, Evtchn Intr Flags
>> >
>> >
>>> On 27.05.15 at 17:25, wrote:
> This patch series provides x86 PVHVM domains with an ability to perform
> kexec/kdump-style operations.
Before I get to look at this latest version, may I go a step back and
ask for clarification whether all of these (seemingly fragile)
manipulations are actuall
On Thu, 28 May 2015, Jan Beulich wrote:
> >>> On 28.05.15 at 12:58, wrote:
> > Let's take a closer look at this table. After the boilierplate, these
> > are the interesting fields:
> >
> > GNT Start, GNT Size
> > Evtchn Intr, Evtchn Intr Flags
> >
> > After the table, it is clearly stated:
> >
>>> On 28.05.15 at 12:56, wrote:
> On 05/28/2015 11:39 AM, Jan Beulich wrote:
> On 28.05.15 at 07:33, wrote:
>>> Changes since V6:
>>> - Removed "Reviewed-by: Tim Deegan ", as the patch
>>>went beyond cosmetic-only changes.
>>> - Parenthesized hvm_event_cr in event.c, to prevent expansi
>>> On 28.05.15 at 12:58, wrote:
> Let's take a closer look at this table. After the boilierplate, these
> are the interesting fields:
>
> GNT Start, GNT Size
> Evtchn Intr, Evtchn Intr Flags
>
> After the table, it is clearly stated:
>
> "The Grant Table region is optional."
>
> and
>
> "The
Tim Deegan writes:
> Hi,
>
> At 17:25 +0200 on 27 May (1432747540), Vitaly Kuznetsov wrote:
>> New operation reassigns all memory pages from source domain to the
>> destination
>> domain mapping them at exactly the same GFNs. Pages mapped more than once
>> (e.g.
>> grants) are being copied.
>>
Memory management is hard[citation needed]. Furthermore, it isn't helped by
the inconsistent use of terms through the code, or that some terms have
changed meaning over time.
Describe the currently-used terms in a more practical fashon, so new code has
a concrete reference.
Signed-off-by: Andrew
On Thu, 2015-05-28 at 10:03 +0100, Jan Beulich wrote:
> Could one or both of you confirm that this as well as the other patch
> it was originally paired with ("cpupool: assigning a CPU to a pool can
> fail") ought to be backported (presumably to both 4.5 and 4.4)
> please?
>
Right, I was about to
On 09.05.2015 00:31, Jim Fehlig wrote:
> This series provides support for SPICE graphics in the libxl driver.
> The first patch is mostly code movement. The second patch is a trivial
> name change of a structure member. Patch3 populates the
> libxl_domain_build_info struct with SPICE info. SPICE
On Wed, 27 May 2015, Jan Beulich wrote:
> >>> On 26.05.15 at 19:34, wrote:
> > On Thu, 21 May 2015, Jan Beulich wrote:
> >> >>> On 21.05.15 at 12:34, wrote:
> >> > ACPI 6.0 has been released few months after Parth and Naresh began to
> >> > implement ACPI for Xen. We could take advantage of this
On 05/28/2015 11:39 AM, Jan Beulich wrote:
On 28.05.15 at 07:33, wrote:
>> Changes since V6:
>> - Removed "Reviewed-by: Tim Deegan ", as the patch
>>went beyond cosmetic-only changes.
>> - Parenthesized hvm_event_cr in event.c, to prevent expansion of
>>the macro with the same name
This is a note to let you know that I have just added a patch titled
config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected
to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=
On Wed, 2015-05-20 at 18:56 +0100, Wei Liu wrote:
> I worked a little bit on upgrading Osstest to Jessie a few months ago but
> dropped the ball. Here are the patches I wrote.
With the recent change to support submenus I find I now need the below,
I think update-grub on Jessie must include some so
On Thu, 2015-05-28 at 04:49 +, osstest service user wrote:
> flight 57401 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/57401/
>
> Failures :-/ but no regressions.
Lontao, Robert,
The grub related bits of the nested series are now in the production
osstest instance.
On 28/05/15 11:15, Chen Baozi wrote:
> From: Chen Baozi
>
> When a guest uses vGICv2, the maximum number of vCPU it can support
> should not be as many as MAX_VIRT_CPUS, which is 128 at the moment.
> So the domain_max_vcpus should return the value according to the vGIC
> version the domain uses.
>
From: Chen Baozi
Use cpumask_t instead of unsigned long which can only express 64 cpus at
the most. Add the {gicv2|gicv3}_sgir_to_cpumask in corresponding vGICs
to translate GICD_SGIR/ICC_SGI1R_EL1 to vcpu_mask for vgic_to_sgi.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v2.c | 16
From: Chen Baozi
When a guest uses vGICv2, the maximum number of vCPU it can support
should not be as many as MAX_VIRT_CPUS, which is 128 at the moment.
So the domain_max_vcpus should return the value according to the vGIC
version the domain uses.
We didn't keep it as the old static inline form
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused.
Current implementation considers that AFF0 is equal to vCPUID, which
makes all vCPUs in one cluster, limiting its number to 16. If we would
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC-
From: Chen Baozi
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on arm64.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v3.c | 1 -
xen/include/asm-arm/config.h | 4
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
Signed-off-by: Chen Baozi
--
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
tools/libxl/libxl_arm.c |
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
xen/arch/arm/domain_build
>>> On 28.05.15 at 11:26, wrote:
> On Thu, 2015-05-28 at 09:50 +0100, Jan Beulich wrote:
>> >>> On 27.05.15 at 18:04, wrote:
>> > On Tue, 2015-05-26 at 14:29 +0100, Ian Campbell wrote:
>> >> I've now managed to reproduce using the arndale on my desk.
>> >
>> > ... and now I've confirmed that rev
On 09.05.2015 00:31, Jim Fehlig wrote:
> Signed-off-by: Jim Fehlig
> ---
> src/libxl/libxl_conf.c | 72
> +-
> 1 file changed, 66 insertions(+), 6 deletions(-)
>
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index 8552c77..5bb04
Hi,
At 17:25 +0200 on 27 May (1432747540), Vitaly Kuznetsov wrote:
> New operation reassigns all memory pages from source domain to the destination
> domain mapping them at exactly the same GFNs. Pages mapped more than once
> (e.g.
> grants) are being copied.
>
> Signed-off-by: Vitaly Kuznetsov
flight 57443 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
>>> On 28.05.15 at 11:47, wrote:
> On 26/05/2015 21:00, Jan Beulich wrote
>> >>> On 13.05.16 at 09:50, wrote:
>> > --- a/xen/include/acpi/cpufreq/cpufreq.h
>> > +++ b/xen/include/acpi/cpufreq/cpufreq.h
>> > @@ -52,6 +52,10 @@ struct cpufreq_policy {
>> > unsigned intmax;/* in kHz
At 17:49 +0100 on 27 May (1432748951), Andrew Cooper wrote:
> RFC: All changes here are subject to my current understanding, which might be
> wrong
>
> Memory management is hard[citation needed]. Furthermore, it isn't helped by
> the inconsistent use of terms through the code.
>
> Describe the
>>> On 28.05.15 at 11:38, wrote:
> I had one total crash/reboot of Xen with pvops domU kernel 3.18.13.
> Somehow it looked like that domU was able to crash the whole hypervisor.
> Perhaps somebody has time to spend more time on investigating.
Seems unlikely without you giving any details.
Neve
On 26/05/2015 21:00, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > --- a/xen/drivers/cpufreq/utility.c
> > +++ b/xen/drivers/cpufreq/utility.c
> > @@ -456,6 +456,11 @@ int __cpufreq_set_policy(struct cpufreq_policy
> > *data,
> >
> > data->min = policy->min;
> > data->max = po
>>> On 28.05.15 at 11:26, wrote:
> On 26/05/2015 20:51, Jan Beulich wrote
>> >>> On 13.05.16 at 09:50, wrote:
>> > The unregister notifier function is needed to support cpu hotplug.
>>
>> Without loadable module support I have some difficulty seeing why this
>> should be needed.
>>
>
> Ok. The
I am currently validating 4.5.1-rc1 as a stable platform for production
environments. I perform a series of tests which stress the IO subsystems
(net+disk) to the max. For block IO I reach more than 1.5 gigabytes/sec.
The tests also hash (SHA1) all IO and verify it against known values so
I can
On Thu, 2015-05-28 at 09:50 +0100, Jan Beulich wrote:
> >>> On 27.05.15 at 18:04, wrote:
> > On Tue, 2015-05-26 at 14:29 +0100, Ian Campbell wrote:
> >> On Wed, 2015-05-20 at 10:56 +0100, Ian Campbell wrote:
> >> > On Wed, 2015-05-20 at 09:34 +, osstest service user wrote:
> >> > > flight 5675
On 26/05/2015 20:51, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > The unregister notifier function is needed to support cpu hotplug.
>
> Without loadable module support I have some difficulty seeing why this
> should be needed.
>
Ok. Then, should we remove the entire cpufreq_unregis
Hi Andrew,
On Thu, May 28, 2015 at 09:50:38AM +0100, Andrew Cooper wrote:
> On 28/05/15 08:44, Chen Baozi wrote:
> > From: Chen Baozi
> >
> > Since the maximum vcpu information is already saved in the struct domain,
> > there is no need for domain_max_vpus to return the fixed value.
> >
> > Signe
1 - 100 of 118 matches
Mail list logo
