Hi Felipe,
On 03/06/2015 06:30 PM, Felipe Franciosi wrote:
>> -Original Message-
>> From: Bob Liu [mailto:bob@oracle.com]
>> Sent: 05 March 2015 00:47
>> To: Konrad Rzeszutek Wilk
>> Cc: Roger Pau Monne; Felipe Franciosi; David Vrabel; xen-devel@lists.xen.org;
>> linux-ker...@vger.kern
Yes there is. Take a look at this sample code in LibVMI:
https://github.com/libvmi/libvmi/blob/master/examples/event-example.c
Cheers,
Tamas
On Mon, Mar 16, 2015 at 11:12 PM, HANNAS YAYA Issa
wrote:
> Hello
> I want to know when there is context switch between processes in guest the
> xen hyperv
>>> On 17.03.15 at 06:26, wrote:
> In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a
> hypercall to inform xen that a new pci device has been added.
> If we were to inform xen about a new pci bus that is added there are 2 ways
> a) Issue the hypercall from drivers/pci/prob
If I remember the context correctly this is in the autodetect case,
so I think shouldn't mention IGD. Something like "Unable to detect
graphics passthru kind, please set gfx_passthru_kind. See xl.cfg(5)
for more
s/gfx_passthru_kind/gfx_passthru, right? Because actually we always get
'gfx_passthr
On Fri, Mar 13, 2015 at 09:40:13AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 13, 2015 at 06:13:20PM +0800, Chao Peng wrote:
> > Detect Intel Cache Allocation Technology(CAT) feature and store the
> > cpuid information for later use. Currently only L3 cache allocation is
> > supported. The L
>>> On 16.03.15 at 18:59, wrote:
> Hence was wondering if it would just be easier to put
> this patch in (see above) - with the benfit that folks have
> an faster interrupt passthrough experience and then I work on another
> variant of this with tristate cmpxchg and ->mapping atomic counter.
Cons
Tuesday, March 17, 2015, 9:18:32 AM, you wrote:
On 16.03.15 at 18:59, wrote:
>> Hence was wondering if it would just be easier to put
>> this patch in (see above) - with the benfit that folks have
>> an faster interrupt passthrough experience and then I work on another
>> variant of this wi
On Mon, Mar 16, 2015 at 01:47:06PM +, Jan Beulich wrote:
> >>> On 13.03.15 at 11:13, wrote:
> > @@ -1112,6 +1117,12 @@ The following resources are available:
> >total/local memory bandwidth. Follow the same options with Cache
> > Monitoring
> >Technology.
> >
> > +* Cache Alllocatio
>>> On 17.03.15 at 01:46, wrote:
> On 3/16/15, Jan Beulich wrote:
>> So where do you expect the major performance / scalability
>> improvement to be gained? Internally to Xen, each page will need
>> to be tracked separately anyway, as what appears physically
>> contiguous in the granting guest ma
On Fri, Mar 13, 2015 at 09:53:37AM -0400, Konrad Rzeszutek Wilk wrote:
> > +xfree(d->arch.psr_cos_ids);
>
> And d->arch.psr_cos_ids = NULL
>
> (however this depends on who calls psr_domain_init, which
> is unclear to me).
>
> > +}
> > +
> > +int psr_domain_init(struct domain *d)
> > +{
> > +
>>> On 17.03.15 at 09:48, wrote:
> On Mon, Mar 16, 2015 at 01:47:06PM +, Jan Beulich wrote:
>> >>> On 13.03.15 at 11:13, wrote:
>> > @@ -1112,6 +1117,12 @@ The following resources are available:
>> >total/local memory bandwidth. Follow the same options with Cache
>> > Monitoring
>> >
On Mon, Mar 16, 2015 at 05:10:32PM +, Jan Beulich wrote:
> >>> On 13.03.15 at 11:13, wrote:
> > +else
> > +{
> > +unsigned int cpu = cpumask_check(get_socket_cpu(socket));
>
> Isn't this going to trigger an assertion when the socket count got
> specified on the command line?
On Mon, Mar 16, 2015 at 04:53:35PM +, Jan Beulich wrote:
> >>> On 13.03.15 at 11:13, wrote:
> > @@ -1473,11 +1471,10 @@ static void __context_switch(void)
> > }
> > vcpu_restore_fpu_eager(n);
> > n->arch.ctxt_switch_to(n);
> > -
> > -if ( psr_cmt_enabled() &&
>>> On 13.03.15 at 11:13, wrote:
> @@ -407,10 +388,75 @@ void psr_domain_free(struct domain *d)
> psr_free_cos(d);
> }
>
> +static void psr_assoc_init(struct psr_assoc *psra)
> +{
> +unsigned int socket;
> +struct psr_cat_socket_info *info;
> +
> +socket = cpu_to_socket(smp_pro
On Mon, Mar 16, Quan Xu wrote:
> Typedefs are duplicated in stubdom/vtpmmgr/tcg.h and supported compilers
> do not cope with current staging branch.
This version finally compiles. Thanks!
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://
Olaf,
Thanks for your test.
Ian,
Could you help me check it again? Any comments, I will fix it soon.
If no any other comments, could you help me merge it? Thanks.
Quan
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Tuesday, March 17, 2015 5:20 PM
> To:
>>> On 17.03.15 at 10:11, wrote:
> On Mon, Mar 16, 2015 at 05:10:32PM +, Jan Beulich wrote:
>> >>> On 13.03.15 at 11:13, wrote:
>> > +else
>> > +{
>> > +unsigned int cpu = cpumask_check(get_socket_cpu(socket));
>>
>> Isn't this going to trigger an assertion when the socket co
On Tue, 2015-03-17 at 15:46 +0800, Chen, Tiejun wrote:
> >>> If I remember the context correctly this is in the autodetect case,
> >>> so I think shouldn't mention IGD. Something like "Unable to detect
> >>> graphics passthru kind, please set gfx_passthru_kind. See xl.cfg(5)
> >>> for more
> >>
> >
On Tue, Mar 17, 2015 at 09:19:42AM +, Jan Beulich wrote:
> > +psra->cos_mask = (~(~0ull << (get_count_order(info->cos_max)
> > + + 32))) & (~0ull << 32);
>
> ((1ull << get_count_order()) - 1) << 32
>
> seems better readable to me.
Indeed :)
>
> > vo
On Thu, 2015-03-12 at 16:42 -0400, Daniel De Graaf wrote:
> This adds support in the hypervisor and policy build toolchain for
> Xen/Flask policy version 30, which adds the ability to label ARM device
> tree nodes and expands the IOMEM ocontext entries to 64 bits.
>
> Signed-off-by: Daniel De Graa
On Tue, Mar 17, 2015 at 09:25:48AM +, Jan Beulich wrote:
> >>> On 17.03.15 at 10:11, wrote:
> > On Mon, Mar 16, 2015 at 05:10:32PM +, Jan Beulich wrote:
> >> >>> On 13.03.15 at 11:13, wrote:
> >> > +else
> >> > +{
> >> > +unsigned int cpu = cpumask_check(get_socket_cpu(soc
flight 36498 linux-3.10 running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36498/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt queued
build-i386-rumpuserxen
flight 36501 seabios running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36501/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt queued
test-amd64-amd64-xl-winxpsp
flight 36491 qemu-mainline running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36491/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt queued
build-amd64-pvops
flight 36500 ovmf running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36500/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel queued
build-i386-libvirt
flight 36505 linux-next running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36505/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen queued
build-amd64-libvirt
flight 36495 linux-3.16 running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36495/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 2 hosts-allocate running [st=running!]
>>> On 30.01.15 at 18:54, wrote:
> @@ -94,6 +111,17 @@ ENTRY(start)
> gdt_boot_descr:
> .word 6*8-1
> .long sym_phys(trampoline_gdt)
> +.long 0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +.long sym_phys(cs32_switch)
> +.long BOOT_CS
On Mon, 2015-03-16 at 12:41 +, Ian Campbell wrote:
> We've not yet tracked down the source of the mysterious filer reboots
> and there was another earlier today, we've fiddled with a few things to
> see if we can track them down.
>
> osstest is doing stuff now, fingers crossed.
There were som
On Tue, 2015-03-17 at 00:10 +, Slutz, Donald Christopher wrote:
> @@ -715,7 +715,7 @@ static int hvm_ioreq_server_map_pages(struct
> hvm_ioreq_server *s,
>bool_t is_default, bool_t
> handle_bufioreq)
> {
> struct domain *d = s->domain;
> -unsign
>>> On 16.03.15 at 18:04, wrote:
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -264,18 +264,17 @@ rt_dump(const struct scheduler *ops)
> struct list_head *iter_sdom, *iter_svc, *runq, *depletedq, *iter;
> struct rt_private *prv = rt_priv(ops);
> struct rt_vcpu *sv
On Mon, 2015-03-16 at 17:18 +, George Dunlap wrote:
> On 02/27/2015 04:51 PM, Dario Faggioli wrote:
> > diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> > index ad0a5d4..2b852cc 100644
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -931,
>>> On 16.03.15 at 18:05, wrote:
> such as it is taken care of by the various schedulers, rather
> than happening in schedule.c. In fact, it is the schedulers
> that know better which locks are necessary for the specific
> dumping operations.
>
> While there, fix a few style issues (indentation,
On Tue, 2015-03-17 at 10:41 +, Jan Beulich wrote:
> >>> On 16.03.15 at 18:04, wrote:
> > --- a/xen/common/sched_rt.c
> > +++ b/xen/common/sched_rt.c
> > @@ -264,18 +264,17 @@ rt_dump(const struct scheduler *ops)
> > struct list_head *iter_sdom, *iter_svc, *runq, *depletedq, *iter;
> >
>>> On 16.03.15 at 18:05, wrote:
> e.g., with `xl debug-key r'. This change adds something
> like the following lines to the dump output:
>
> (XEN) Num online Cpus: 16, cpu_online_map: 0-15
> (XEN) Num free Cpus: 8, cpupool_free_cpus: 8-15
I dislike such redundant information: Just printing
On 03/17/2015 10:54 AM, Jan Beulich wrote:
On 16.03.15 at 18:05, wrote:
>> such as it is taken care of by the various schedulers, rather
>> than happening in schedule.c. In fact, it is the schedulers
>> that know better which locks are necessary for the specific
>> dumping operations.
>>
>> W
On 03/16/2015 08:30 PM, Meng Xu wrote:
> Hi Dario,
>
> 2015-03-16 13:05 GMT-04:00 Dario Faggioli :
>> In fact, printing the cpupool's CPU online mask
>> for each vCPU is just redundant, as that is the
>> same for all the vCPUs of all the domains in the
>> same cpupool, while hard affinity is alrea
Thanks Zoli, every time you have given very well detailed answers.
I will consider that and will let you know .
Best Regards
Ronald
On Mon, Mar 16, 2015 at 12:49 PM, Zoltan Kiss wrote:
> Hi,
>
> In that case I recommend you to take a look at the debugfs patch already in
> there, based on that i
On 03/17/2015 10:48 AM, Dario Faggioli wrote:
> On Mon, 2015-03-16 at 17:18 +, George Dunlap wrote:
>> On 02/27/2015 04:51 PM, Dario Faggioli wrote:
>
>
>>> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
>>> index ad0a5d4..2b852cc 100644
>>> --- a/xen/common/sched_credit
On Tue, 2015-03-17 at 10:54 +, Jan Beulich wrote:
> >>> On 16.03.15 at 18:05, wrote:
> > such as it is taken care of by the various schedulers, rather
> > than happening in schedule.c. In fact, it is the schedulers
> > that know better which locks are necessary for the specific
> > dumping ope
On Tue, Mar 10, 2015 at 12:03 PM, Bob Ball wrote:
> For the last few weeks Anthony and I have been working on creating a CI
> environment to run against all OpenStack jobs. We're now in a position where
> we can share the current status, overview of how it works and next steps. We
> actively
On Fri, Mar 13, 2015 at 01:51:05PM +0100, Imre Palik wrote:
> From: "Palik, Imre"
>
> With the current netback, the bandwidth limiter's parameters are only
> settable during vif setup time. This patch register a watch on them, and
> thus makes them runtime changeable.
>
> When the watch fires,
On Tue, 2015-03-17 at 11:05 +, George Dunlap wrote:
> On 03/17/2015 10:54 AM, Jan Beulich wrote:
> > Finally, as said in different contexts earlier, I think unconditionally
> > acquiring locks in dumping routines isn't the best practice. At least
> > in non-debug builds I think these should be
>>> On 17.03.15 at 12:05, wrote:
> On 03/17/2015 10:54 AM, Jan Beulich wrote:
>> Finally, as said in different contexts earlier, I think unconditionally
>> acquiring locks in dumping routines isn't the best practice. At least
>> in non-debug builds I think these should be try-locks only, skipping
On Fri, 2015-03-13 at 13:51 +0100, Imre Palik wrote:
[...]
> diff --git a/drivers/net/xen-netback/interface.c
> b/drivers/net/xen-netback/interface.c
> index 3aa8648..34d8038 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -463,6 +463,7 @@ int xe
>>> On 17.03.15 at 12:10, wrote:
> On 03/16/2015 08:30 PM, Meng Xu wrote:
>> 2015-03-16 13:05 GMT-04:00 Dario Faggioli :
>>> This change also takes the chance to add a scratch
>>> cpumask, to avoid having to create one more
>>> cpumask_var_t on the stack of the dumping routine.
>>
>> Actually, I
>>> On 17.03.15 at 12:14, wrote:
> On Tue, 2015-03-17 at 10:54 +, Jan Beulich wrote:
>> Finally, as said in different contexts earlier, I think unconditionally
>> acquiring locks in dumping routines isn't the best practice. At least
>> in non-debug builds I think these should be try-locks only
On 03/17/2015 11:25 AM, Jan Beulich wrote:
On 17.03.15 at 12:05, wrote:
>> On 03/17/2015 10:54 AM, Jan Beulich wrote:
>>> Finally, as said in different contexts earlier, I think unconditionally
>>> acquiring locks in dumping routines isn't the best practice. At least
>>> in non-debug builds I
On Thu, 2015-03-12 at 18:14 +, Lars Kurth wrote:
> Hi,I nearly missed this. Please make sure you forward stuff and change
> the headline if you want me to look into things. Otherwise I may miss
> it.
Sure, I'll try and remember.
FYI before Ian J went away he mentioned that he had raised some
>>> On 17.03.15 at 12:32, wrote:
> On 03/17/2015 11:25 AM, Jan Beulich wrote:
> On 17.03.15 at 12:05, wrote:
>>> On 03/17/2015 10:54 AM, Jan Beulich wrote:
Finally, as said in different contexts earlier, I think unconditionally
acquiring locks in dumping routines isn't the best prac
On Tue, Mar 17, 2015 at 12:46 AM, Andrew Warkentin wrote:
> I was thinking more of explicit sharing of code rather than automatic
> deduplication (at least I'm assuming you're talking about the
> deduplication support that was added a while back).
Automatic deduplication has two halves: automatic
On 03/17/2015 11:43 AM, Jan Beulich wrote:
On 17.03.15 at 12:32, wrote:
>> On 03/17/2015 11:25 AM, Jan Beulich wrote:
>> On 17.03.15 at 12:05, wrote:
On 03/17/2015 10:54 AM, Jan Beulich wrote:
> Finally, as said in different contexts earlier, I think unconditionally
> acquir
On Tuesday 17 March 2015 12:58 PM, Jan Beulich wrote:
On 17.03.15 at 06:26, wrote:
In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a
hypercall to inform xen that a new pci device has been added.
If we were to inform xen about a new pci bus that is added there are 2 ways
>>> On 17.03.15 at 13:06, wrote:
> On Tuesday 17 March 2015 12:58 PM, Jan Beulich wrote:
> On 17.03.15 at 06:26, wrote:
>>> In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a
>>> hypercall to inform xen that a new pci device has been added.
>>> If we were to inform xen
On Mon, Mar 16, 2015 at 11:31:49AM +0100, Juergen Gross wrote:
> On 03/16/2015 11:03 AM, Daniel Kiper wrote:
> >On Mon, Mar 16, 2015 at 06:35:04AM +0100, Juergen Gross wrote:
> >>On 03/11/2015 04:40 PM, Boris Ostrovsky wrote:
> >>>On 03/11/2015 10:42 AM, David Vrabel wrote:
> On 10/03/15 13:35,
On Tue, Mar 17, 2015 at 10:32:01AM +, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, wrote:
> > @@ -94,6 +111,17 @@ ENTRY(start)
> > gdt_boot_descr:
> > .word 6*8-1
> > .long sym_phys(trampoline_gdt)
> > +.long 0 /* Needed for 64-bit lgdt */
> > +
> > +cs32_swi
On Mon, 2015-03-16 at 14:00 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 10, 2015 at 12:03:13PM +, Bob Ball wrote:
> > I'd like to organise a meeting to walk through the various components of
> > the CI with those who are interested, so this is an initial call to find
> > out who is int
On Mon, Mar 16, 2015 at 11:08:50PM +, Ian Murray wrote:
> On 16/03/15 14:12, Konrad Rzeszutek Wilk wrote:
> > On Sun, Mar 15, 2015 at 09:34:16PM +, Ian Murray wrote:
> >> Hi,
> >>
> >> I have a domU guest that booted fine under Xen 4.4.1 with pvh=1 but now
> >> fails to boot with it under
On Mon, 2015-03-16 at 14:23 -0400, Meng Xu wrote:
> 2015-03-16 13:10 GMT-04:00 Dario Faggioli :
> > We discussed about this issue before, here:
> > http://lists.xen.org/archives/html/xen-devel/2014-09/msg02765.html
> >
> > But, as far as it looks, the code we ended up merging still had the
> > iss
On 03/17/2015 01:40 PM, Daniel Kiper wrote:
On Mon, Mar 16, 2015 at 11:31:49AM +0100, Juergen Gross wrote:
On 03/16/2015 11:03 AM, Daniel Kiper wrote:
On Mon, Mar 16, 2015 at 06:35:04AM +0100, Juergen Gross wrote:
On 03/11/2015 04:40 PM, Boris Ostrovsky wrote:
On 03/11/2015 10:42 AM, David Vr
(CC Ian and Jan)
Hi,
Is there any blocker to push this patch? It's useful for using XSM with
passthrough.
Regards,
On 11/03/15 14:59, Daniel De Graaf wrote:
> The definitions of static device labels must be placed at the end of the
> policy.conf before passing it to checkpolicy; the existing ex
Hi Ian,
On Thu, Mar 5, 2015 at 10:40 PM, Ian Campbell wrote:
> On Thu, 2015-03-05 at 16:46 +, Ian Campbell wrote:
>> On Wed, 2015-03-04 at 11:36 +0530, vijay.kil...@gmail.com wrote:
>> > From: Vijaya Kumar K
>> >
>> > Add GSER region to thunderx platfrom specific mappings.
>> > This region i
> On 17 Mar 2015, at 11:40, Ian Campbell wrote:
>
> On Thu, 2015-03-12 at 18:14 +, Lars Kurth wrote:
>> Hi,I nearly missed this. Please make sure you forward stuff and change
>> the headline if you want me to look into things. Otherwise I may miss
>> it.
>
> Sure, I'll try and remember.
>
On Tue, Mar 17, 2015 at 04:11:33PM +0800, Chao Peng wrote:
> On Fri, Mar 13, 2015 at 09:40:13AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Mar 13, 2015 at 06:13:20PM +0800, Chao Peng wrote:
> > > Detect Intel Cache Allocation Technology(CAT) feature and store the
> > > cpuid information for la
On Tue, 17 Mar 2015, Ian Campbell wrote:
> On Thu, 2015-03-12 at 18:14 +, Lars Kurth wrote:
> > Hi,I nearly missed this. Please make sure you forward stuff and change
> > the headline if you want me to look into things. Otherwise I may miss
> > it.
>
> Sure, I'll try and remember.
>
> FYI bef
On Tue, Mar 17, 2015 at 10:56:48AM +0530, Manish Jaggi wrote:
>
> On Friday 27 February 2015 10:20 PM, Ian Campbell wrote:
> >On Fri, 2015-02-27 at 16:35 +, Jan Beulich wrote:
> >On 27.02.15 at 16:24, wrote:
> >>>On Fri, 2015-02-27 at 14:54 +, Stefano Stabellini wrote:
> MMCFG is
>>> On 17.03.15 at 14:03, wrote:
> (CC Ian and Jan)
This is mostly about tools stuff:
>> docs/misc/xsm-flask.txt | 31 +++
>> tools/flask/policy/Makefile | 3 ++-
>> tools/flask/policy/policy/device_contexts| 32
Hi Ian,
Sorry for the late answer.
On 23/02/15 17:22, Ian Campbell wrote:
> On Mon, 2015-02-23 at 17:06 +, Julien Grall wrote:
>> On 23/02/15 11:46, Ian Campbell wrote:
>>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
Let the user to pass additional nodes to the guest device tr
On 07/11/2014 08:23 PM, Andrew Cooper wrote:
> On 11/07/14 16:43, Razvan Cojocaru wrote:
>> Added support for VMCALL events (the memory introspection library
>> will have the guest trigger VMCALLs, which will then be sent along
>> via the mem_event mechanism).
>>
>> Changes since V1:
>> - Added a
On Mon, 2015-03-16 at 19:05 +, George Dunlap wrote:
> On 03/16/2015 05:05 PM, Dario Faggioli wrote:
> > @@ -218,7 +224,6 @@ __q_elem(struct list_head *elem)
> > static void
> > rt_dump_vcpu(const struct scheduler *ops, const struct rt_vcpu *svc)
> > {
> > -char cpustr[1024];
> > cp
On 03/13/2015 08:37 PM, Konrad Rzeszutek Wilk wrote:
> +static int parse_cpumask(const char *arg)
> +{
> +xc_cpumap_t map;
> +uint32_t v, i;
> +int bits = 0;
> +
> +map = malloc(sizeof(uint32_t));
> +if ( !map )
> +return -ENOMEM;
> +
> +v = argtol(arg, 0);
> +fo
On Tue, 2015-03-17 at 18:32 +0530, Vijay Kilari wrote:
> Hi Ian,
>
> On Thu, Mar 5, 2015 at 10:40 PM, Ian Campbell wrote:
> > On Thu, 2015-03-05 at 16:46 +, Ian Campbell wrote:
> >> On Wed, 2015-03-04 at 11:36 +0530, vijay.kil...@gmail.com wrote:
> >> > From: Vijaya Kumar K
> >> >
> >> > Add
>>> On 17.03.15 at 14:05, wrote:
>> On 17 Mar 2015, at 11:40, Ian Campbell wrote:
>> I think the main things which is missing is some decision as to the the
>> point at which we would consider the ABI for a PV protocol fixed, i.e.
>> to be maintained in a backwards compatible manner from then on.
>>> On 17.03.15 at 14:50, wrote:
> On 07/11/2014 08:23 PM, Andrew Cooper wrote:
>> From the point of view of your in-guest agent, it would be a vmcall with
>> rax = 34 (hvmop) rdi = $N (send_mem_event subop) rsi = data or pointer
>> to struct containing data, depending on how exactly you implement
On Tue, 2015-03-17 at 13:05 +, Lars Kurth wrote:
> > On 17 Mar 2015, at 11:40, Ian Campbell wrote:
> >
> > On Thu, 2015-03-12 at 18:14 +, Lars Kurth wrote:
> >> Hi,I nearly missed this. Please make sure you forward stuff and change
> >> the headline if you want me to look into things. Oth
Hi Chunyan,
I've found another problem while trying to write a qemu based pvUSB
backend.
On 01/19/2015 09:28 AM, Chunyan Liu wrote:
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list assignable usb devices in host
- some
On 03/17/2015 03:58 PM, Jan Beulich wrote:
On 17.03.15 at 14:50, wrote:
>> On 07/11/2014 08:23 PM, Andrew Cooper wrote:
>>> From the point of view of your in-guest agent, it would be a vmcall with
>>> rax = 34 (hvmop) rdi = $N (send_mem_event subop) rsi = data or pointer
>>> to struct contain
On Tue, 2015-03-17 at 10:45 +0530, Manish Jaggi wrote:
> On Monday 09 March 2015 08:04 AM, Yijing Wang wrote:
> > Now we could pass PCI domain combined with bus number
> > in u32 argu. Because in arm/arm64, PCI domain number
> > is assigned by pci_bus_assign_domain_nr(). So we leave
> > pci_scan_ro
On Mon, 2015-03-16 at 16:30 -0400, Meng Xu wrote:
> Hi Dario,
>
Hey,
> 2015-03-16 13:05 GMT-04:00 Dario Faggioli :
> >
> > This change also takes the chance to add a scratch
> > cpumask, to avoid having to create one more
> > cpumask_var_t on the stack of the dumping routine.
>
> Actually, I ha
>>> On 17.03.15 at 15:07, wrote:
> Yes, but Andrew's idea (which I think is very neat) is that instead of
> the trickery I used to do in the original patch (create a specific
> VMCALL vm_event and compare eax to a magic constant on VMCALL-based
> VMEXITS, to figure out if all I wanted to do was se
Bob Ball wrote:
> For the last few weeks Anthony and I have been working on creating a CI
> environment to run against all OpenStack jobs. We're now in a position where
> we can share the current status, overview of how it works and next steps. We
> actively want to support involvement in this
On 17/03/15 12:54, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 16, 2015 at 11:08:50PM +, Ian Murray wrote:
>> On 16/03/15 14:12, Konrad Rzeszutek Wilk wrote:
>>> On Sun, Mar 15, 2015 at 09:34:16PM +, Ian Murray wrote:
Hi,
I have a domU guest that booted fine under Xen 4.4.1 wi
On 03/17/2015 04:20 PM, Jan Beulich wrote:
On 17.03.15 at 15:07, wrote:
>> Yes, but Andrew's idea (which I think is very neat) is that instead of
>> the trickery I used to do in the original patch (create a specific
>> VMCALL vm_event and compare eax to a magic constant on VMCALL-based
>> VME
On Tue, 2015-03-17 at 10:28 +, Ian Campbell wrote:
> On Mon, 2015-03-16 at 12:41 +, Ian Campbell wrote:
> > We've not yet tracked down the source of the mysterious filer reboots
> > and there was another earlier today, we've fiddled with a few things to
> > see if we can track them down.
>
Hi all
I'm now working on upstream QEMU stubdom, and rump kernel seems to be a
good fit for this purpose.
A bit background information. A stubdom is a service domain. With QEMU
stubdom we are able to run QEMU device emulation code in a separate
domain so that bugs in QEMU don't affect Dom0 (the
flight 36499 qemu-upstream-4.4-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36499/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 2 hosts-allocaterunnin
flight 36492 qemu-upstream-4.5-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36492/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 2 hosts-allocaterunnin
Hi Bob,
> -Original Message-
> From: Bob Liu [mailto:bob@oracle.com]
> Sent: 17 March 2015 07:00
> To: Felipe Franciosi
> Cc: Konrad Rzeszutek Wilk; Roger Pau Monne; David Vrabel; xen-
> de...@lists.xen.org; linux-ker...@vger.kernel.org; ax...@fb.com;
> h...@infradead.org; avanzini.ari
On Tue, Mar 17, 2015 at 09:42:21AM +0100, Sander Eikelenboom wrote:
>
> Tuesday, March 17, 2015, 9:18:32 AM, you wrote:
>
> On 16.03.15 at 18:59, wrote:
> >> Hence was wondering if it would just be easier to put
> >> this patch in (see above) - with the benfit that folks have
> >> an faster
flight 36494 qemu-upstream-4.3-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36494/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-winxpsp3-vcpus1 2 hosts-allocate runnin
On Tue, Mar 17, 2015 at 02:54:09PM +, Ian Campbell wrote:
> On Tue, 2015-03-17 at 14:29 +, Wei Liu wrote:
> > 2. The ability to access files in Dom0. That will be used to write to /
> >read from QEMU state file.
>
> This requirement is not as broad as you make it sound.
>
Yes. You're
Save VPMU state during context switch for both HVM and PV(H) guests.
A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call
context_
With this patch return value of 1 of vpmu_do_msr() will now indicate whether an
error was encountered during MSR processing (instead of stating that the access
was to a VPMU register).
As part of this patch we also check for validity of certain MSR accesses right
when we determine which register i
We don't need to try to destroy it since it can't be already allocated at the
time we try to initialize it.
Signed-off-by: Boris Ostrovsky
Suggested-by: Andrew Cooper
---
Changes in v19:
* Removed unnecesary test for VPMU_CONTEXT_ALLOCATED in svm/vpmu.c
xen/arch/x86/hvm/svm/vpmu.c | 3 ---
xe
Intercept accesses to PMU MSRs and process them in VPMU module. If vpmu ops
for VCPU are not initialized (which is the case, for example, for PV guests that
are not "VPMU-enlightened") access to MSRs will return failure.
Dump VPMU state for all domains (HVM and PV) when requested.
Signed-off-by:
On Tue, Mar 17, 2015 at 02:29:07PM +, Wei Liu wrote:
> I've now successfully built QEMU upstream with rump kernel. However to
> make it fully functional as a stubdom, there are some missing pieces to
> be added in.
>
> 1. The ability to access QMP socket (a unix socket) from Dom0. That
>wi
The two routines share most of their logic.
Signed-off-by: Boris Ostrovsky
---
Changes in v19:
* const-ified arch_vpmu_ops in vpmu_do_wrmsr
* non-changes:
- kept 'current' as a non-initializer to avoid unnecessary initialization
in the (common) non-VPMU case
- kept 'nop' label since th
Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.
Signed-off-by: Boris Ostrovsky
---
Changes in v19:
* Slightly different mode changing logic i
On Tue, 2015-03-17 at 14:57 +, Wei Liu wrote:
> On Tue, Mar 17, 2015 at 02:54:09PM +, Ian Campbell wrote:
> > On Tue, 2015-03-17 at 14:29 +, Wei Liu wrote:
> > > 2. The ability to access files in Dom0. That will be used to write to /
> > >read from QEMU state file.
> >
> > This req
Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF: PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
can profile itself
1 - 100 of 163 matches
Mail list logo
