>>> On 24.11.15 at 08:48, wrote:
> On 2015/11/24 15:22, Jan Beulich wrote:
> On 24.11.15 at 04:08, wrote:
>>> On 2015/11/24 0:59, Jan Beulich wrote:
>>> On 17.11.15 at 10:40, wrote:
> + if ( !table_header )
> + {
> + printk("Table header not present\n");
> +
>>> On 24.11.15 at 04:27, wrote:
> 2015-11-23 10:00 GMT-05:00 Jan Beulich :
> On 23.11.15 at 15:50, wrote:
>>> What are the rules again, then? Dario is a scheduler maintainer, and
>>> Meng is an established contributor. I thought that was enough.
>>
>> My understanding is that patches by ma
Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list,
usb-attach and usb-detach.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usbctrl-attach test_vm version=1 ports=8
#xl usb-list test_vm
will show the usb controllers and port usage under th
Add xl usb-assignable-list command to list assignable USB devices.
Assignable USB device means the USB device type is assignable and
it's not assigned to any guest yet.
Signed-off-by: Chunyan Liu
---
Same as "libxl: add libxl_device_usb_assignable_list API" patch,
this patch could be sqaushe
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Reviewed-by: Wei Liu
---
Changes:
* fix indentation
tools/libxl/libxl.c | 5 ++---
tools/libxl/libxl_internal.h | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
inde
Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.
Signed-off-by: Chunyan Liu
---
Changes:
- write a separate function libxl__read_sysfs_file_contents, no
longer mix with libxl_read_file_contents
tools/libxl/libxl_intern
Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.
One could specify usb controllers and usb devices in config file
like t
Add API for listing assignable USB devices info.
Assignable USB device means the USB device type is assignable and
it's not assigned to any guest yet.
Signed-off-by: Chunyan Liu
---
This could be squashed with previous patch. Split because there is
some dispute on this. If this is acceptable, co
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
---
changes:
- update DEFINE_DEVICE_REMOVE instead of crea
This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.
Changes to V8:
* lots of changes in libxl pvusb API (patch 3/7)
* update 2/7 to write separate read_sysfs_file function
* address all other comm
>>> On 24.11.15 at 08:56, wrote:
>> From: Wu, Feng
>> Sent: Tuesday, November 24, 2015 3:54 PM
>> > From: Tian, Kevin
>> > Sent: Tuesday, November 24, 2015 3:45 PM
>> > > +/* Setup/Update interrupt remapping table entry. */
>> > > +setup_posted_irte(&new_ire, &old_ire, pi_desc, gvec);
>>
>>> On 24.11.15 at 07:55, wrote:
> What about:
>
> 4) Instead of relying on the kernel maintained p2m list for m2p
>conversion use the hypervisor maintained m2p list which should be
>available in the dump as well. This is the way the alive kernel is
>working, so mimic it during crash
>>> On 24.11.15 at 00:54, wrote:
> flight 65028 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65028/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd
>>> On 23.11.15 at 21:06, wrote:
> Some people reported that after applying v2 of my patches they cannot build
> xen.gz due to following error:
>
> objdump -h reloc.o | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
> while read idx name sz rest; do \
> case "$name" in \
>
flight 65047 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 60684
test-amd64
Currently those places which want this open code a lookup of the
{ident}_suite runvar with a fallback to the configuration file.
However selecthost was missing such a lookup in the case where it is
constructing a nested L1 host (which begins from the selectguest
template), which lead to ts-xen-ins
On Mon, 2015-11-23 at 17:05 +, Ian Campbell wrote:
Adding Daniel who I should have included the first time, plus a few
more thoughts from me at the end.
> On Wed, 2015-11-11 at 15:03 +, Ian Jackson wrote:
> > > XXX consider combining into a single namespace (i.e. with
> > > xengnttab_hand
On 24/11/15 08:59, Jan Beulich wrote:
On 24.11.15 at 07:55, wrote:
>> What about:
>>
>> 4) Instead of relying on the kernel maintained p2m list for m2p
>>conversion use the hypervisor maintained m2p list which should be
>>available in the dump as well. This is the way the alive kernel
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Jan Beulich
> Sent: 24 November 2015 07:33
> To: Andrew Cooper
> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Xen-devel;
> Stefano Stabellini; Shannon Zhao
On 24/11/15 09:55, Malcolm Crossley wrote:
> On 24/11/15 08:59, Jan Beulich wrote:
> On 24.11.15 at 07:55, wrote:
>>> What about:
>>>
>>> 4) Instead of relying on the kernel maintained p2m list for m2p
>>>conversion use the hypervisor maintained m2p list which should be
>>>available in
On Tue, 24 Nov 2015 10:09:01 +
David Vrabel wrote:
> On 24/11/15 09:55, Malcolm Crossley wrote:
> > On 24/11/15 08:59, Jan Beulich wrote:
> > On 24.11.15 at 07:55, wrote:
> >>> What about:
> >>>
> >>> 4) Instead of relying on the kernel maintained p2m list for m2p
> >>>conversion use
On 24/11/15 09:56, Paul Durrant wrote:
>> -Original Message-
>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>> boun...@lists.xen.org] On Behalf Of Jan Beulich
>> Sent: 24 November 2015 07:33
>> To: Andrew Cooper
>> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; X
Am 20.11.15 um 08:57 schrieb Jan Beulich:
What you list above seems pretty normal indeed. However, why don't you
simply look at the options actually passed to gcc when building the
hypervisor. And you should also not forget that your distro's gcc
build itself may have certain non-standard optio
>>> On 23.11.15 at 17:36, wrote:
> I instrumented detect_extended_topology() and ran again with 4 CPUs.
>[...]
> (XEN) smp_store_cpu_info id=3
> (XEN) detect_extended_topology cpuid_count op=0xb count=0 eax=0x0 ebx=0x1
> ecx=0x100 edx=0x6
> (XEN) detect_extended_topology initial_apicid=6 core_plu
On 24/11/15 10:17, Petr Tesarik wrote:
> On Tue, 24 Nov 2015 10:09:01 +
> David Vrabel wrote:
>
>> On 24/11/15 09:55, Malcolm Crossley wrote:
>>> On 24/11/15 08:59, Jan Beulich wrote:
>>> On 24.11.15 at 07:55, wrote:
> What about:
>
> 4) Instead of relying on the kernel mainta
On Tue, Nov 24, 2015 at 10:28 AM, Andrew Cooper
wrote:
>> Could we also perhaps deprecate this whole mechanism at this point? I added
>> HVMOP_set_evtchn_upcall_vector quite a while ago now.
>
> January, so Xen 4.6 is the only release with this hvmop in.
Come on -- if you're not rebuilding from
>>> On 24.11.15 at 11:32, wrote:
> Am 20.11.15 um 08:57 schrieb Jan Beulich:
>> What you list above seems pretty normal indeed. However, why don't you
>> simply look at the options actually passed to gcc when building the
>> hypervisor. And you should also not forget that your distro's gcc
>> b
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Refactor gic-v3 related functions into dt and generic parts. This will be
> helpful when adding acpi support for gic-v3.
>
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/gic-v3.c | 95
> ++
On 24/11/15 07:50, Jan Beulich wrote:
On 24.11.15 at 06:04, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Monday, November 23, 2015 10:28 PM
>>>
>> On 21.10.15 at 05:16, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, October 20, 2015
On 24/11/15 10:55, Andrew Cooper wrote:
> On 24/11/15 07:50, Jan Beulich wrote:
> On 24.11.15 at 06:04, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, November 23, 2015 10:28 PM
>>> On 21.10.15 at 05:16, wrote:
>> From: Jan Beulich [mailto:jbeul...@
On Wed, Nov 4, 2015 at 5:17 PM, Dario Faggioli
wrote:
> Hi,
>
> This series, improves how inserting vCPUs in schedulers runqueues is done,
> including fixing a couple of bugs, and paving the way for more improvement in
> Credit2 runqueue handling (will be submitted as a separate series).
>
> v3 is
>>> On 24.11.15 at 11:59, wrote:
> On 24/11/15 10:55, Andrew Cooper wrote:
>> On 24/11/15 07:50, Jan Beulich wrote:
>> On 24.11.15 at 06:04, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, November 23, 2015 10:28 PM
>
On 21.10.15 at 05:16, wrote:
>
Hi everyone,
I’m looking at the code of domain_kill() to understand how a dying domain
releases its resources.
If I’m understanding correctly, physical memory is released by gradually
releasing the page tables and updating the page_info associated to each entry
to decrement reference counters u
On 24/11/15 11:04, Jan Beulich wrote:
On 24.11.15 at 11:59, wrote:
>> On 24/11/15 10:55, Andrew Cooper wrote:
>>> On 24/11/15 07:50, Jan Beulich wrote:
>>> On 24.11.15 at 06:04, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, November 23, 2015 10:28 PM
>>
On 23/11/15 15:24, Jan Beulich wrote:
On 23.11.15 at 16:01, wrote:
>> On 23/11/15 12:49, Jan Beulich wrote:
>>> @@ -1525,6 +1516,16 @@ static void vmx_inject_trap(struct hvm_t
>>> __restore_debug_registers(curr);
>>> write_debugreg(6, read_debugreg(6) | DR_STEP);
>>>
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 24 November 2015 10:29
> To: Paul Durrant; Jan Beulich
> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Xen-devel;
> Stefano Stabellini; Shannon Zhao
> Subject: Re: [Xen-devel] [PATCH] publi
Ian Campbell writes ("[PATCH v3] Set {ident}_suite runvar when install a Debian
guest."):
> Currently those places which want this open code a lookup of the
> {ident}_suite runvar with a fallback to the configuration file.
>
> However selecthost was missing such a lookup in the case where it is
>
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> Add generic way to use device from acpi similar to the way it is
> supported in device tree.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/device.c| 19 +++
>
On Thu, Nov 19, 2015 at 01:02:36PM -0700, Alex Williamson wrote:
> On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote:
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursday, November 19, 2015 2:12 AM
> > >
> > > [cc +qemu-devel, +paolo, +gerd]
> > >
> > > Another
>>> On 17.11.15 at 10:40, wrote:
> From: Bob Moore
>
> ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4
>
> One new 64-bit field at the end of the table.
> FADT version is now 6.
>
> Link: https://github.com/acpica/acpica/commit/72b0b674
> Signed-off-by: Bob Moore
> Signed-off-by: Lv Z
>>> On 24.11.15 at 11:58, wrote:
> I’m looking at the code of domain_kill() to understand how a dying domain
> releases its resources.
> If I’m understanding correctly, physical memory is released by gradually
> releasing the page tables and updating the page_info associated to each entry
> to
On Wed, Nov 4, 2015 at 5:17 PM, Dario Faggioli
wrote:
> The insert_vcpu() hook is handled with inconsistent locking.
> In fact, schedule_cpu_switch() calls the hook with runqueue
> lock held, while sched_move_domain() relies on the hook
> implementations to take the lock themselves (and, since tha
On Tue, Nov 24, 2015 at 10:58 AM, Simula wrote:
> Hi everyone,
> I’m looking at the code of domain_kill() to understand how a dying domain
> releases its resources.
> If I’m understanding correctly, physical memory is released by gradually
> releasing the page tables and updating the page_info a
On Tue, 2015-11-24 at 11:03 +, George Dunlap wrote:
> On Wed, Nov 4, 2015 at 5:17 PM, Dario Faggioli
> wrote:
> >
> > There is a git branch for this series here:
> > git://xenbits.xen.org/people/dariof/xen.git rel/sched/fix-vcpu-
> > ins-rem-v4
>
> BTW this branch somehow got named
> "dari
On Tue, Nov 24, 2015 at 12:19:18PM +0100, Daniel Vetter wrote:
> Downside: Tracking mapping changes on the guest side won't be any easier.
> This is mostly a problem for integrated gpus, since discrete ones usually
> require contiguous vram for scanout. I think saying "don't do that" is a
> valid o
Am 20.11.15 um 00:53 schrieb Andrew Cooper:
On 19/11/2015 20:02, Atom2 wrote:
Am 19.11.15 um 02:06 schrieb Andrew Cooper:
Thanks! That is what I was looking for.
Sadly, it is less useful than I was hoping. The guest is not appearing
to do anything interesting which causes the bad state; it is
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
> First get the GIC version from GIC Distributor. Then parse GIC related
> subtables, collect CPU interface and distributor addresses and call
> driver
Ping?
On 17/11/15 15:51, Juergen Gross wrote:
> pte_update_defer can be removed as it is always set to the same
> function as pte_update. So any usage of pte_update_defer() can be
> replaced by pte_update().
>
> pmd_update and pmd_update_defer are always set to paravirt_nop, so they
> can just be
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Like GICv2, ACPI on Xen hypervisor uses MADT table for proper GICv3
> initialization. Parse GIC distributor subtable, redistributor subtable
> and interrupt subtable.
>
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/a
flight 38328 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start fail REGR. vs. 38299
test-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, November 24, 2015 4:52 PM
>
> >>> On 24.11.15 at 08:56, wrote:
> >> From: Wu, Feng
> >> Sent: Tuesday, November 24, 2015 3:54 PM
> >> > From: Tian, Kevin
> >> > Sent: Tuesday, November 24, 2015 3:45 PM
> >> > > +/* Setup/Update
Hi,
> > Yes, vGPU may have additional features, like a framebuffer area, that
> > aren't present or optional for direct assignment. Obviously we support
> > direct assignment of GPUs for some vendors already without this feature.
>
> For exposing framebuffers for spice/vnc I highly recommend a
On Tue, 2015-11-24 at 11:17 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH v3] Set {ident}_suite runvar when install a
> Debian guest."):
> > Currently those places which want this open code a lookup of the
> > {ident}_suite runvar with a fallback to the configuration file.
> >
> > Howev
El 20/11/15 a les 16.37, Jan Beulich ha escrit:
On 18.11.15 at 17:37, wrote:
>> --- a/xen/include/xen/hvm/save.h
>> +++ b/xen/include/xen/hvm/save.h
>> @@ -60,6 +60,8 @@ void _hvm_read_entry(struct hvm_domain_context *h,
>> */
>> #define _hvm_load_entry(_x, _h, _dst, _strict) ({
V Tue, 24 Nov 2015 10:35:03 +
Andrew Cooper napsáno:
> On 24/11/15 10:17, Petr Tesarik wrote:
> > On Tue, 24 Nov 2015 10:09:01 +
> > David Vrabel wrote:
> >
> >> On 24/11/15 09:55, Malcolm Crossley wrote:
> >>> On 24/11/15 08:59, Jan Beulich wrote:
> >>> On 24.11.15 at 07:55, wrote:
On 11/23/15 10:37, Boris Ostrovsky wrote:
> On 11/22/2015 12:54 PM, Haozhong Zhang wrote:
> >Hi Jan, Boris and Aravind,
> >
> >(Sorry for sending such a long email and thanks for your patience)
>
> First, thank you very much for doing this.
>
> >
> >Because this patchset also touches the existing
>>> On 24.11.15 at 13:54, wrote:
> El 20/11/15 a les 16.37, Jan Beulich ha escrit:
> On 18.11.15 at 17:37, wrote:
>>> --- a/xen/include/xen/hvm/save.h
>>> +++ b/xen/include/xen/hvm/save.h
>>> @@ -60,6 +60,8 @@ void _hvm_read_entry(struct hvm_domain_context *h,
>>> */
>>> #define _hvm_load_
El 20/11/15 a les 16.49, Jan Beulich ha escrit:
On 18.11.15 at 17:37, wrote:
>> @@ -2091,7 +2092,8 @@ static int hvm_load_cpu_ctxt(struct domain *d,
>> hvm_domain_context_t *h)
>> struct xsave_struct *xsave_area = v->arch.xsave_area;
>>
>> memcpy(v->arch.xsave_area, ctxt.
El 24/11/15 a les 14.06, Jan Beulich ha escrit:
On 24.11.15 at 13:54, wrote:
>> El 20/11/15 a les 16.37, Jan Beulich ha escrit:
>> On 18.11.15 at 17:37, wrote:
--- a/xen/include/xen/hvm/save.h
+++ b/xen/include/xen/hvm/save.h
@@ -60,6 +60,8 @@ void _hvm_read_entry(struct h
On Tue, Nov 24, 2015 at 01:38:55PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > Yes, vGPU may have additional features, like a framebuffer area, that
> > > aren't present or optional for direct assignment. Obviously we support
> > > direct assignment of GPUs for some vendors already without this f
>>> On 24.11.15 at 14:10, wrote:
> El 20/11/15 a les 16.49, Jan Beulich ha escrit:
> On 18.11.15 at 17:37, wrote:
>>> @@ -2091,7 +2092,8 @@ static int hvm_load_cpu_ctxt(struct domain *d,
>>> hvm_domain_context_t *h)
>>> struct xsave_struct *xsave_area = v->arch.xsave_area;
>>>
>>>
>>> On 24.11.15 at 13:57, wrote:
> V Tue, 24 Nov 2015 10:35:03 +
> Andrew Cooper napsáno:
>
>> On 24/11/15 10:17, Petr Tesarik wrote:
>> > On Tue, 24 Nov 2015 10:09:01 +
>> > David Vrabel wrote:
>> >
>> >> On 24/11/15 09:55, Malcolm Crossley wrote:
>> >>> On 24/11/15 08:59, Jan Beulich
On Tue, 2015-11-24 at 12:41 +, Ian Campbell wrote:
> On Tue, 2015-11-24 at 11:17 +, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH v3] Set {ident}_suite runvar when install
> > a
> > Debian guest."):
> > > Currently those places which want this open code a lookup of the
> > > {ident}_s
On 24/11/15 13:39, Jan Beulich wrote:
On 24.11.15 at 13:57, wrote:
>> V Tue, 24 Nov 2015 10:35:03 +
>> Andrew Cooper napsáno:
>>
>>> On 24/11/15 10:17, Petr Tesarik wrote:
On Tue, 24 Nov 2015 10:09:01 +
David Vrabel wrote:
> On 24/11/15 09:55, Malcolm Crossley wro
On 24/11/15 13:41, Andrew Cooper wrote:
> On 24/11/15 13:39, Jan Beulich wrote:
> On 24.11.15 at 13:57, wrote:
>>> V Tue, 24 Nov 2015 10:35:03 +
>>> Andrew Cooper napsáno:
>>>
On 24/11/15 10:17, Petr Tesarik wrote:
> On Tue, 24 Nov 2015 10:09:01 +
> David Vrabel wrote:
>
On Tue, 2015-11-24 at 10:35 +, Andrew Cooper wrote:
> On 24/11/15 10:17, Petr Tesarik wrote:
> > On Tue, 24 Nov 2015 10:09:01 +
> > David Vrabel wrote:
> >
> > > On 24/11/15 09:55, Malcolm Crossley wrote:
> > > > On 24/11/15 08:59, Jan Beulich wrote:
> > > > > > > > On 24.11.15 at 07:55,
flight 65053 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65053/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-libvirt-vhd 9 debian-di-install fail REGR. vs. 63089
Tests which did not
>>> On 24.11.15 at 14:46, wrote:
> On Tue, 2015-11-24 at 10:35 +, Andrew Cooper wrote:
>> On 24/11/15 10:17, Petr Tesarik wrote:
>> > On Tue, 24 Nov 2015 10:09:01 +
>> > David Vrabel wrote:
>> >
>> > > On 24/11/15 09:55, Malcolm Crossley wrote:
>> > > > On 24/11/15 08:59, Jan Beulich wro
flight 65072 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65072/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Hi,
> But there's some work to add generic mmap support to dma-bufs, and for
> really simple case (where we don't have a gl driver to handle the dma-buf
> specially) for untiled framebuffers that would be all we need?
Not requiring gl is certainly a bonus, people might want build qemu
without o
On Tue, Nov 24, 2015 at 2:34 AM, Jan Beulich wrote:
> Indeed, and I think I had said so. The algorithm does, however, tell
> us that with the above output CPU 3 (APIC ID 6) is on socket 6 (both
> shifts being zero), which for the whole system results in sockets 1,
> 3, and 5 unused. While not expl
Ian Campbell writes ("Re: [PATCH v3] Set {ident}_suite runvar when install a
Debian guest."):
> On Tue, 2015-11-24 at 11:17 +, Ian Jackson wrote:
> > If you do this instead
> > +$gho->{Suite} //= guest_var($gho,'suite',undef);
> > the previous line (`return ... if') is not needed.
>
> D
On Tue, Nov 24, 2015 at 03:12:31PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > But there's some work to add generic mmap support to dma-bufs, and for
> > really simple case (where we don't have a gl driver to handle the dma-buf
> > specially) for untiled framebuffers that would be all we need?
>
>
On 11/24/2015 08:05 AM, Haozhong Zhang wrote:
This bug can be fixed either later by patch 5 which introduces a
common function hvm_scale_tsc() to scale TSC, or by replacing above
underlined code with a simplified and inlined version of
hvm_scale_tsc() as below:
uint64_t mul
>>> Tue, 16 Jun 2015 15:48:16 +0100 Stefano Stabellini wrote:
>On Tue, 16 Jun 2015, Jan Beulich wrote:
>> >>> On 16.06.15 at 15:35, Stefano Stabellini wrote:
>> > On Fri, 5 Jun 2015, Jan Beulich wrote:
I'm sorry for getting back to this only now.
>> >> @@ -322,6 +323,13 @@ static int xen_pt_msix_
On 11/24/15 21:05, Haozhong Zhang wrote:
[...]
> > >
> > > This bug can be fixed either later by patch 5 which introduces a
> > > common function hvm_scale_tsc() to scale TSC, or by replacing above
> > > underlined code with a simplified and inlined version of
> > > hvm_scale_tsc() as below
On Tue, 24 Nov 2015, kbuild test robot wrote:
arch/x86/xen/time.c: In function 'xen_pvclock_gtod_notify':
> >> arch/x86/xen/time.c:139:35: warning: passing argument 1 of
> >> 'timespec_compare' from incompatible pointer type
> >> [-Wincompatible-pointer-types]
> if (!was_set && timespec_
El 24/11/15 a les 14.34, Jan Beulich ha escrit:
On 24.11.15 at 14:10, wrote:
>> El 20/11/15 a les 16.49, Jan Beulich ha escrit:
>> On 18.11.15 at 17:37, wrote:
@@ -2091,7 +2092,8 @@ static int hvm_load_cpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
struct xs
It's unused and wrong (we already have MAC_LOCAL_APIC and MAX_APICS).
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -37,7 +37,6 @@ extern void (*mtrr_hook) (void);
extern void zap_low_mappings(void);
-#define MAX_APICID 256
extern u32 x86_cpu
We have several outstanding patch series which add devices that have
two levels: a controller and individual devices attached to that
controller.
In the interest of consistency, this patch introduces a section that
sketches out a template for interfaces for such devices.
Signed-off-by: George Dun
On 24/11/15 14:38, Jan Beulich wrote:
> It's unused and wrong (we already have MAC_LOCAL_APIC and MAX_APICS).
MAX_LOCAL_APIC
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xe
Now that we intercept them all, there's no reason not to also uniformly
hand them to XSM. Reads (which are expected to be of less interest) get
handled as before (MMCFG accesses un-audited).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -7,6 +7,7 @@
#include
Hi Eric
In fact we would like to have Linux-stubdom. Just that when it was
first posted back then we didn't know where to put it. Xen tree is not
an option. Now that Raisin is here it seems a good fit.
On Mon, Nov 23, 2015 at 02:52:47AM -0500, Eric Shelton wrote:
> Wei and others,
>
> It has bee
On 11/20/2015 11:35 AM, Stefano Stabellini wrote:
On Fri, 20 Nov 2015, Boris Ostrovsky wrote:
After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate descriptors for legacy interrupts if PIC does not
exis
On 11/24/2015 09:36 AM, Stefano Stabellini wrote:
On Tue, 24 Nov 2015, kbuild test robot wrote:
arch/x86/xen/time.c: In function 'xen_pvclock_gtod_notify':
arch/x86/xen/time.c:139:35: warning: passing argument 1 of 'timespec_compare'
from incompatible pointer type [-Wincompatible-pointer
>>> On 24.11.15 at 15:38, wrote:
> El 24/11/15 a les 14.34, Jan Beulich ha escrit:
> On 24.11.15 at 14:10, wrote:
>>> El 20/11/15 a les 16.49, Jan Beulich ha escrit:
>>> On 18.11.15 at 17:37, wrote:
> @@ -157,6 +159,8 @@ struct hvm_hw_cpu {
> };
> /* error code for
Hi Maxim,
On Fri, 2015-11-13 at 20:26 -0700, Jim Fehlig wrote:
> On 11/13/2015 10:00 AM, Dario Faggioli wrote:
> > Hello,
> >
> > The Xen Project's automated test suite is failing at running its
> > libvirt tests for a few time, like this:
> >
> > On Wed, 2015-11-04 at 09:04 +, osstest servi
On Tue, 24 Nov 2015, Boris Ostrovsky wrote:
> > On Tue, 24 Nov 2015, kbuild test robot wrote:
> > arch/x86/xen/time.c: In function 'xen_pvclock_gtod_notify':
> > > > > arch/x86/xen/time.c:139:35: warning: passing argument 1 of
> > > > > 'timespec_compare' from incompatible pointer type
> > > >
On 24/11/15 15:40, George Dunlap wrote:
> We have several outstanding patch series which add devices that have
> two levels: a controller and individual devices attached to that
> controller.
>
> In the interest of consistency, this patch introduces a section that
> sketches out a template for int
1: MSI-X: latch MSI-X table writes
2: MSI-X: really enforce alignment
3: pass-through: correctly deal with RW1C bits
4: [RFC] MSI: re-expose masking capability
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists
Currently those places which want this open code a lookup of the
{ident}_suite runvar with a fallback to the configuration file.
However selecthost was missing such a lookup in the case where it is
constructing a nested L1 host (which begins from the selectguest
template), which lead to ts-xen-ins
The remaining log message in pci_msix_write() is wrong, as there guest
behavior may only appear to be wrong: For one, the old logic didn't
take the mask-all bit into account. And then this shouldn't depend on
host device state (i.e. the host may have masked the entry without the
guest having done s
The way the generic infrastructure works the intention of not allowing
unaligned accesses can't be achieved by simply setting .unaligned to
false. The benefit is that we can now replace the conditionals in
{get,set}_entry_value() by assert()-s.
Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stab
Now that the hypervisor intercepts all config space writes and monitors
changes to the masking flags, this undoes the main effect of the
XSA-129 fix, exposing the masking capability again to guests.
Signed-off-by: Jan Beulich
---
TBD: We probably need to deal with running on an older hypervisor.
Introduce yet another mask for them, so that the generic routine can
handle them, at once rendering xen_pt_pmcsr_reg_write() superfluous.
Signed-off-by: Jan Beulich
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -113,6 +113,8 @@ struct XenPTRegInfo {
uint32_t res_mask;
/* reg read only
>>> On 24.11.15 at 15:13, wrote:
> On Tue, Nov 24, 2015 at 2:34 AM, Jan Beulich wrote:
>> Bottom line - for the moment I do not see a reasonable way of
>> dealing with that situation. The closest I could see would be what
>> we iirc had temporarily during the review cycles of the initial CAT
>> s
On Tue, 2015-11-24 at 15:14 +, Ian Campbell wrote:
> ---
> I've run an adhoc test with:
> OSSTEST_JOBS_ONLY=
> OSSTEST_JOBS_ONLY=$OSSTEST_JOBS_ONLY:build-amd64
> OSSTEST_JOBS_ONLY=$OSSTEST_JOBS_ONLY:build-amd64-pvops
> OSSTEST_JOBS_ONLY=$OSSTEST_JOBS_ONLY:test-amd64-amd64-qemuu-nested # nested
On Tue, 2015-11-24 at 15:26 +, Ian Campbell wrote:
> On Tue, 2015-11-24 at 15:14 +, Ian Campbell wrote:
> > ---
> > I've run an adhoc test with:
> > OSSTEST_JOBS_ONLY=
> > OSSTEST_JOBS_ONLY=$OSSTEST_JOBS_ONLY:build-amd64
> > OSSTEST_JOBS_ONLY=$OSSTEST_JOBS_ONLY:build-amd64-pvops
> > OSSTEST
On Tue, 2015-11-24 at 15:28 +, Ian Campbell wrote:
> On Tue, 2015-11-24 at 15:26 +, Ian Campbell wrote:
> > On Tue, 2015-11-24 at 15:14 +, Ian Campbell wrote:
> > > ---
> > > I've run an adhoc test with:
> > > OSSTEST_JOBS_ONLY=
> > > OSSTEST_JOBS_ONLY=$OSSTEST_JOBS_ONLY:build-amd64
> >
On 13/11/15 17:10, Dario Faggioli wrote:
> In fact, with 2 cpupools, one (the default) Credit and
> one Credit2 (with at least 1 pCPU in the latter), trying
> a (e.g., ACPI S3) suspend/resume crashes like this:
>
> (XEN) [ 150.587779] [ Xen-4.7-unstable x86_64 debug=y Not tainted
> ]
1 - 100 of 225 matches
Mail list logo
