>>> On 22.01.16 at 04:36, wrote:
> By the way, do you think it's possible to make grant table support bigger
> page e.g 64K?
> One grant-ref per 64KB instead of 4KB, this should able to reduce the grant
> entry consumption significantly.
How would that work with an underlying page size of 4k, a
>>> On 21.01.16 at 19:15, wrote:
> On 21/01/16 17:21, Andrew Cooper wrote:
>> On 21/01/16 17:02, Jan Beulich wrote:
>> On 16.12.15 at 22:24, wrote:
case 0x8001:
-/* Modify Feature Information. */
-if ( is_pv_32bit_domain(currd) )
-{
-
>>> On 21.01.16 at 18:21, wrote:
> On 21/01/16 17:02, Jan Beulich wrote:
> On 16.12.15 at 22:24, wrote:
>>> case 0x8001:
>>> -/* Modify Feature Information. */
>>> -if ( is_pv_32bit_domain(currd) )
>>> -{
>>> -__clear_bit(X86_FEATURE_LM % 32, &d);
>>> On 22.01.16 at 02:56, wrote:
> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>>At the very least it would need to be avoided by denying the request.
>>Upon shared use, either all parties agree, or only one may use the
>>clock. And passing through a (platform) device would theref
On Wed, Jan 20 2016, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 23, 2015 at 10:06:24PM +0100, Julia Lawall wrote:
>> The cleancache_ops structure is never modified, so declare it as const.
>>
>> This also removes the __read_mostly declaration on the cleancache_ops
>> variable declaration, since
flight 78700 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78700/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
test-amd64-amd64-
flight 78686 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 11 guest-start fail REGR. vs. 78620
Regressions which
flight 78683 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78683/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail like 78509
Tests which did not succeed,
On 1/21/2016 11:06 PM, Tianyang Chen wrote:
Budget replenishment and enforcement are separated by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.
A new runningq has been added to keep track of all vcpus that
are on pcpus.
The following f
Budget replenishment and enforcement are separated by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.
A new runningq has been added to keep track of all vcpus that
are on pcpus.
The following functions have major changes to manage the runnin
Current RTDS scheduler is time driven and is called every 1ms.
During each scheduler call, the repl_update() scans both runq
and depeletedq, which might not be necessary every 1ms.
Since each vcpu is implemented as a deferable server, budget is
preserved during its period and refilled in the ne
On 2016/1/19 1:03, Stefano Stabellini wrote:
> On Fri, 15 Jan 2016, Shannon Zhao wrote:
>> > From: Shannon Zhao
>> >
>> > When running on Xen hypervisor, runtime services are supported through
>> > hypercall. So call Xen specific function to initialize runtime services.
>> >
>> > Signed-off-by
On 01/21/2016 08:19 PM, Ian Campbell wrote:
> On Thu, 2016-01-21 at 10:56 +, David Vrabel wrote:
>> On 20/01/16 12:23, Ian Campbell wrote:
>>> There have been a few reports recently[0] which relate to a failure of
>>> netfront to allocate sufficient grant refs for all the queues:
>>>
>>> [
This patch refactors struct rangeset to base it on the red-black
tree structure, instead of on the current doubly linked list. By
now, ioreq leverages rangeset to keep track of the IO/memory
resources to be emulated. Yet when number of ranges inside one
ioreq server is very high, traversing a doubl
A new parameter - max_wp_ram_ranges is added to set the upper limit
of write-protected ram ranges to be tracked inside one ioreq server
rangeset.
Ioreq server uses a group of rangesets to track the I/O or memory
resources to be emulated. Default limit of ranges that one rangeset
can allocate is se
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each. This
patch uses a seperate rangeset for the guest r
XenGT leverages ioreq server to track and forward the accesses to
GPU I/O resources, e.g. the PPGTT(per-process graphic translation
tables). Currently, ioreq server uses rangeset to track the BDF/
PIO/MMIO ranges to be emulated. To select an ioreq server, the
rangeset is searched to see if the I/O
Hi Ian and Stefano,
On Thu, Jan 21, 2016 at 04:11:45PM +, Stefano Stabellini wrote:
>On Thu, 21 Jan 2016, Ian Campbell wrote:
>> On Thu, 2016-01-21 at 12:55 +, Stefano Stabellini wrote:
>> > On Thu, 21 Jan 2016, Peng Fan wrote:
>> > > Hi Ian,
>> > >
>> > > On Thu, Jan 21, 2016 at 12:26:04
On 01/21/16 07:52, Jan Beulich wrote:
> >>> On 21.01.16 at 15:01, wrote:
> > On 01/21/16 03:25, Jan Beulich wrote:
> >> >>> On 21.01.16 at 10:10, wrote:
> >> > b) some _DSMs control PMEM so you should filter out these kind of _DSMs
> >> > and
> >> > handle them in hypervisor.
> >>
> >> Not
Hi Ian,
On Thu, Jan 21, 2016 at 12:49:24PM +, Ian Campbell wrote:
>On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote:
>> On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
>> > Would adding a dummy fixed-clock[0] (or several of them) to the guest
>> > passthrough DT satisfy the driv
Hi Jan,
On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
On 21.01.16 at 13:06, wrote:
>> On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote:
>> On 21.01.16 at 09:59, wrote:
uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm.
passthrough uart2, hypervisor
flight 78670 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254
test-armhf-armhf-xl
On 01/21/16 16:25, Luis R. Rodriguez wrote:
>>
>> Basically, if the hardware is enumerable using standard PC mechanisms (PCI,
>> ACPI) and doesn't need a special boot flow it should use type 0.
>
> I can extend the documentation as part of this to be clear.
>
> I will note though that this still
On Thu, Jan 21, 2016 at 03:56:35PM -0800, H. Peter Anvin wrote:
> On 01/21/16 14:25, Luis R. Rodriguez wrote:
> > On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
> > wrote:
> >>> Sure, do we know if that ICC compatible? Do we care? There are a
> >>> series of ICC hacks put in place on ipxe'
On Wed, Jan 20, 2016 at 2:20 PM, H. Peter Anvin wrote:
> On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez"
> wrote:
>>On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote:
>>> On 01/20/16 13:33, Luis R. Rodriguez wrote:
That's correct for PV and PVH, likewise when qemu is requi
On Thu, Jan 21, 2016 at 11:52 AM, H. Peter Anvin wrote:
> On 01/21/16 11:50, H. Peter Anvin wrote:
>>
>> Right... we already do that.
>>
>> I don't even think you need to initialize any tables. At least on i386,
>> we have to do this in assembly code. However, it is just a simple table
>> walk.
On 01/21/16 14:25, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
> wrote:
>>> Sure, do we know if that ICC compatible? Do we care? There are a
>>> series of ICC hacks put in place on ipxe's original solution which
>>> I've folded in, it seems that works but if w
On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
wrote:
>> Sure, do we know if that ICC compatible? Do we care? There are a
>> series of ICC hacks put in place on ipxe's original solution which
>> I've folded in, it seems that works but if we care about ICC those
>> folks should perhaps help
flight 78658 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78658/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 60684
test-amd64
On Thu, Jan 21, 2016 at 12:33:43PM -0800, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 12:19 PM, H. Peter Anvin wrote:
> > On 12/17/15 20:40, H. Peter Anvin wrote:
> >>>
> >>> const struct
> >>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
> >>>
> >>> const struc
On 01/21/16 12:05, Luis R. Rodriguez wrote:
>
>> At least on i386,
>> we have to do this in assembly code.
>
> Neat! How is that order kept?
>
Right now subarch_entries[] is just an array indexed by subarch number
hardcoded in head_32.S.
However, if you have a list of (id, target) then you cou
On Thu, Jan 21, 2016 at 04:47:29PM +0100, Julia Lawall wrote:
> The cleancache_ops structure is never modified, so declare it as const.
>
> Done with the help of Coccinelle.
I will pull it in my tree and sent it to Linus.
Thanks!
>
> Signed-off-by: Julia Lawall
>
> ---
>
> v2: put back the r
flight 78640 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs.
78529
test-amd64-
On Thu, Jan 21, 2016 at 12:19 PM, H. Peter Anvin wrote:
> On 12/17/15 20:40, H. Peter Anvin wrote:
>>>
>>> const struct
>>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
>>>
>>> const struct
>>> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
>>> tablename
This run is configured for baseline tests only.
flight 38679 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38679/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-
On 12/17/15 20:40, H. Peter Anvin wrote:
>>
>> const struct
>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
>>
>> const struct
>> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
>> tablename__end[0];
>>
(Over)thinking about this some more, I suggest using
Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8
(xen: switch to linear virtual mapped sparse p2m list), which
appeared in 3.19, introduced linear virtual mapped sparse p2m
list. If readmem() reads p2m then it access this list using
physical addresses. Sadly, VMA to physical address tra
On Thu, Jan 21, 2016 at 11:50 AM, H. Peter Anvin wrote:
>> The PV init code would kick in early and could parse the
>> boot_params.hdr.hardware_subarch_data pointer as it sees fit.
>>
>
> Right... we already do that.
>
> I don't even think you need to initialize any tables.
The init above is for
On Thu, 21 Jan 2016, Rasmus Villemoes wrote:
> On Wed, Jan 20 2016, Konrad Rzeszutek Wilk wrote:
>
> > On Wed, Dec 23, 2015 at 10:06:24PM +0100, Julia Lawall wrote:
> >> The cleancache_ops structure is never modified, so declare it as const.
> >>
> >> This also removes the __read_mostly decla
On 01/21/16 11:50, H. Peter Anvin wrote:
>
> Right... we already do that.
>
> I don't even think you need to initialize any tables. At least on i386,
> we have to do this in assembly code. However, it is just a simple table
> walk. :)
>
It might make more sense to make subarch its own table,
On 01/21/16 11:46, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin wrote:
>>> And that's exactly what HVMlite does. Most of this shim layer is setting
>>> up boot_params, after which we jump to standard x86 boot path (i.e.
>>> startup_{32|64}). With hardware_subarch set
On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin wrote:
>> And that's exactly what HVMlite does. Most of this shim layer is setting
>> up boot_params, after which we jump to standard x86 boot path (i.e.
>> startup_{32|64}). With hardware_subarch set to zero.
>
> Which is the way to do it as long a
On 01/21/16 05:45, Boris Ostrovsky wrote:
>> I don't think the hypervisor should be setting Linux specific boot
>> related parameters, the boot ABI should be OS agnostic. IMHO, a small
>> shim should be added to Linux in order to set what Linux requires when
>> entering from a Xen entry point.
For
flight 78621 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78621/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
77687
Regressions
On Jan 5, 10:04am, Oleksii Kurochko wrote:
} Subject: Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initial
> Hey.
Hi Oleksii, I hope this note finds your day going well.
> Strange for me was that I got vmid=0 and gen_type=0, so I decided go
> to i915_gem_vgtbuffer_ioctl and write ne
Roger Pau Monné writes ("Re: [PATCH v4 1/6] libelf: rewrite symtab/strtab
loading for Dom0"):
> El 21/01/16 a les 18.29, Ian Jackson ha escrit:
> > Roger Pau Monne writes ("[PATCH v4 1/6] libelf: rewrite symtab/strtab
> > loading for Dom0"):
> >> #define elf_hdr_elm(_elf, _hdr, _elm, _val) \
Ian Campbell wrote:
> ... and consolidate the cmdline/extra/root parsing to facilitate doing
> so.
>
> The logic is the same as xl's parse_cmdline from the current xen.git master
> branch (e6f0e099d2c17de47fd86e817b1998db903cab61).
>
> On the formatting side switch to producing cmdline= instead o
On 21/01/16 17:21, Andrew Cooper wrote:
> On 21/01/16 17:02, Jan Beulich wrote:
> On 16.12.15 at 22:24, wrote:
>>> @@ -864,69 +865,27 @@ void pv_cpuid(struct cpu_user_regs *regs)
>>>
>>> cpuid_count(a, c, &a, &b, &c, &d);
>>>
>>> -if ( (regs->eax & 0x7fff) == 0x0001 )
>>>
flight 78697 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78697/
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
El 21/01/16 a les 18.29, Ian Jackson ha escrit:
> Roger Pau Monne writes ("[PATCH v4 1/6] libelf: rewrite symtab/strtab loading
> for Dom0"):
>> Current implementation of elf_load_bsdsyms is broken when loading inside of
>> a HVM guest, because it assumes elf_memcpy_safe is able to write into gues
ilable in the git repository at:
>
>
> git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160121
>
> for you to fetch changes up to 5a11d0f7549e24a10e178a9dc8ff5e698031d9a6:
>
> Xen PCI passthru
Wei Liu writes ("Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands"):
> Or rewrite every adhoc parser with bison/flex or Ocaml / Haskell parsec.
I endorse this product and/or service.
> Jokes aside. I will see what I can do. Consolidating them into helper
> functions is a good start.
Yes :-
From: Cao jin
Signed-off-by: Cao jin
Reviewed-by: Eric Blake
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_pt.c | 53 -
1 file changed, 28 insertions(+), 25 deletions(-)
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 9eef3df..d3322
Roger Pau Monne writes ("[PATCH v4 1/6] libelf: rewrite symtab/strtab loading
for Dom0"):
> Current implementation of elf_load_bsdsyms is broken when loading inside of
> a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
> memory space, which it is not.
>
> Take the oport
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -32,6 +32,9 @@ integer_param("cpuid_mask_ext_ecx", opt_cpuid_mask_ext_ecx);
> unsigned int __devinitdata opt_cpuid_mask_ext_edx = ~0u;
> integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ex
On 21/01/16 17:02, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> @@ -864,69 +865,27 @@ void pv_cpuid(struct cpu_user_regs *regs)
>>
>> cpuid_count(a, c, &a, &b, &c, &d);
>>
>> -if ( (regs->eax & 0x7fff) == 0x0001 )
>> -{
>> -/* Modify Feature Information.
flight 78603 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 78487
test-amd64-amd64-xl-xs
flight 78610 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78610/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 77892
test-amd64-i386-rumpuserxen-i
From: Markus Armbruster
xen_ram_alloc() dies with hw_error() on error, even though its caller
ram_block_add() handles errors just fine. Add an Error **errp
parameter and use it.
Leave case RUN_STATE_INMIGRATE alone, because that looks like some
kind of warning.
Signed-off-by: Markus Armbruster
>>> On 16.12.15 at 22:24, wrote:
> Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
> commandline-provided masks would take effect in Xen's view of the features.
>
> As the masks got applied after the query for features, the redundant call to
> generic_identify() would
On 21/01/16 17:05, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> Later changes will add to this logic.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
> And actually looks like this is pretty independent of the earlier patches,
> and hence could go in right away?
It ce
>>> On 16.12.15 at 22:24, wrote:
> Later changes will add to this logic.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
And actually looks like this is pretty independent of the earlier patches,
and hence could go in right away?
Jan
__
>>> On 16.12.15 at 22:24, wrote:
> @@ -864,69 +865,27 @@ void pv_cpuid(struct cpu_user_regs *regs)
>
> cpuid_count(a, c, &a, &b, &c, &d);
>
> -if ( (regs->eax & 0x7fff) == 0x0001 )
> -{
> -/* Modify Feature Information. */
> -if ( !cpu_has_apic )
> -
From: Cao jin
And assert the snprintf() error, because user can do nothing in case of
snprintf() fail.
Signed-off-by: Cao jin
Reviewed-by: Stefano Stabellini
Reviewed-by: Eric Blake
---
hw/xen/xen-host-pci-device.c | 35 +++
1 file changed, 11 insertions(+),
From: Cao jin
To catch the error message. Also modify the caller
Signed-off-by: Cao jin
Reviewed-by: Eric Blake
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_pt.c |7 +--
hw/xen/xen_pt.h |3 ++-
hw/xen/xen_pt_graphics.c | 11 ++-
3 files changed, 13 i
m.git tags/xen-20160121
for you to fetch changes up to 5a11d0f7549e24a10e178a9dc8ff5e698031d9a6:
Xen PCI passthru: convert to realize() (2016-01-21 16:45:54 +)
Xen
If the frontend sets out_cons to a value higher than out_prod, it will
cause xenfb_handle_events to loop about 2^32 times. Avoid that by using
better checks at the beginning of the function.
Signed-off-by: Stefano Stabellini
Reported-by: Ling Liu
---
hw/display/xenfb.c |5 +++--
1 file chan
Add the PV block backend, the Xen mapcache, and hw/i386/xen to the list
of Xen related files maintained by me.
Signed-off-by: Stefano Stabellini
Reviewed-by: Markus Armbruster
---
MAINTAINERS |3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d8b0f36..e3d4
From: Cao jin
Signed-off-by: Cao jin
Reviewed-by: Stefano Stabellini
---
hw/i386/xen/xen_pvdevice.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/i386/xen/xen_pvdevice.c b/hw/i386/xen/xen_pvdevice.c
index c218947..9abcf25 100644
--- a/hw/i386/xen/xen_pvd
From: Cao jin
To catch the error message. Also modify the caller
Signed-off-by: Cao jin
Reviewed-by: Stefano Stabellini
Reviewed-by: Eric Blake
---
hw/xen/xen-host-pci-device.c | 102 +++---
hw/xen/xen-host-pci-device.h |5 ++-
hw/xen/xen_pt.c
From: Markus Armbruster
xen_hvm_init() returns -1 without cleaning up on some errors (harmless
long as the caller exit()s on error), dies with hw_error() on others.
hw_error() isn't approprate here. Clean up to exit() on all errors.
Signed-off-by: Markus Armbruster
Reviewed-by: Stefano Stabell
From: Cao jin
No need to roll our own (with slightly incorrect handling of errno),
when we can use the common version.
Change signed parsing to unsigned, because what it read are values in
PCI config space, which are non-negative.
Signed-off-by: Cao jin
Reviewed-by: Stefano Stabellini
Reviewe
flight 78618 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78618/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 3 host-install(3) broken REGR. vs. 78528
test-amd64-i386-xl-qemuu-w
From: Cao jin
To catch the error message. Also modify the caller
Signed-off-by: Cao jin
Reviewed-by: Eric Blake
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_pt.c |8 ---
hw/xen/xen_pt.h |2 +-
hw/xen/xen_pt_config_init.c | 51 +++---
And use it as the default value for the VGA kind. This allows libxl to set
it to the default value later on when the domain type is known. For HVM
guests the default value is LIBXL_VGA_INTERFACE_TYPE_CIRRUS while for
HVMlite the default value is LIBXL_VGA_INTERFACE_TYPE_NONE.
Signed-off-by: Roger
Allow enabling or disabling emulated devices from the libxl domain
configuration file. For HVM guests with a device model all the emulated
devices are enabled. For HVM guests without a device model no devices are
enabled by default, although they can be enabled using the options provided.
The arbit
Joao Martins wrote:
> As suggested in a previous thread [0] this patch adds some missing calls
> to libxl_dominfo_{init,dispose} when doing some of the libxl_domain_info
> operations which would otherwise lead to memory leaks.
>
> [0]
> https://www.redhat.com/archives/libvir-list/2015-September/ms
Add a new HVM-specific feature flag that signals the presence of a bitmap
that contains the current set of enabled emulated devices. The bitmap is
placed in the ecx register. The bit fields used in the bitmap are the same
as the ones used in the xen_arch_domainconfig emulation_flags field, and
thei
Hello,
The series is sorted in the following way:
- Patch 1 is a preparatory patch for Dom0 HVMlite support.
- Patch 4 is a fix from a fallout introduced by the HVMlite series, which
inadvertently disabled the emulated PIT that was added to PV(H) guests.
- Patches 2, 3 and 5 expand the field
libxl__arch_domain_prepare_config has access to the libxl_domain_build_info
struct, so make sure it's properly initialised. Note that prepare_config is
called from within libxl__domain_make.
This is not a bug at the moment, because prepare_config doesn't access
libxl_domain_build_info yet, but thi
Current implementation of elf_load_bsdsyms is broken when loading inside of
a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
memory space, which it is not.
Take the oportunity to do some cleanup and properly document how
elf_{parse/load}_bsdsyms works. The new implementa
This fixes the fallout from the HVMlite series, that removed the emulated
PIT from PV(H) guests. Also, this patch forces the hardware domain to
always have an emulated PIT, regardless of whether the toolstack specified
one or not.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Coo
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -278,11 +278,16 @@ unsigned int xstate_ctxt_size(u64 xcr0)
> /* Collect the information of processor's extended state */
> void xstate_init(struct cpuinfo_x86 *c)
> {
> +static bool_t __initdat
>>> On 20.01.16 at 16:01, wrote:
> Initially reported to debian
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here:
>
> With AMD Opteron 6xxx processors, half of the memory controllers are
> missing from /sys/devices/system/edac/mc
> Checked with single 6120 (dual memory
>>> On 21.01.16 at 17:16, wrote:
>> On January 20, 2016 at 7:29 pm, wrote:
>> >>> On 20.01.16 at 11:26, wrote:
>> >> On January 15, 2016 at 9:10, wrote:
>> >> >>> On 23.12.15 at 09:25, wrote:
>> >> > @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
>> >> > return 0;
>>
flight 78649 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
test-amd64-amd64-
flight 78659 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78659/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
Ian Campbell wrote:
> On Wed, 2016-01-20 at 11:16 -0700, Jim Fehlig wrote:
>> Ian Campbell wrote:
>>> ... and consolidate the cmdline/extra/root parsing to facilitate doing
>>> so.
>>>
>>> The logic is the same as xl's parse_cmdline from the current xen.git
>>> master
>>> branch (e6f0e099d2c17de47f
> On January 20, 2016 at 7:29 pm, wrote:
> >>> On 20.01.16 at 11:26, wrote:
> >> On January 15, 2016 at 9:10, wrote:
> >> >>> On 23.12.15 at 09:25, wrote:
> >> > @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
> >> > return 0;
> >> > }
> >> >
> >> > +static void dev_inv
On Thu, 21 Jan 2016, Ian Campbell wrote:
> On Thu, 2016-01-21 at 12:55 +, Stefano Stabellini wrote:
> > On Thu, 21 Jan 2016, Peng Fan wrote:
> > > Hi Ian,
> > >
> > > On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
> > > > On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> > > >
El 21/01/16 a les 12.31, Wei Liu ha escrit:
> On Thu, Jan 21, 2016 at 11:01:43AM +0100, Roger Pau Monné wrote:
>> El 21/01/16 a les 10.39, Ian Campbell ha escrit:
>>> On Wed, 2016-01-20 at 19:33 +0100, Roger Pau Monné wrote:
El 20/01/16 a les 14.01, Ian Campbell ha escrit:
> On Wed, 2016-0
The cleancache_ops structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
v2: put back the read mostly
drivers/xen/tmem.c |2 +-
include/linux/cleancache.h |2 +-
mm/cleancache.c|4 ++--
3 files c
On Thu, Jan 21, 2016 at 04:35:40PM +0100, Roger Pau Monné wrote:
> El 21/01/16 a les 16.29, Ian Campbell ha escrit:
> > On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
> >> My patch b2700877 "move and amend multicast control documentation"
> >> clarified use of the multicast control protocol
On Thu, Jan 21, 2016 at 03:29:36PM +, Ian Campbell wrote:
> On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
> > My patch b2700877 "move and amend multicast control documentation"
> > clarified use of the multicast control protocol between frontend and
> > backend. However, it transpires
El 21/01/16 a les 16.29, Ian Campbell ha escrit:
> On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
>> My patch b2700877 "move and amend multicast control documentation"
>> clarified use of the multicast control protocol between frontend and
>> backend. However, it transpires that the restric
On Fri, 2015-12-18 at 16:08 +, Malcolm Crossley wrote:
>
> xen/arch/arm/mm.c | 4 +-
[...]
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 47bfb27..81f9e2e 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1055,7 +1055,7 @@ int xenmem_add_to_physmap_on
On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
> My patch b2700877 "move and amend multicast control documentation"
> clarified use of the multicast control protocol between frontend and
> backend. However, it transpires that the restrictions that documentation
> placed on the "request-mult
On Thu, Jan 21, 2016 at 8:44 PM, Dario Faggioli
wrote:
> On Wed, 2016-01-20 at 03:06 -0700, Jan Beulich wrote:
>> > > > On 19.01.16 at 20:55, wrote:
>> >
>> > $ 'addr2line -e xen-syms 82d0801c1cce' returns
>> > 'xen/xen/arch/x86/xstate.c:387' which again points to
>> > xsave. Also, adding 'xs
On Fri, 2015-12-18 at 16:08 +, Malcolm Crossley wrote:
> diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
> index 71e7649..c308a56 100644
> --- a/xen/include/asm-arm/percpu.h
> +++ b/xen/include/asm-arm/percpu.h
> @@ -27,6 +27,11 @@ void percpu_init_areas(void);
> #defi
On Fri, 2015-12-18 at 14:09 +, David Vrabel wrote:
> atomic_compareandswap() used atomic_t as the new, old and returned
> values which is less convinient than using just int.
"convenient"
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
> index 5a38c67..29ab265 100644
1 - 100 of 173 matches
Mail list logo
