I am creating an Arch Linux AUR package for Xen 4.5 RC4. As this
doesn't exist and I am playing around with a xen server. Hopefully
I'll be done in time for the test day. (AUR is a package repository
for build scripts that make packages for the Arch Linux package
manager). The idea is to have somet
On Tue, Dec 16, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> > On Tue, Dec 16, konrad.w...@oracle.com wrote:
> >
> > > In terms of bugs, we have:
> >
> > ... systemd SELinux, but its not listed.
>
> >
> > Whats your plan with the failures you se
flight 32418 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32418/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32194
Tests which did not succeed,
On 16/12/2014 23:26, Andrew Cooper wrote:
On 16/12/2014 23:06, Julien Grall wrote:
Hi,
On 16/12/2014 20:28, Andrew Cooper wrote:
I suspect you also would be better, and certainly more brief, with
"run_in_exception_handler(show_stack)" instead, which will just print a
stack trace, but nothing
On 16/12/2014 23:06, Julien Grall wrote:
> Hi,
>
> On 16/12/2014 20:28, Andrew Cooper wrote:
>> I suspect you also would be better, and certainly more brief, with
>> "run_in_exception_handler(show_stack)" instead, which will just print a
>> stack trace, but nothing more.
>
> FIY, run_in_exception_h
Hi,
On 16/12/2014 20:28, Andrew Cooper wrote:
I suspect you also would be better, and certainly more brief, with
"run_in_exception_handler(show_stack)" instead, which will just print a
stack trace, but nothing more.
FIY, run_in_exception_handler doesn't exists on ARM.
Regards,
--
Julien Gral
On Dec 15, 2014, at 6:11 AM, David Vrabel wrote:
> On 11/12/14 15:12, Christopher S. Aker wrote:
>> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
>> Dom0: 3.17.4
>>
>> Things go badly after a day or four. We've hit this on a number of
>> previously healthy hosts, since moving fro
On Tue, Dec 16, 2014 at 10:04:25PM +, M A Young wrote:
> On Tue, 16 Dec 2014, Wei Liu wrote:
>
> >On Tue, Dec 16, 2014 at 08:38:42PM +, M A Young wrote:
> >[...]
> >>Is this patch going to get committed in time for xen 4.5?
> >>
> >
> >Yes. See d36a3734a6.
> >
> >And there's a subsequence
On Tue, 16 Dec 2014, Wei Liu wrote:
On Tue, Dec 16, 2014 at 08:38:42PM +, M A Young wrote:
[...]
Is this patch going to get committed in time for xen 4.5?
Yes. See d36a3734a6.
And there's a subsequence patch to fix a regression caused by that
patch. See 09b7ff1a.
Wei.
No that is the
On Tue, Dec 16, 2014 at 08:38:42PM +, M A Young wrote:
[...]
> Is this patch going to get committed in time for xen 4.5?
>
Yes. See d36a3734a6.
And there's a subsequence patch to fix a regression caused by that
patch. See 09b7ff1a.
Wei.
> Michael Young
__
On Tue, Dec 16, 2014 at 05:43:08PM +, Andrew Cooper wrote:
> On 16/12/14 16:13, konrad.w...@oracle.com wrote:
> > Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> > we have the General Release on Jan 7th!
> >
> > Details for the test-day are at
> >
> > http://wiki.xen.or
On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> On Tue, Dec 16, konrad.w...@oracle.com wrote:
>
> > In terms of bugs, we have:
>
> ... systemd SELinux, but its not listed.
>
> Whats your plan with the failures you see? Should I continue to be
> concerned about that, or will all t
flight 32412 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail REGR. vs. 31241
test-amd64-amd64-xl
On Mon, 1 Dec 2014, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 28, 2014 at 12:09:41PM +, Ian Campbell wrote:
On Wed, 2014-11-26 at 21:19 +, Andrew Cooper wrote:
On 26/11/2014 19:54, M A Young wrote:
If differences are found during the verification phase of xl migrate
--debug then it is
On 16/12/14 19:33, Mihai Donțu wrote:
> Implemented xmem_pool_check(), xmem_pool_check_locked() and
> xmem_pool_check_unlocked() to verity the integrity of the TLSF matrix.
>
> Signed-off-by: Mihai Donțu
>
> ---
> Changes since v3:
> - try harder to respect the 80 column limit
> - use 'unsigned
From: David Vrabel
Date: Tue, 16 Dec 2014 18:59:46 +
> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
> masking in NAPI) the napi instance is removed from the per-cpu list
> prior to calling the n->poll(), and is only requeued if all of the
> budget was used. This inadve
On ARM, the way to assign device tree node is exactly the same as PCI.
Futhermore, all devices can be represented by a "struct device'.
Therefore there is no need to add separate ops.
Signed-off-by: Julien Grall
CC: Suravee Suthikulpanit
CC: Aravind Gopalakrishnan
CC: Jan Beulich
CC: Yang Zhan
Xen is currently using list a compatible string to know if the driver
can use device node. This leads to have double definition in the GIC
code.
Futhermore Linux drivers is using dt_match_node (actually called of_device_id
in Linux) to list device supported by the drivers.
Signed-off-by: Julien G
The current SMMU driver has completly diverged. That makes me hard to
maintain.
Signed-off-by: Julien Grall
---
xen/drivers/passthrough/arm/Makefile |1 -
xen/drivers/passthrough/arm/smmu.c | 1784 --
2 files changed, 1785 deletions(-)
delete mode 100644 xe
From: Andreas Herrmann
Try to determine mask/id values that match several stream IDs of a
master device when doing Stream ID matching. Thus the number of used
SMR groups that are required to map all stream IDs of a master device
to a context should be less than the number of SMR groups used so fa
The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.
To achieve that we:
- Add helpers to Linux function not implemented on Xen
- Add callbacks used by Xen to do our own stuff and call Linux ones
- Only modify whe
Currently, Xen is supporting PCI and Platform device (based on Device Tree).
While we don't support both at the same time: platform device for ARM
and PCI for x86, ARM will gain support on PCI soon.
Some drivers, such as IOMMU drivers, may handle PCI and platform device in
the same way. Only few
This macro can be used in drivers imported from Linux.
Signed-off-by: Julien Grall
CC: Ian Jackson
CC: Jan Beulich
CC: Keir Fraser
---
xen/include/xen/compiler.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 4
I'm not sure why a ':' has been added in the name... But none of the
other usages doesn't have it.
Signed-off-by: Julien Grall
---
xen/arch/arm/gic-v2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..f149e09 100644
Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.
It's a basic copy of the Linux SMMU drivers code. No Xen code has yet been added
and not build.
Compare to the previous drivers it gains support of PCI. Though it will
need a bit of plumbing for Xen.
Signed-of-by: Julien Grall
---
xen/d
Hello,
The SMMU drivers has diverged from Linux. Having our own driver doesn't make
any benefits and make difficult to backport fixes and/or porting features such
as PCI.
With this series, the core of the SMMU drivers (i.e copied from Linux) is mostly
not modified. If it's the case a comment /* X
The header asm/device.h has been included in the vgic code during
splitting to support multiple version. But no code within those files
requires it.
Signed-off-by: Julien Grall
---
xen/arch/arm/vgic-v2.c | 1 -
xen/arch/arm/vgic-v3.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/xen/arch/
From: Andreas Herrmann
If DT information lists one stream ID twice for the master devices of
an SMMU this can cause a multi match when stream ID matching is used.
For stream ID indexing this might trigger an overwrite of an S2CR that
is already in use.
So better check for duplicates when DT info
This enum was used for matching a specific device and not to get the
type of device.
Hence the name device_type will be used for another purpose later.
Signed-off-by: Julien Grall
---
xen/arch/arm/device.c| 4 ++--
xen/include/asm-arm/device.h | 8
2 files changed, 6 insertions
Some drivers may want to configure differently the device depending on
the compatible string.
Also modify the return type of dt_match_node to return the matching
structure.
Signed-off-by: Julien Grall
---
xen/arch/arm/platform.c | 2 +-
xen/common/device_tree.c | 12 ++--
xe
Implemented xmem_pool_check(), xmem_pool_check_locked() and
xmem_pool_check_unlocked() to verity the integrity of the TLSF matrix.
Signed-off-by: Mihai Donțu
---
Changes since v3:
- try harder to respect the 80 column limit
- use 'unsigned int' instead of 'int' where possible
- made the logge
After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
masking in NAPI) the napi instance is removed from the per-cpu list
prior to calling the n->poll(), and is only requeued if all of the
budget was used. This inadvertently broke netfront because netfront
does not use NAPI correctly
On 16/12/14 17:34, Roger Pau Monné wrote:
> Hello,
>
> While working on the FreeBSD PVH Dom0 port I've realized that IO-APIC
> interrupts get stuck in a very strange state very easily with the
> current PIRQ implementation that I'm using on FreeBSD.
>
> Since I'm not sure what is going on, I woul
flight 32392 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32392/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf-pin 5 xen-boot fail like 32361
Tests which did not succeed,
On 16/12/14 16:13, konrad.w...@oracle.com wrote:
> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> we have the General Release on Jan 7th!
>
> Details for the test-day are at
>
> http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
>
> In terms of bugs, we have:
>From th
Hello,
While working on the FreeBSD PVH Dom0 port I've realized that IO-APIC
interrupts get stuck in a very strange state very easily with the
current PIRQ implementation that I'm using on FreeBSD.
Since I'm not sure what is going on, I would like to ask for some
feedback and possible solution
On Mon, 2014-12-15 at 16:47 +, George Dunlap wrote:
> On Wed, Dec 10, 2014 at 4:30 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Tue, Dec 09, 2014 at 02:48:21PM +, Ian Campbell wrote:
> >> On Tue, 2014-12-09 at 14:04 +, George Dunlap wrote:
> >> > At the moment libxl unconditinally passes
On Fri, 2014-12-12 at 18:26 +, Andrew Cooper wrote:
> `font` had a trailing single quote which was out of place.
>
> `gnttab_max_frames` was missing escapes for the underscores which caused the
> underscores to take their markdown meaning, causing 'max' in the middle to be
> italicised. Escap
On Mon, 2014-12-15 at 11:06 +, Ian Campbell wrote:
> > Release-Acked-by: Konrad Wilk
>
> Acked-by: Ian Campbell
Applied.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, 2014-12-10 at 12:13 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 09, 2014 at 04:43:22PM +, Andrew Cooper wrote:
> > The error handling from a failed memory allocation should return
> > PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and
> > continuing
> > to the me
On Tue, 2014-12-09 at 11:26 -0500, Konrad Rzeszutek Wilk wrote:
> > I'm fully happy with proposed wording (and want the both bits to be used)
Done and committed.
> >
> > > Konrad, this is a bug fix for a particular piece of hardware, it can't
> > > affect anything other than the OMAP ARM platfo
flight 32414 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32414/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start
flight 32390 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32390/
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
Tests which are failin
2014-12-16 16:23 GMT+00:00 Ian Campbell :
> On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote:
>> What does "info all-registers" gdb command say about SSE registers?
>
> All zeroes. No ffs anywhere.
>
Could be that core does not dump these registers for some reasons? On
my machine I got som
On Tue, Dec 16, konrad.w...@oracle.com wrote:
> In terms of bugs, we have:
... systemd SELinux, but its not listed.
Whats your plan with the failures you see? Should I continue to be
concerned about that, or will all the be postponed to 4.6?
Olaf
___
On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote:
> What does "info all-registers" gdb command say about SSE registers?
All zeroes. No ffs anywhere.
> Do we have a bug in Xen that affect SSE instructions (possibly already
> fixed after Philipp version) ?
Possibly. When this was thought t
Hi,
This is a design proposal for a rework of the config options on the
Linux kernel which are related to Xen.
The need to do so arose from the fact that it is currently not
possible to build the Xen frontend drivers for a non-pvops kernel,
e.g. to run them in a HVM-domain. There are more drawba
Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
we have the General Release on Jan 7th!
Details for the test-day are at
http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
In terms of bugs, we have:
#11 qxl hypervisor support
#13 Re: [Xen-devel] man page example: xm bl
2014-12-16 12:23 GMT+00:00 Ian Campbell :
> On Tue, 2014-12-16 at 11:30 +, Frediano Ziglio wrote:
>> 2014-12-16 11:06 GMT+00:00 Ian Campbell :
>> > On Tue, 2014-12-16 at 10:45 +, Ian Campbell wrote:
>> >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>> >> > > I notice in your bugz
flight 32413 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32413/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen 2c9e812bc368cb68a6249b99b1fb51ef3299d81c
baseline version:
rumpuserxen d40acc2019bd352e1de13842459b
On 12/16/2014 04:31 AM, Jan Beulich wrote:
On 15.12.14 at 23:24, wrote:
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.
We have to do this via IPI since otherwise there is a (som
On 15/12/14 11:47, Jan Beulich wrote:
On 15.12.14 at 12:38, wrote:
>> On 11/12/14 18:04, Juergen Gross wrote:
>>> --- a/arch/x86/syscalls/Makefile
>>> +++ b/arch/x86/syscalls/Makefile
>>
>> Why are these changes here and not in arch/x86/xen/Makefile?
>
> Because this needs to be done in a st
On 12/15/2014 12:38 PM, David Vrabel wrote:
On 11/12/14 18:04, Juergen Gross wrote:
Today there are several places in the kernel which build tables
containing one entry for each possible Xen hypercall. Create an
infrastructure to be able to generate these tables at build time.
Does arm and arm
flight 32391 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32391/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl5 xen-boot fail REGR. vs. 32348
test-armhf-armhf-xl
I am running Ubuntu's xen 4.4 (4.4.1-0ubuntu0.14.04.2), but creating VMs
with libxl.
When I do a 'shutdown -r' or similar with no VMs running, dom0 reboots
fine. When I do this with one or more VMs running, I get:
"INFO: task reboot:11897 blocked for more than 120 seconds."
repeatedly, and the m
On Tue, 2014-12-16 at 12:36 +, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console
> on domain startup."):
> > On Tue, Dec 16, 2014 at 09:30:28AM +, Ian Campbell wrote:
> > > Unless by "not running" you meant bottlenecked or not keeping up
> >
Ian Jackson writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console on
domain startup."):
> I mention all of these for completeness, and for future reference for
> anyone reading the archives later.
>
> In libxl you want option I.
I mean `in xl you want option I'. In libvirt you probably
Anthony PERARD writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console
on domain startup."):
> On Tue, Dec 16, 2014 at 09:30:28AM +, Ian Campbell wrote:
> > Unless by "not running" you meant bottlenecked or not keeping up
> > perhaps.
>
> Well, I did meant no xenconsoled process. But a
On Tue, 2014-12-16 at 11:30 +, Frediano Ziglio wrote:
> 2014-12-16 11:06 GMT+00:00 Ian Campbell :
> > On Tue, 2014-12-16 at 10:45 +, Ian Campbell wrote:
> >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> >> > > I notice in your bugzilla (for a different occurrence, I think):
> >>
Hello,
On 16.12.2014 11:45, Ian Campbell wrote:
> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>>> I notice in your bugzilla (for a different occurrence, I think):
[2090451.721705] univention-conf[2512]: segfault at ff ip
0045e238 sp 768dfa30 error 6 in
On Tue, Dec 16, 2014 at 09:30:28AM +, Ian Campbell wrote:
> On Mon, 2014-12-15 at 17:07 +, Anthony PERARD wrote:
> > On Thu, Dec 11, 2014 at 04:23:15PM +, Ian Campbell wrote:
> > > On Thu, 2014-12-11 at 16:16 +, Anthony PERARD wrote:
> > > > On Tue, Dec 09, 2014 at 03:56:02PM +,
2014-12-16 11:06 GMT+00:00 Ian Campbell :
> On Tue, 2014-12-16 at 10:45 +, Ian Campbell wrote:
>> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>> > > I notice in your bugzilla (for a different occurrence, I think):
>> > >> [2090451.721705] univention-conf[2512]: segfault at ff
On 12/16/2014 11:24 AM, David Vrabel wrote:
On 16/12/14 05:55, Juergen Gross wrote:
On 12/15/2014 01:05 PM, David Vrabel wrote:
On 11/12/14 18:04, Juergen Gross wrote:
Instead of manually list each hypercall in arch/x86/xen/xen-head.S
use the auto generated symbol list.
This also corrects the
On Tue, 2014-12-16 at 10:45 +, Ian Campbell wrote:
> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> > > I notice in your bugzilla (for a different occurrence, I think):
> > >> [2090451.721705] univention-conf[2512]: segfault at ff ip
> > >> 0045e238 sp 768dfa3
On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> > I notice in your bugzilla (for a different occurrence, I think):
> >> [2090451.721705] univention-conf[2512]: segfault at ff ip
> >> 0045e238 sp 768dfa30 error 6 in python2.6[40+21e000]
> >
> > Which appears to
El 16/12/14 a les 11.11, Bob Liu ha escrit:
> The default maximum value of segments in indirect requests was 32, IO
> operations with bigger block size(>32*4k) would be split and performance start
> to drop.
>
> Nowadays backend device usually support 512k max_sectors_kb on desktop, and
> may larg
On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> (gdb) print *tdb
> $1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
> 16711680,
> locked = 0xff00, ecode = 16711680, header = {
> magic_food =
> "\000\000\000\000\000\000\000\000\000\377\000\000\000\000\37
On 16/12/14 05:55, Juergen Gross wrote:
> On 12/15/2014 01:05 PM, David Vrabel wrote:
>> On 11/12/14 18:04, Juergen Gross wrote:
>>> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
>>> use the auto generated symbol list.
>>>
>>> This also corrects the wrong address of xen_hyperca
The default maximum value of segments in indirect requests was 32, IO
operations with bigger block size(>32*4k) would be split and performance start
to drop.
Nowadays backend device usually support 512k max_sectors_kb on desktop, and
may larger on server machines with high-end storage system.
The
On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> Hello Ian,
>
> On 15.12.2014 18:45, Ian Campbell wrote:
> > On Mon, 2014-12-15 at 14:50 +, Ian Campbell wrote:
> >> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> >>> I just noticed something strange:
> >>>
> #3 0x000
flight 32387 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32387/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 3 host-install(3) broken REGR. vs. 32194
test-amd64-amd64-xl
>>> On 16.12.14 at 09:55, wrote:
> Any comments from you? It would be greatly appreciated if you can look
> at this when you have time. Your comments are always important to me :)
I don't think I have to say much here:
> On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
>> Implementatio
>>> On 15.12.14 at 23:24, wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
>
> We have to do this via IPI since otherwise there is a (somewheat
> theoretical) chance tha
On Mon, 2014-12-15 at 17:07 +, Anthony PERARD wrote:
> On Thu, Dec 11, 2014 at 04:23:15PM +, Ian Campbell wrote:
> > On Thu, 2014-12-11 at 16:16 +, Anthony PERARD wrote:
> > > On Tue, Dec 09, 2014 at 03:56:02PM +, Ian Campbell wrote:
> > > > On Tue, 2014-12-09 at 15:39 +, Anthon
Hi Jan,
Any comments from you? It would be greatly appreciated if you can look
at this when you have time. Your comments are always important to me :)
Thanks,
Chao
On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> Hi all, we plan to bring Intel CAT into XEN. This is the initial
> desi
>>> On 15.12.14 at 18:15, wrote:
> On 12/15/2014 05:07 AM, Jan Beulich wrote:
> On 12.12.14 at 22:20, wrote:
>>> --- a/xen/arch/x86/hvm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/vpmu.c
>>> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>>> }
>>> }
>>>
>>> +static void vpmu_clea
76 matches
Mail list logo
