Please look at
"http://xhypervisor.org/pdf/Embedded_Hypervisor_Xvisor_A_comparative_analysis.pdf";.
On Friday, December 9, 2016 11:30 AM, Konrad Rzeszutek Wilk
wrote:
On Fri, Dec 09, 2016 at 06:50:03PM +, Jason Long wrote:
> Hello.
> I like to see Xen developer ideas and concerns about "
I see "http://www.xvisor-x86.org/wiki/Main_Page"; and they want move it to x86.
On Friday, December 9, 2016 11:30 AM, Konrad Rzeszutek Wilk
wrote:
On Fri, Dec 09, 2016 at 06:50:03PM +, Jason Long wrote:
> Hello.
> I like to see Xen developer ideas and concerns about "Xvisor" hypervisor. A
This run is configured for baseline tests only.
flight 68188 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68188/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops
On 12/09/2016 06:00 PM, Thomas Gleixner wrote:
On Fri, 9 Dec 2016, Boris Ostrovsky wrote:
On 12/09/2016 05:06 PM, Thomas Gleixner wrote:
On Thu, 8 Dec 2016, Thomas Gleixner wrote:
Boris, can you please verify if that makes the
topology_update_package_map() call which you placed into the Xen
On 12/09/2016 06:02 PM, Boris Ostrovsky wrote:
On 12/09/2016 05:06 PM, Thomas Gleixner wrote:
On Thu, 8 Dec 2016, Thomas Gleixner wrote:
Boris, can you please verify if that makes the
topology_update_package_map() call which you placed into the Xen cpu
starting code obsolete ?
Will do. I di
The rt variable can only be 0 or 7, no need to check if it's 15.
Coverity-ID: 1381835
Signed-off-by: Stefano Stabellini
diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c
index c6f49a5..decd9dd 100644
--- a/xen/arch/arm/decode.c
+++ b/xen/arch/arm/decode.c
@@ -58,11 +58,6 @@ static int
Forgot to CC Jan again.
On Fri, 9 Dec 2016, Stefano Stabellini wrote:
> HorizontalResolution and VerticalResolution are 32bit, while size is
> 64bit. As it stands multiplications are evaluated with 32bit arithmetic,
> which could overflow. Cast HorizontalResolution to 64bit to avoid that.
>
> Cov
On Thu, 8 Dec 2016, Oleksandr Tyshchenko wrote:
> On Thu, Dec 8, 2016 at 9:39 PM, Julien Grall wrote:
> >
> >
> > On 08/12/16 17:06, Oleksandr Tyshchenko wrote:
> >>
> >> Hi Julien,
> >
> >
> > Hi Oleksandr,
> Hi Julien,
>
> thank you for sharing your opinion.
>
> >
> > As discussed on IRC, I CC
flight 103103 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103103/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 14 guest-saverestore.2 fail REGR.
vs. 103036
test-a
On Fri, 9 Dec 2016, Andre Przywara wrote:
> >> I've been spending some time thinking about this, and I think we can in
> >> fact get away without ever propagating command from domains to the host.
> >>
> >> I made a list of all commands that possible require host ITS command
> >> propagation. There
On Mon, Oct 10, 2016 at 08:32:24AM +0800, Haozhong Zhang wrote:
> The host pmem pages mapped to a domain are unassigned at domain destroy
> so as to be used by other domains in future.
>
> Signed-off-by: Haozhong Zhang
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/domain.c
On Mon, Oct 10, 2016 at 08:32:23AM +0800, Haozhong Zhang wrote:
> XENMEM_populate_pmemmap is used by toolstack to map given host pmem pages
> to given guest pages. Only pages in the data area of a pmem region are
> allowed to be mapped to guest.
>
> Signed-off-by: Haozhong Zhang
> ---
> Cc: Ian J
On Mon, Oct 10, 2016 at 08:32:22AM +0800, Haozhong Zhang wrote:
> Xen hypervisor does not include a pmem driver. Instead, it relies on the
> pmem driver in Dom0 to report the PFN ranges of the entire pmem region,
> its reserved area and data area via XENPF_pmem_add. The reserved area is
> used by X
flight 103089 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103089/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737
test-amd64-amd64-xl
On Mon, Oct 10, 2016 at 08:32:21AM +0800, Haozhong Zhang wrote:
> A reserved area on each pmem region is used to place the M2P table.
> However, it's not at the beginning of the pmem region, so we need to
> specify the location explicitly when creating the M2P table.
>
> Signed-off-by: Haozhong Zh
On Mon, Oct 10, 2016 at 08:32:20AM +0800, Haozhong Zhang wrote:
> A reserved area on each pmem region is used to place the frame table.
> However, it's not at the beginning of the pmem region, so we need to
> specify the location explicitly when extending the frame table.
>
> Signed-off-by: Haozho
On 12/09/2016 10:50 AM, Ross Lagerwall wrote:
> When relocating the p2m/initrd, take special care not to relocate it so
> that is overlaps with the current location of the p2m/initrd. This is
> needed since the full extent of the current location is not marked as a
> reserved region in the e820 (an
flight 103102 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103102/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 102942
Regressions which
On Fri, 9 Dec 2016, Andre Przywara wrote:
> On 07/12/16 20:20, Stefano Stabellini wrote:
> > On Tue, 6 Dec 2016, Julien Grall wrote:
> >> On 06/12/2016 22:01, Stefano Stabellini wrote:
> >>> On Tue, 6 Dec 2016, Stefano Stabellini wrote:
> moving a vCPU with interrupts assigned to it is slower
On Fri, 9 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 07/12/16 20:20, Stefano Stabellini wrote:
> > On Tue, 6 Dec 2016, Julien Grall wrote:
> > > On 06/12/2016 22:01, Stefano Stabellini wrote:
> > > > On Tue, 6 Dec 2016, Stefano Stabellini wrote:
> > > > > moving a vCPU with interrupts assi
This patch relocates mem_access components that are currently mixed with p2m
code into separate files. This better aligns the code with similar subsystems,
such as mem_sharing and mem_paging, which are already in separate files. There
are no code-changes introduced, the patch is mechanical code mov
The only caller of this function is get_page_from_gva which already takes
a vcpu pointer as input. Pass this along to make the function in-line with
its intended use-case.
Signed-off-by: Tamas K Lengyel
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
xen/arch/arm/p2m.c | 11 ++-
1 file
On Fri, 9 Dec 2016, Julien Grall wrote:
> Hi Oleksandr,
>
> Thank you for the patch.
>
> On 06/12/16 17:53, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > Remove one layer of "if" by reordering the check
> > in route_irq_to_guest() to make code more clearer.
> >
> > Signed-
On 09/12/16 19:55, Boris Ostrovsky wrote:
> On 12/09/2016 02:01 PM, Andrew Cooper wrote:
>> Hello,
>>
>> While working on XSA-192, I found a curious thing. On AMD hardware, the
>> VMMCALL instruction appears to behave like a nop if executed in VM86
>> mode. All other processor modes work fine.
>>
On 12/09/2016 02:01 PM, Andrew Cooper wrote:
> Hello,
>
> While working on XSA-192, I found a curious thing. On AMD hardware, the
> VMMCALL instruction appears to behave like a nop if executed in VM86
> mode. All other processor modes work fine.
>
> The documentation suggests it should be valid i
On 09/12/16 19:31, Stefano Stabellini wrote:
> On Fri, 9 Dec 2016, Juergen Gross wrote:
>> On 09/12/16 00:50, Stefano Stabellini wrote:
>>> On Thu, 8 Dec 2016, Andrew Cooper wrote:
On 08/12/2016 19:18, Stefano Stabellini wrote:
> On Thu, 8 Dec 2016, Andrew Cooper wrote:
>> On 08/12/16
HorizontalResolution and VerticalResolution are 32bit, while size is
64bit. As it stands multiplications are evaluated with 32bit arithmetic,
which could overflow. Cast HorizontalResolution to 64bit to avoid that.
Coverity-ID: 1381858
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- remov
pa_range_info has only 8 elements and is accessed using pa_range as
index. pa_range is initialized to 16, potentially causing out of bound
access errors. Fix the issue by checking that pa_range is not greater
than the size of the array.
Coverity-ID: 1381865
Signed-off-by: Stefano Stabellini
dif
On Fri, 9 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 09/12/16 01:40, Stefano Stabellini wrote:
> > On Thu, 8 Dec 2016, Stefano Stabellini wrote:
> > > pa_range_info has only 8 elements and is accessed using pa_range as
> > > index. pa_range is initialized to 16, potentially causing out of
On Fri, 9 Dec 2016, Artem Mygaiev wrote:
> Hi Stefano
>
> On 09.12.16 02:59, Stefano Stabellini wrote:
> > Add missing vgic_unlock_rank on the error path in
> > gic_remove_irq_from_guest.
> >
> > CID: 1381843
> >
> > Signed-off-by: Stefano Stabellini
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/
On Fri, 9 Dec 2016, Juergen Gross wrote:
> On 09/12/16 00:50, Stefano Stabellini wrote:
> > On Thu, 8 Dec 2016, Andrew Cooper wrote:
> >> On 08/12/2016 19:18, Stefano Stabellini wrote:
> >>> On Thu, 8 Dec 2016, Andrew Cooper wrote:
> On 08/12/16 16:46, Juergen Gross wrote:
> > The first ro
On Fri, 2016-12-09 at 14:07 +0100, Dario Faggioli wrote:
> >
Thanks Dario and Wei Liu.
I am able to create VMs using XL toolstack and removing old xen and
libvirt packages. I think you both were right, I had double environment
problem.
Thanks once again for your suggestions.
> On Thu, 2016-12-0
On Fri, Dec 09, 2016 at 06:50:03PM +, Jason Long wrote:
> Hello.
> I like to see Xen developer ideas and concerns about "Xvisor" hypervisor. Any
> experiences and compares?
Um (https://github.com/xvisor/xvisor/blob/master/HOSTS), this:
M: x86_64 Generic
A: x86 64-bit
C: x86_64
On Fri, 9 Dec 2016, Jan Beulich wrote:
> >>> On 09.12.16 at 09:29, wrote:
> > On Fri, 2016-12-09 at 01:13 -0700, Jan Beulich wrote:
> >> > > > On 08.12.16 at 22:54, wrote:
> >> > Yeah, that was what was puzzling me too. Keeping them ordered has
> >> > the
> >> > nice property that if a user says
On 09/12/16 19:01, Stefano Stabellini wrote:
> On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
>> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
>>> On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
>> Should we have a section on new PV drivers? If so, I suggest to add
On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
> > On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
> > > > > Should we have a section on new PV drivers? If so, I suggest to add:
> > > > > - Xen transport for 9pfs
> > > >
Hello,
While working on XSA-192, I found a curious thing. On AMD hardware, the
VMMCALL instruction appears to behave like a nop if executed in VM86
mode. All other processor modes work fine.
The documentation suggests it should be valid in any situation, but I
never get a #VMEXIT from it. Thus
On 03/12/16 00:46, Stefano Stabellini wrote:
> On Fri, 2 Dec 2016, Andre Przywara wrote:
>> Hi,
Hi Stefano,
I started to answer this email some days ago, but then spend some time
on actually implementing what I suggested, hence the delay ...
>>
>> sorry for chiming in late
>>
>> I've been s
Hello.
I like to see Xen developer ideas and concerns about "Xvisor" hypervisor. Any
experiences and compares?
Thank you.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 08/12/16 12:20, Jan Beulich wrote:
>
>> However, it would also require only enabling the SVM GP intercept in the
>> hvm_update_guest_vendor() path (which should be renamed to something
>> slightly more generic like hvm_cpuid_policy_updated()).
> Why that? We always need it intercepted as long as
On Fri, Dec 9, 2016 at 2:27 AM, Jan Beulich wrote:
On 08.12.16 at 23:57, wrote:
>> --- a/xen/arch/x86/mm/Makefile
>> +++ b/xen/arch/x86/mm/Makefile
>> @@ -9,6 +9,7 @@ obj-y += guest_walk_3.o
>> obj-y += guest_walk_4.o
>> obj-y += mem_paging.o
>> obj-y += mem_sharing.o
>> +obj-y += mem_acc
This is unfortunate but appears to be necessary.
Signed-off-by: Ian Jackson
CC: pgsql-hack...@postgresql.org
---
Osstest/JobDB/Executive.pm | 45 -
tcl/JobDB-Executive.tcl| 6 --
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/
Hi. This message is going to xen-devel (because that's where the
osstest project is) and to pgsql-hackers (because I hope they may be
able to advise about the scope of the PostgreSQL SERIALIZABLE
constraint problem).
In summary: PostgreSQL only provides transaction serialisability for
successful
On 12/09/2016 01:15 PM, Andrew Cooper wrote:
> On 06/12/16 11:11, Andrew Cooper wrote:
>> On 05/12/16 20:59, Boris Ostrovsky wrote:
>>> On 12/05/2016 01:24 PM, Andrew Cooper wrote:
@@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int
*eax, unsigned int *ebx,
Aside from being excessively slow, CPUID is problematic: Linux runs
on a handful of CPUs that don't have CPUID. Use IRET-to-self
instead. IRET-to-self works everywhere, so it makes testing easy.
For reference, On my laptop, IRET-to-self is ~110ns,
CPUID(eax=1, ecx=0) is ~83ns on native and very
This reverts commit ed68d7e9b9cfb64f3045ffbcb108df03c09a0f98.
The patch wasn't quite correct -- there are non-Intel (and hence
non-486) CPUs that we support that don't have CPUID. Since we no
longer require CPUID for sync_core(), just revert the patch.
I think the relevant CPUs are Geode and Ela
The Intel microcode driver is using sync_core() to mean "do CPUID
with EAX=1". I want to rework sync_core(), but first the Intel
microcode driver needs to stop depending on its current behavior.
Reported-by: Henrique de Moraes Holschuh
Acked-by: Borislav Petkov
Signed-off-by: Andy Lutomirski
-
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/processor.h | 2 +-
1 file c
*** PATCHES 1 and 2 MAY BE 4.9 MATERIAL ***
Alan Cox pointed out that the 486 isn't the only supported CPU that
doesn't have CPUID. Let's clean up the mess and make everything
faster while we're at it.
Patch 1 is intended to be an easy fix: it makes sync_core() work
without CPUID on all 32-bit k
On 09/12/16 17:55, Paul Durrant wrote:
> ...if the domain is not under construction.
>
> If upstream QEMU is in use then it will explicitly create an ioreq server
> rather than implicitly creating the default ioreq server, which is a
> side-effect of reading HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_
...if the domain is not under construction.
If upstream QEMU is in use then it will explicitly create an ioreq server
rather than implicitly creating the default ioreq server, which is a
side-effect of reading HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_PFN,
or HVM_PARAM_BUFIOREQ_EVTCHN (as is done by
On 09/12/16 10:49, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
On 6 December 2016 at 21:14, Julien Grall wrote:
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -789,7 +789,8 @@ void __init start_xen(unsigned long
boot_phys_offset,
gic_init();
-p2m_vmid_allocat
On 06/12/16 11:11, Andrew Cooper wrote:
> On 05/12/16 20:59, Boris Ostrovsky wrote:
>> On 12/05/2016 01:24 PM, Andrew Cooper wrote:
>>> @@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int
>>> *eax, unsigned int *ebx,
>>> if ( !(hvm_pae_enabled(v) || hvm_long_mode_en
On 12/09/2016 12:10 PM, Ross Lagerwall wrote:
> Only mark a page as managed when it is released back to the allocator.
> This ensures that the managed page count does not get falsely increased
> when a VM is running. Correspondingly change it so that pages are
> marked as unmanaged after getting th
Hi,
On 07/12/16 20:20, Stefano Stabellini wrote:
> On Tue, 6 Dec 2016, Julien Grall wrote:
>> On 06/12/2016 22:01, Stefano Stabellini wrote:
>>> On Tue, 6 Dec 2016, Stefano Stabellini wrote:
moving a vCPU with interrupts assigned to it is slower than moving a
vCPU without interrupts assi
Hi Jan,
On 08/12/16 16:00, Jan Beulich wrote:
This brings it in line with most other functions dealing with CPU
masks. Convert both implementations to inline functions at once.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Regards,
--
Julien Grall
Hi Daniel,
On 05/12/16 22:25, Daniel Kiper wrote:
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on
Hi Stefano,
On 07/12/16 20:20, Stefano Stabellini wrote:
On Tue, 6 Dec 2016, Julien Grall wrote:
On 06/12/2016 22:01, Stefano Stabellini wrote:
On Tue, 6 Dec 2016, Stefano Stabellini wrote:
moving a vCPU with interrupts assigned to it is slower than moving a
vCPU without interrupts assigned t
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
[snip]
> > >
> > > This bug is caused by the read side effects of
> > > HVM_PARAM_IOREQ_PFN. The migration code needs a way of being
> able to
> > > query whether a default ioreq server exists, without crea
flight 103144 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103144/
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 1
On Fri, Dec 09, 2016 at 04:43:58PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> > Konrad Rzeszutek Wilk
> > Sent: 09 December 2016 16:14
> > To: Zhang Chen ; Paul Durrant
> >
> > Cc: Changlong Xie ; Wei Liu
>
On 09/12/16 15:22, Jan Beulich wrote:
> Move the looking at EFLAGS.DF into the macro, rendering all call sites
> more readable.
>
> Signed-off-by: Jan Beulich
The net change is ok; it is certainly cleaner to read in the body of
x86_emulate().
However, the naming of register_address_increment() w
>>> On 09.12.16 at 18:06, wrote:
> On 09/12/16 15:21, Jan Beulich wrote:
>> LODS, SCAS, and STOS all use the accumulator as one of their operands.
>> This avoids come open coding of things, but requires switching around
>
> Do you mean "some open coding" ?
Indeed I do - not sure what my fingers
Only mark a page as managed when it is released back to the allocator.
This ensures that the managed page count does not get falsely increased
when a VM is running. Correspondingly change it so that pages are
marked as unmanaged after getting them from the allocator.
Signed-off-by: Ross Lagerwall
>>> On 30.11.16 at 17:49, wrote:
> @@ -176,6 +177,8 @@ unsigned int __init dom0_max_vcpus(void)
> max_vcpus = opt_dom0_max_vcpus_max;
> if ( max_vcpus > MAX_VIRT_CPUS )
> max_vcpus = MAX_VIRT_CPUS;
> +if ( dom0_hvm )
> +max_vcpus = min_t(typeof(max_vcpus), max_vc
On 09/12/16 15:21, Jan Beulich wrote:
> LODS, SCAS, and STOS all use the accumulator as one of their operands.
> This avoids come open coding of things, but requires switching around
Do you mean "some open coding" ?
> operands of SCAS.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>>> On 30.11.16 at 17:49, wrote:
> @@ -1930,12 +1931,148 @@ static int __init hvm_setup_p2m(struct domain *d)
> #undef MB1_PAGES
> }
>
> +static int __init hvm_copy_to_phys(struct domain *d, paddr_t paddr, void
> *buf,
> + int size)
I guess you made size pla
On Fri, Dec 09, 2016 at 01:02:10PM +0100, Cedric Bosdonnat wrote:
> On Fri, 2016-12-09 at 11:25 +, Ian Jackson wrote:
> > Hi, Cedric et al. I like the idea of tidying this up. Thanks for the
> > patch, which (with some small changes) will be a good idea.
> >
> > Cedric Bosdonnat writes ("Re:
On Wed, Nov 30, 2016 at 06:38:45PM -0700, Jim Fehlig wrote:
> Hi All,
.. crickets..
>
> During the last Wg-openstack meetup we briefly discussed a long-standing bug
> when using Xen+libvirt+OpenStack with Neutron networking
>
> https://bugs.launchpad.net/nova/+bug/1450465
>
> The bug was also d
Hi Oleksandr,
Thank you for the patch.
On 06/12/16 17:53, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Remove one layer of "if" by reordering the check
in route_irq_to_guest() to make code more clearer.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
xen/arch/arm/irq.c
Hi Stefano,
On 09/12/16 01:40, Stefano Stabellini wrote:
On Thu, 8 Dec 2016, Stefano Stabellini wrote:
pa_range_info has only 8 elements and is accessed using pa_range as
index. pa_range is initialized to 16, potentially causing out of bound
access errors. Fix the issue by initializing pa_range
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Konrad Rzeszutek Wilk
> Sent: 09 December 2016 16:14
> To: Zhang Chen ; Paul Durrant
>
> Cc: Changlong Xie ; Wei Liu
> ; Eddie Dong ; Andrew
> Cooper ; Ian Jackson
> ; Wen Congyang ; Paul
> Durra
>>> On 30.11.16 at 17:49, wrote:
> @@ -302,7 +307,8 @@ static unsigned long __init compute_dom0_nr_pages(
> avail -= max_pdx >> s;
> }
>
> -need_paging = opt_dom0_shadow || (is_pvh_domain(d) &&
> !iommu_hap_pt_share);
> +need_paging = opt_dom0_shadow || (has_hvm_contai
osstest service owner writes ("[xen-unstable test] 103010: regressions -
trouble: broken/fail/pass"):
> flight 103010 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/103010/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which
Convert xl-disk-configuration.txt from plain text file to a POD file
to get it as a man page. The references to it in the other man pages
are also updated.
Signed-off-by: Cédric Bosdonnat
---
docs/INDEX | 1 -
docs/man/xl-disk-configuration.pod.5 | 529 +++
tscmode.txt is referenced in xl.cfg(5). Convert it into a pod
formatted man page.
Signed-off-by: Cédric Bosdonnat
---
docs/INDEX | 1 -
docs/{misc/tscmode.txt => man/tscmode.pod.7} | 109 ++-
docs/man/xl.cfg.pod.5.in
vtpmmgr.txt is referenced in a man page, convert it to a man page.
Signed-off-by: Cédric Bosdonnat
---
docs/{misc/vtpmmgr.txt => man/vtpmmgr.pod.7} | 351 ---
1 file changed, 206 insertions(+), 145 deletions(-)
rename docs/{misc/vtpmmgr.txt => man/vtpmmgr.pod.7} (54%)
d
Some of the docs/misc documents are written in markdown language.
As an effort to cleanup man pages these documents will be converted into
man pages. To avoid some more conversion, add rules to the docs/Makefile
to generate man pages out of markdown files as well as pod ones.
However, pandoc doesn
Make vbd-interface a man page, section7, as this document is
referenced in other man pages (xl-disk-configuration)
Signed-off-by: Cédric Bosdonnat
---
docs/INDEX| 1 -
docs/{misc/vbd-interface.txt => man/vbd-interface.markdown.7} | 0
2 files c
As pointed out in Ian and Andrew's emails on my recent docs improvement
attempt, getting the documents from docs/misc referenced in man pages
as man pages would would make these pages more visible for users. This
would also not break the docs html INDEX.
This series adds ability to write markdown
docs/misc/xl-numa-placement.markdown is referenced by xl.cfg.5 man page,
move it to a man page, section 7.
Signed-off-by: Cédric Bosdonnat
---
.../xl-numa-placement.markdown => man/xl-numa-placement.markdown.7} | 0
docs/man/xl.cfg.pod.5.in| 2
pci-device-reservations is references in xl.cfg(5), convert it as a man
page in pod format. The name is now prefixed with 'xen-' to avoid
possible name conflicts.
Signed-off-by: Cédric Bosdonnat
---
docs/man/xen-pci-device-reservations.pod.7 | 84 ++
docs/man/xl.cfg.p
Some of the docs/misc documents will need to go in man 7 section,
prepare docs/Makefile for it.
Signed-off-by: Cédric Bosdonnat
---
.gitignore| 1 +
docs/Makefile | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index a2f34a14cb..7584956383
vtpm.txt is referenced in xl.cfg man page. Convert it to pod,
move it to the man folder and update the reference.
Signed-off-by: Cédric Bosdonnat
---
docs/INDEX | 1 -
docs/{misc/vtpm.txt => man/vtpm.pod.7} | 364 +
docs/man/xl.cfg.po
Move docs/misc/xl-network-configuration.markdown to docs/man and
update the references to it in the other man pages.
Signed-off-by: Cédric Bosdonnat
---
docs/INDEX| 1 -
.../xl-network-configuration.markdown.5}
channel.txt is referenced in xl.cfg(5). Move it to man pages, section 7
Signed-off-by: Cédric Bosdonnat
---
.../channel.txt => man/xen-pv-channel.markdown.7}| 20 ++--
docs/man/xl.cfg.pod.5.in | 2 +-
2 files changed, 11 insertions(+), 11 deletion
On Fri, Dec 09, 2016 at 04:21:02PM +0800, Ken wrote:
> Hi all,
>
> I run the Ubuntu 16.04 server (2 vcpu/2G, Linux 4.4.0) on the Xen-4.1.2, and
> installed gcc through the CDROM used by 16.04 iso file, when I installed gcc
> that depends deb packages to decompress failed. But uploaded the ISO file
.snip..
> > If you can be more specific about what is broken in COLO we might be
> > able to devise a fix for you.
>
> My workmate have reported this BUG last year:
> https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02850.html
Paul, Andrew was asking about:
This bug is cau
>>> On 30.11.16 at 17:49, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -656,6 +656,23 @@ affinities to prefer but be not limited to the specified
> node(s).
>
> Pin dom0 vcpus to their respective pcpus
>
> +### dom0
> +> `= List of [ hvm
strcmp can do singificant work, and is found in some inner loops where
we search for the meaning of things we find in the image. We need to
avoid doing too much work.
So replace all calls to strcmp with elf_strcmp_safe.
Signed-off-by: Ian Jackson
---
xen/common/libelf/libelf-dominfo.c | 37 +++
Not used yet, so no functional change. We will need this in a moment.
Signed-off-by: Ian Jackson
---
xen/common/libelf/libelf-dominfo.c | 5 +++--
xen/include/xen/libelf.h | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/common/libelf/libelf-dominfo.c
b/xen
On Fri, Dec 09, 2016 at 06:40:07PM +0530, George John wrote:
> Hi all,
>
> I am a newbie in xen. I wish to know which all intel platforms support xen
> hypervisor?.
All the ones that can do 64-bit mode.
___
Xen-devel mailing list
Xen-devel@lists.xen.or
When relocating the p2m/initrd, take special care not to relocate it so
that is overlaps with the current location of the p2m/initrd. This is
needed since the full extent of the current location is not marked as a
reserved region in the e820 (and it shouldn't be since it is about to be
moved).
Thi
This will allow us to keep track of the total amount of work we are
doing. When it becomes excessive, we mark the ELF broken, and stop
processing.
This is a more robust way of preventing DoS problems by bad images
than attempting to prove, for each of the (sometimes rather deeply
nested) loops, t
All the loops which might go out of control, due to excessive shdrs,
have been decorated with elf_iter_ok. So there is no need for this
explicit (and rather crude) check.
(Anyway, the count was a 16-bit field, so the check was redundant.)
Signed-off-by: Ian Jackson
---
xen/common/libelf/libelf
When we use elf_mem*_unsafe, we need to check that we are not doing
too much work.
Ensure that a call to elf_iter_ok_counted is near every call to
elf_mem*_unsafe.
(At one call site, just have a comment instead.)
Signed-off-by: Ian Jackson
---
xen/common/libelf/libelf-dominfo.c | 1 +
xen/comm
In every `for' or `while' loop, either call elf_iter_ok, or explain
why it's not necessary. This is part of comprehensive defence against
out of control loops.
Signed-off-by: Ian Jackson
---
xen/common/libelf/libelf-dominfo.c | 22 +-
xen/common/libelf/libelf-loader.c | 8
Signed-off-by: Ian Jackson
---
xen/include/xen/libelf.h | 92
1 file changed, 92 insertions(+)
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 6436bd7..8b75242 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libe
We recently discovered two near-miss in libelf:
* The intended method for limiting the phdr loop iteration count was
not effective. But happily this turned not to be important because
the count field is only 16 bits.
* A recent commit accidentally introduced a division by zero
vulnerabilit
Now, elf_load_image eventually calls elf_memcpy_safe, which calls
elf_iter_ok_counted.
So there is a work limit of 4x the image size. This is larger than
the previous limit of 2x the image size, but it includes a lot of
other processing too. And the purpose is to reject bad images without
a sign
1 - 100 of 207 matches
Mail list logo
