On 2015/3/18 12:26, Manish Jaggi wrote:
>
> On Tuesday 17 March 2015 07:35 PM, Ian Campbell wrote:
>> 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
On 03/17/2015 04:33 PM, Dario Faggioli wrote:
e.g., with `xl debug-key r', like this:
(XEN) Online Cpus: 0-15
(XEN) Free Cpus: 8-15
Also, for each cpupool, print the set of pCPUs it
contains, like this:
(XEN) Cpupool 0:
(XEN) Cpus: 0-7
(XEN) Scheduler: SMP Credit Scheduler (cre
On Tuesday 17 March 2015 07:35 PM, Ian Campbell wrote:
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_a
On Tuesday 17 March 2015 06:01 PM, Jan Beulich wrote:
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 be
2015-03-17 11:33 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 already part
> of the output of dumping domains info.
>
> Instead
Hi Dario,
2015-03-17 10:12 GMT-04:00 Dario Faggioli :
> 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
>> > cpu
>>>
>>> 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 have a question about the strength of this design. When we
>> have a machine with many cpus, we will end up with alloca
On 03/17/2015 10:52 PM, Felipe Franciosi wrote:
> Hi Bob,
>
> I've put the hardware back together and am sorting out the software for
> testing. Things are not moving as fast as I wanted due to other commitments.
> I'll keep this thread updated as I progress. Malcolm is OOO and I'm trying to
>
On 3/17/15, Jan Beulich wrote:
> And how would that be significantly different from the batching
> that's already built into the grant table hypercall?
>
I guess it does do more or less what I want already. I was looking
more at the inner mapping/unmapping functions, rather than the
wrappers aroun
Tuesday, March 17, 2015, 6:44:54 PM, you wrote:
>> >> Additionally I think it should be considered whether the bitmap
>> >> approach of interpreting ->state is the right one, and we don't
>> >> instead want a clean 3-state (idle, sched, run) model.
>> >
>> > Could you elaborate a bit more pleas
In order to support paths containing spaces or other characters, allow a
quoted string with these characters to be parsed as a path in addition
to the existing unquoted string.
Signed-off-by: Daniel De Graaf
---
checkpolicy/policy_parse.y | 3 +++
checkpolicy/policy_scan.l | 1 +
2 files change
In Xen on ARM, device tree nodes identified by a path (string) need to
be labeled by the security policy.
Signed-off-by: Daniel De Graaf
---
checkpolicy/policy_define.c| 55 +
checkpolicy/policy_define.h| 1 +
checkpolicy/policy_parse.y
In order to support assigning security lables to ARM device tree nodes
in Xen's XSM policy, a new ocontext type is needed in the security
policy.
In addition to adding the new ocontext, the existing I/O memory range
ocontext is expanded to 64 bits in order to support hardware with more
than 44 bit
This expands IOMEMCON device context entries to 64 bits. This change is
required to support static I/O memory range labeling for systems with
over 16TB of physical address space. The policy version number change
is shared with the next patch.
While this makes no changes to SELinux policy, a new
On Mon, 2015-03-16 at 12:56 +, Jan Beulich wrote:
> >>> On 16.03.15 at 13:51, wrote:
> > On 03/16/2015 12:48 PM, Jan Beulich wrote:
> >> Them returning garbage isn't what needs fixing. Instead the code
> >> here should use a different condition to check whether this is the
> >> boot CPU (e.g.
On Tue, Mar 17, 2015 at 09:30:59AM -0600, Jim Fehlig wrote:
> From: Ian Jackson
>
> Call xc_domain_destroy in a subprocess. That allows us to do so
> asynchronously, rather than blocking the whole process calling libxl.
>
> The changes in detail:
>
> * Provide an libxl__ev_child in libxl__dom
It seems some repos have this via the hooks/post-update.sample having
been renamed to hooks/post-update, but a few don't.
So I've done:
xen@xenbits:~/git$ for i in rumpuser-xen.git mini-os.git libvirt.git ;
do
> mv -iv $i/hooks/post-update.sample $i/hooks/post-update
> do
On Tue, Mar 17, 2015 at 09:30:57AM -0600, Jim Fehlig wrote:
> From: Ian Jackson
>
> From: Ian Jackson
>
> When domain_death_xswatch_callback needed a further call to
> xc_domain_getinfolist it would restart it with the last domain it
> found rather than the first one it wants.
>
> If it only w
On Tue, Mar 17, 2015 at 09:30:58AM -0600, Jim Fehlig wrote:
> From: Ian Jackson
>
> Unlock the userdata before we actually call xc_domain_destroy. This
> leaves open the possibility that other libxl callers will see the
> half-destroyed domain (with no devices, paused), but this is fine.
>
> Si
> >> Additionally I think it should be considered whether the bitmap
> >> approach of interpreting ->state is the right one, and we don't
> >> instead want a clean 3-state (idle, sched, run) model.
> >
> > Could you elaborate a bit more please? As in three different unsigned int
> > (or bool_t) t
Note that the following Haswell chipsets should also be included in this list:
Haswell - 0xc0f, 0xd00, 0xd04, 0xd08, 0xd0f, 0xa00, 0xa08, 0xa0f
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com
Note that the following Nehalem/Westmere chipsets should be included in this
list:
Nehalem - 0x40, 0x2c01, 0x2c41, 0x313x
Westmere - 0x2c70, 0x2d81, 0xd15x
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786
-Original Message-
From: Jan Beulich [mailto:jbeu
At 15:55 + on 17 Mar (1426607705), Jan Beulich wrote:
> - drop an effectively unused struct pv_vcpu field (x86)
> - adjust VM_ASSIST() to prepend VMASST_TYPE_
>
> Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan , though I think these would
have been better as two separate patches.
Cheers
On Tue, Mar 17, 2015 at 04:06:14PM +, Jan Beulich wrote:
> >>> On 17.03.15 at 16:38, wrote:
> > --- a/xen/drivers/passthrough/io.c
> > +++ b/xen/drivers/passthrough/io.c
> > @@ -804,7 +804,17 @@ static void dpci_softirq(void)
> > d = pirq_dpci->dom;
> > smp_mb(); /* 'd' MUST
On 17/03/15 14:29, 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
will be used to issue command to Q
At 15:56 + on 17 Mar (1426607770), Jan Beulich wrote:
> Most callers have this available already, and the functions don't need
> any vcpu specifics.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists
On Tue, Mar 17, 2015 at 04:01:49PM +, Jan Beulich wrote:
> >>> On 17.03.15 at 15:54, wrote:
> > On Tue, Mar 17, 2015 at 09:42:21AM +0100, Sander Eikelenboom wrote:
> >> I'm still running with this first simple stopgap patch from Konrad,
> >> and it has worked fine for me since.
> >
> > I beli
On Mon, Mar 16, 2015 at 10:06:17AM +, PRAMOD DEVENDRA wrote:
> From: Pramod Devendra
>
> Signed-off-by: Pramod Devendra
> CC: Ian Jackson
> CC: Stefano Stabellini
> CC: Ian Campbell
> CC: Wei Liu
Acked-by: Wei Liu
> ---
> tools/libxl/libxl_cpuid.c |8 +---
> 1 file changed, 5
On Tue, Mar 17, 2015 at 01:52:27PM +, George Dunlap wrote:
> 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));
> > +
>>> On 17.03.15 at 16:38, wrote:
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -804,7 +804,17 @@ static void dpci_softirq(void)
> d = pirq_dpci->dom;
> smp_mb(); /* 'd' MUST be saved before we set/clear the bits. */
> if ( test_and_set_bi
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.
All which is really required is the ability to slurp in or write out a
blob of bytes t
Add support for handling PMU interrupts for PV guests.
VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hyper
This is a small series of libxl patches I received off-list from
Ian Jackson. The patches fix a few issues I found when converting
the libvirt libxl driver to use a single libxl_ctx. Patch 2 has
been modified slightly to address off-list comments from Wei Liu.
Ian Jackson (3):
libxl: In domain
>>> On 17.03.15 at 15:54, wrote:
> On Tue, Mar 17, 2015 at 09:42:21AM +0100, Sander Eikelenboom wrote:
>> I'm still running with this first simple stopgap patch from Konrad,
>> and it has worked fine for me since.
>
> I believe the patch that Sander and Malcom had been running is the best
> candi
On Tue, 2015-03-17 at 15:27 +, Wei Liu wrote:
> This looks most interesting as it implies we can easily pipe a console
> to it.
BTW, rather than rawe consoles we should probably consider using the
channel extension: http://xenbits.xen.org/docs/unstable/misc/channel.txt
Ian.
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 already part
of the output of dumping domains info.
Instead, print the intersection between hard
affinity and online
On Tue, 17 Mar 2015, Anthony PERARD wrote:
> 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 ac
Take 2. Some of the patches have been checked-in already, so here's what's
remaining:
- fix a bug in the RTDS scheduler (patch 1),
- improve how the whole process of dumping scheduling info is serialized,
by moving all locking code into specific schedulers (patch 2),
- print more useful sched
being serviced by the RTDS scheduler, as that is a
legit situation to be in: think, for instance, of a
newly created RTDS cpupool, with no domains migrated
to it yet.
While there:
- move the spinlock acquisition up, to effectively
protect the domain list and avoid races;
- the mask of online
On Mon, Mar 16, 2015 at 10:05:38AM +, PRAMOD DEVENDRA wrote:
> From: Pramod Devendra
>
> Signed-off-by: Pramod Devendra
> CC: Ian Jackson
> CC: Stefano Stabellini
> CC: Ian Campbell
> CC: Wei Liu
> ---
> tools/libxl/libxl_qmp.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion
On Mon, Mar 16, 2015 at 10:06:50AM +, PRAMOD DEVENDRA wrote:
> From: Pramod Devendra
>
> Signed-off-by: Pramod Devendra
> CC: Ian Jackson
> CC: Stefano Stabellini
> CC: Ian Campbell
> CC: Wei Liu
Acked-by: Wei Liu
> ---
> tools/libxc/xc_linux_osdep.c |1 +
> 1 file changed, 1 ins
On Tue, Mar 17, 2015 at 03:15:17PM +, Anthony PERARD wrote:
> 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.
> >
> >
From: Ian Jackson
Unlock the userdata before we actually call xc_domain_destroy. This
leaves open the possibility that other libxl callers will see the
half-destroyed domain (with no devices, paused), but this is fine.
Signed-off-by: Ian Jackson
CC: Wei Liu
Reviewed-by: Jim Fehlig
Tested-by:
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, trailing
whitespace, parentheses and blank lin
From: Ian Jackson
From: Ian Jackson
When domain_death_xswatch_callback needed a further call to
xc_domain_getinfolist it would restart it with the last domain it
found rather than the first one it wants.
If it only wants one it will also only ask for one domain. The result
would then be that
more specifically, for each runqueue, print what pCPUs
belong to it, which ones are idle and which ones have
been tickled.
While there, also convert the whole file to use
keyhandler_scratch for printing cpumask-s.
Signed-off-b: Dario Faggioli
Cc: George Dunlap
Cc: Jan Beulich
Cc: Keir Fraser
Most callers have this available already, and the functions don't need
any vcpu specifics.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1416,9 +1416,8 @@ do {
//shadow-types.h to shadow-priva
On Mon, Mar 16, 2015 at 10:12:34AM +, Koushik Chakravarty wrote:
> Signed-off-by: Koushik Chakravarty
> CC: Ian Jackson
> CC: Stefano Stabellini
> CC: Ian Campbell
> CC: Wei Liu
Acked-by: Wei Liu
Ian J, this one should be backported to 4.5.
> ---
> tools/libxl/libxl_json.c |2 +-
>
- drop an effectively unused struct pv_vcpu field (x86)
- adjust VM_ASSIST() to prepend VMASST_TYPE_
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -901,7 +901,6 @@ int arch_set_info_guest(
v->arch.pv_vcpu.event_callback_cs = c(event_callback_cs);
Changes in v19:
* Do not allow changing mode to/from OFF/ALL while guests are
running. This significantly simplifies code due
to large number of corner cases that I had to deal with. Most of the
changes are in patch#5. This also makes patch 4 from last version
unnecessary
* Defer NMI supp
Xen L4 entries being uniformly installed into any L4 table and 64-bit
PV kernels running in ring 3 means that user mode was able to see the
read-only M2P presented by Xen to the guests. While apparently not
really representing an exploitable information leak, this still very
certainly was never mea
There is race when we clear the STATE_SCHED in the softirq
- which allows the 'raise_softirq_for' (on another CPU or
on the one running the softirq) to schedule the dpci.
Specifically this can happen when the other CPU receives
an interrupt, calls 'raise_softirq_for', and puts the dpci
on its per-
Export Xen's symbols as {} triplet via new XENPF_get_symbol
hypercall
Signed-off-by: Boris Ostrovsky
Acked-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/platform_hypercall.c | 28 +++
xen/common/sym
On Mon, Mar 16, 2015 at 10:09:29AM +, Koushik Chakravarty wrote:
> Signed-off-by: Koushik Chakravarty
> CC: Ian Jackson
> CC: Stefano Stabellini
> CC: Ian Campbell
> CC: Wei Liu
> ---
> tools/libxl/libxl_dm.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --
Forgot to Cc people in the cover letter of the series... Sorry!
Forwarded Message
From: Dario Faggioli
To: Xen-devel
Subject: [PATCH v2 0/5] Improving dumping of scheduler related info
Date: Tue, 17 Mar 2015 16:32:41 +0100
Mailer: StGit/0.17.1-dirty
Message-Id: <20150317152615.
Move some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
---
xen/arch/x86/hvm/svm/vpmu.c | 106 --
xen/arch/x86/hvm/vmx/vpmu_core2.c | 151 ++
From: Ian Jackson
Call xc_domain_destroy in a subprocess. That allows us to do so
asynchronously, rather than blocking the whole process calling libxl.
The changes in detail:
* Provide an libxl__ev_child in libxl__domain_destroy_state, and
initialise it in libxl__domain_destroy. There is
On 03/10/2015 08:03 AM, 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 i
The main point of the series is really patch 1 (which after consultation
among the security team doesn't appear to represent a security fix);
the other two are just cleanup that I found possible/desirable while
putting together the first one.
1: x86: allow 64-bit PV guest kernels to suppress user
Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.
Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets
Code for initializing/tearing down PMU for PV guests
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Acked-by: Daniel De Graaf
---
Changes in v19:
* Keep track of PV(H) VPMU count for non-dom0 VPMUs
* Move vpmu.xenpmu_data test in pvpmu_init() under lock
* Return better error codes in pvpm
vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/include/asm-x86/domain.h | 2 ++
xen/include/asm-x86/hvm/vcpu.h
e.g., with `xl debug-key r', like this:
(XEN) Online Cpus: 0-15
(XEN) Free Cpus: 8-15
Also, for each cpupool, print the set of pCPUs it
contains, like this:
(XEN) Cpupool 0:
(XEN) Cpus: 0-7
(XEN) Scheduler: SMP Credit Scheduler (credit)
Signed-off-by: Dario Faggioli
Cc: Juergen Gros
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
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 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
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
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
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:
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
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
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_
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
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 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
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
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
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
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
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.
>
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
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 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
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 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 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
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 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
>>> 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 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 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 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 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 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
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 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
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 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 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
1 - 100 of 163 matches
Mail list logo