On 01/20/2017 12:22 AM, Stefano Stabellini wrote:
On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/io/kbdif.h | 216 ++
1 file changed, 216 insertions(+)
flight 104296 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104296/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 104241
test-armhf-armhf-libvirt-x
On 01/19/2017 08:56 PM, Stefano Stabellini wrote:
On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/io/kbdif.h | 248 +-
1 file changed, 221 insertions(+),
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, January 20, 2017 1:30 AM
>
> There's nothing wrong with allowing the domain to perform DMA transfers to
> MMIO areas that it already can access from the CPU, and this allows us to
> remove the hack in set_identity_p2m_entry for
flight 104291 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104291/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in
104271 pass in 104291
test-armhf-armh
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 84cf44d..b8f727a 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> -2: /* Reserve 64kb for the trampoline */
> -sub $0x1000,%ecx
> +
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Add multiboot2 protocol support for relocatable images. Only GRUB2 with
> "multiboot2: Add support for relocatable images" patch understands
> that feature. Older multiboot protocol (regardless of version)
> compatible loaders ignore it and everything works
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> This way macro name better describes its function.
> Currently it is used to calculate symbol offset in
> relation to the beginning of Xen image mapping.
> However, value returned by sym_offs() for a given
> symbol is not always equal its physical address.
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> ..calculating its value during runtime.
>
> Signed-off-by: Daniel Kiper
> Acked-by: Jan Beulich
> Reviewed-by: Doug Goldstein
FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.
--
Doug Gol
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Subsequent patches introducing relocatable early boot code play with
> page tables using 2 MiB huge pages. If load address is not aligned at
> 2 MiB then code touching such page tables must have special cases for
> start and end of Xen image memory region.
flight 104290 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 18 leak-check/check fail REGR. vs. 104223
Regressions which
On Thu, Jan 19, 2017 at 09:25:08AM -0500, Doug Goldstein wrote:
> On 1/19/17 6:56 AM, Daniel Kiper wrote:
> >> Can you tell me what were the fixes to the relocation code?
> >
> > Unfortunately I have not received any details from you. Just vague
> > statements that it does not work. So, I am not ab
Hi,
I am sending twelfth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known/confirmed issues.
The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platf
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2
Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without p
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 1 MiB address and we should
not allocate a memory fro
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v12
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-b
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
---
v12 - suggestions/fixes:
- rename __efi64_start to __efi64_mb2_start
(suggested by Andrew Cooper),
- use efi_arch_memory_setup() machiner
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e6f6ef1..24b4b23 100644
---
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file con
On Thu, 19 Jan 2017, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 19, 2017 at 06:58:46PM -0500, Boris Ostrovsky wrote:
> > On 01/19/2017 01:39 PM, Stefano Stabellini wrote:
> > > In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
> > > page is not suitable, we swap it for another p
On Thu, Jan 19, 2017 at 06:58:46PM -0500, Boris Ostrovsky wrote:
> On 01/19/2017 01:39 PM, Stefano Stabellini wrote:
> > In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
> > page is not suitable, we swap it for another page from the swiotlb
> > pool.
> >
> > In these cases, we
On 01/19/2017 01:39 PM, Stefano Stabellini wrote:
> In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
> page is not suitable, we swap it for another page from the swiotlb
> pool.
>
> In these cases, we don't update the previously calculated dma address
> for the page before cal
This run is configured for baseline tests only.
flight 68398 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68398/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i3863 host-install(3) broken bas
On (01/19/17 13:47), Sowmini Varadhan wrote:
> > Specifically I'm talking about the dev_validate_header() check.
> > That is supposed to protect us from these kinds of situations.
>
> ah, but I run my pf_packet application as root, so I have
> capable(CAP_SYS_RAWIO), so I slip through the dev_val
On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> xen/include/public/io/kbdif.h | 216
> ++
> 1 file changed, 216 insertions(+)
>
> diff --git a/xen/include/public/io/k
On Wed, 11 Jan 2017, Oleksandr Andrushchenko wrote:
> On 01/11/2017 02:29 AM, Stefano Stabellini wrote:
> > On Tue, 10 Jan 2017, Oleksandr Andrushchenko wrote:
> > > On 01/07/2017 12:37 AM, Stefano Stabellini wrote:
> > > > On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:
> > > > > From: Oleksand
flight 104282 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104282/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 59254
test-amd64-amd64-xl
>
> So I can see 2 solutions:
> 1) Increase the timeout
> 2) Only build the kernel on the Arndales. Though they are known to
> be unreliable in the colo :/
>
> Any opinions?
I'd vote for (1). Alternatively we could cross-compile on an x86 box.
-boris
___
Hi,
On 19/01/2017 20:15, Boris Ostrovsky wrote:
So this appears to be a pretty slow, 2-core box:
[ 0.049778] SMP: Total of 2 processors activated (96.00 BogoMIPS).
For comparison, my (old-ish) phone is 4 x 26 BogoMIPS. So it's
theoretically faster than this server.
The ARM32 platforms we
flight 68397 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68397/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REG
Hello,
On 19/01/2017 19:22, Stefano Stabellini wrote:
On Thu, 19 Jan 2017, Roger Pau Monné wrote:
On Wed, Jan 18, 2017 at 07:13:23PM +, Julien Grall wrote:
Hi,
On 18/01/17 19:05, Stefano Stabellini wrote:
On Wed, 18 Jan 2017, Roger Pau Monné wrote:
On Tue, Jan 17, 2017 at 02:20:54PM -08
> So this appears to be a pretty slow, 2-core box:
>
> [ 0.049778] SMP: Total of 2 processors activated (96.00 BogoMIPS).
For comparison, my (old-ish) phone is 4 x 26 BogoMIPS. So it's
theoretically faster than this server.
-boris
>
> Julien --- how does 2.5 hours for kernel build sound to you?
Wei Liu (2):
tools/fuzz: fix compilation after 897129d
tools/fuzz: make sure targets are always built
tools/fuzz/Makefile | 6 ++
tools/fuzz/libelf/Makefile | 3 +++
tools/fuzz/x86_instruction_emulator/Makefile | 5 -
3 files changed, 9 inser
We need to add -D__XEN_TOOLS__ so that the correct register names are
generated.
Signed-off-by: Wei Liu
---
tools/fuzz/x86_instruction_emulator/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/fuzz/x86_instruction_emulator/Makefile
b/tools/fuzz/x86_instruction_
Invocation of `make' in top-level directory would end up invoking the
install target.
Adjust fuzzing target makefiles a bit so that they are always build in
that situation.
Signed-off-by: Wei Liu
---
tools/fuzz/Makefile | 6 ++
tools/fuzz/libelf/Makefile
On 01/19/2017 01:07 PM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104237:
> regressions - FAIL"):
>> On 01/18/2017 10:05 AM, osstest service owner wrote:
>>> build-armhf-pvops 5 kernel-build fail REGR. vs.
>>> 59254
>> ARM build see
On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> xen/include/public/io/kbdif.h | 248
> +-
> 1 file changed, 221 insertions(+), 27 deletions(-)
>
> diff --git a/xen/in
On (01/19/17 11:37), David Miller wrote:
>
> I thought we had code which made sure that at least a minimal
> link layer header was present in the SKB?
>
> Specifically I'm talking about the dev_validate_header() check.
> That is supposed to protect us from these kinds of situations.
ah, but I ru
On Thu, 19 Jan 2017, Julien Grall wrote:
> Hi Edgar,
>
> On 10/01/2017 11:37, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Relax the hardware domains mapping attributes to p2m_mmio_direct_c.
> > This will allow the hardware domain to fully control the
> > attribtues via its S1
On 01/19/2017 01:05 PM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104237:
> regressions - FAIL"):
>> On 01/18/2017 10:05 AM, osstest service owner wrote:
>>> flight 104237 linux-linus real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/104237/
>>
In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
page is not suitable, we swap it for another page from the swiotlb
pool.
In these cases, we don't update the previously calculated dma address
for the page before calling xen_dma_map_page. Thus, we end up calling
xen_dma_map_pa
On Thu, 19 Jan 2017, Pooya Keshavarzi wrote:
> Hi Stefano,
>
> On 01/13/2017 07:39 PM, Stefano Stabellini wrote:
> > On Fri, 13 Jan 2017, Pooya.Keshavarzi wrote:
> >> On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
> >>> On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
>
> Firstly sorry fo
On Thu, 19 Jan 2017, Roger Pau Monné wrote:
> On Wed, Jan 18, 2017 at 07:13:23PM +, Julien Grall wrote:
> > Hi,
> >
> > On 18/01/17 19:05, Stefano Stabellini wrote:
> > > On Wed, 18 Jan 2017, Roger Pau Monné wrote:
> > > > On Tue, Jan 17, 2017 at 02:20:54PM -0800, Stefano Stabellini wrote:
> >
Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions
- FAIL"):
> On 01/18/2017 10:05 AM, osstest service owner wrote:
> > build-armhf-pvops 5 kernel-build fail REGR. vs.
> > 59254
>
> ARM build seems to be caused by some sort of a timeout. The
Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions
- FAIL"):
> On 01/18/2017 10:05 AM, osstest service owner wrote:
> > flight 104237 linux-linus real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/104237/
> >
> > Regressions :-(
> >
> > Tests which did no
On Thu, Jan 19, 2017 at 11:10:53AM -0600, Eric DeVolder wrote:
> When checking kexec_flags bit corresponding to the
> requested image, ensure that 0 or 1 is returned.
>
> Signed-off-by: Eric DeVolder
In general Reviewed-by: Daniel Kiper but...
> ---
> xen/common/kexec.c | 3 ++-
> 1 file chang
On 18/01/17 19:56, Ronald Rojas wrote:
> Add calls for the following host-related functionality:
> - libxl_get_max_cpus
> - libxl_get_online_cpus
> - libxl_get_max_nodes
> - libxl_get_free_memory
> - libxl_get_physinfo
> - libxl_get_version_info
>
> Include Golang versions of the following structs
xen.git commit 57f8b13c changed several of the libxl memory
get/set functions to take 64 bit parameters. The libvirt
libxl driver still uses uint32_t variables for these various
parameters, which is particularly problematic for the
libxl_set_memory_target() function.
When dom0 autoballooning is en
On Thu, Jan 19, 2017 at 01:29:15AM -0700, Jan Beulich wrote:
> >>> On 18.01.17 at 20:56, wrote:
> > I am looking at rmrr_identity_mapping where the RMRR paddr get converted
> > to pfn and then mapped with iommu.
> > If ( rmrr->end_address & ~PAGE_SHIFT_MASK_4K ) == 0, the while loop
> > while
Split the Dom0 builder into two different functions, one for PV (and classic
PVH), and another one for PVHv2. Introduce a new command line parameter
called 'dom0' that can be used to request the creation of a PVHv2 Dom0 by
setting the 'hvm' sub-option. A panic has also been added if a user tries
to
Initialize Dom0 BSP/APs and setup the memory and IO permissions. This also sets
the initial BSP state in order to match the protocol specified in
hvm/start_info.h.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
---
xen/arch/x86/domain_build.c | 60
On Wed, Jan 18, 2017 at 10:16:49AM -0600, Eric Blake wrote:
> Quite a few users of qdict_put() were manually wrapping a
> non-QObject. We can make such call-sites shorter, by providing
> common macros to do the tedious work. Also shorten nearby
> qdict_put_obj(,,QOBJECT()) sequences.
>
> Signed-o
Introduce a helper to parse the Dom0 kernel.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v4:
- s/hvm/pvh.
- Use hvm_copy_to_guest_phys_vcpu.
Changes since v3:
- Change one error message.
- Indent "out" label by one space.
- Introduce hvm_copy_to_
On 19/01/17 17:29, Roger Pau Monne wrote:
> PVHv2 Dom0 is limited to 128 vCPUs, as are all HVM guests at the moment. Fix
> dom0_max_vcpus so it takes this limitation into account by poking at the
> dom0_hvm variable.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Current __hvm_copy assumes that the destination memory belongs to the current
vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
functions are used with current being the idle vcpu. Add a new vcpu parameter
to hvm copy in order to solve that. Note that only hvm_copy_to_guest_
Craft the Dom0 e820 memory map and populate it. Introduce a helper to remove
memory pages that are shared between Xen and a domain, and use it in order to
remove low 1MB RAM regions from dom_io in order to assign them to a PVHv2 Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew
There's nothing wrong with allowing the domain to perform DMA transfers to
MMIO areas that it already can access from the CPU, and this allows us to
remove the hack in set_identity_p2m_entry for PVH Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: George Dunlap
Cc:
PVHv2 guests, unlike HVM guests, won't have the option to route interrupts
from physical or emulated devices over event channels using PIRQs. This
applies to both DomU and Dom0 PVHv2 guests.
Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
route physical interrupts (even
Hello,
This is the first batch of the PVHv2 Dom0 support series, that includes
everything up to the point where ACPI tables for Dom0 are crafted. I've
decided to left the last part of the series (the one that contains the PCI
config space handlers, and other emulation/trapping related code) separa
PVHv2 Dom0 is limited to 128 vCPUs, as are all HVM guests at the moment. Fix
dom0_max_vcpus so it takes this limitation into account by poking at the
dom0_hvm variable.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Change since v4:
- Fix codding style to match rest o
Create a new MADT table that contains the topology exposed to the guest. A
new XSDT table is also created, in order to filter the tables that we want
to expose to the guest, plus the Xen crafted MADT. This in turn requires Xen
to also create a new RSDP in order to make it point to the custom XSDT.
On 18/01/17 19:56, Ronald Rojas wrote:
> Create error type Errorxl for throwing proper xenlight
> errors.
>
> Update Ctx functions to throw Errorxl errors.
>
> Signed-off-by: Ronald Rojas
Overall, looks good! Thanks for this. Just a few minor comments.
> ---
> tools/golang/xenlight/xenlight
When checking kexec_flags bit corresponding to the
requested image, ensure that 0 or 1 is returned.
Signed-off-by: Eric DeVolder
---
xen/common/kexec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index aa808cb..3da27bf 100644
---
Jan,
This corrects the use of test_bit() in kexec_status().
Wei,
This patch is against the kexec_status() recently applied to staging.
Regards,
Eric
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 01/18/2017 10:05 AM, osstest service owner wrote:
> flight 104237 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/104237/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemut-win7-a
Sorry, this fell through the crack.
On Wed, Nov 30, 2016 at 06:38:45PM -0700, Jim Fehlig wrote:
> Hi All,
>
> 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
>
On 19/01/17 17:19, Wei Liu wrote:
> On Thu, Jan 19, 2017 at 05:14:35PM +0100, Olaf Hering wrote:
>> On Tue, Jul 12, Juergen Gross wrote:
>>
>>> Instead of using a macro generating the code to merge xenstore and
>>> json configuration data, use the generic device type support for
>>> this purpose.
>
This run is configured for baseline tests only.
flight 68395 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68395/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i3863 host-install(3) broken bas
On 18/01/17 19:56, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
>
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
>
>
On 18/01/17 19:56, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
>
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
>
>
From: Sowmini Varadhan
Date: Thu, 19 Jan 2017 06:14:26 -0500
> I'll probably work on fixing packet_snd to return -EINVAL
> or similar when the len is zero this week.
I thought we had code which made sure that at least a minimal
link layer header was present in the SKB?
Specifically I'm talking
>>> On 17.01.17 at 16:08, wrote:
> But fortunately commenting out that line could still reproduce the IOMMU
> fault.
> I was lucky to capture the full log before it fills up my 100MB ring buffer
> (in less than 2 seconds).
So here's a first take at a debugging patch. I've tried to limit existing
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-win7-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tradit
On Thu, 2017-01-19 at 16:02 +, George Dunlap wrote:
> On 19/01/17 15:13, Ronald Rojas wrote:
> > It's possible to add the errors as part of the first patch and then
> > add the context functions as the second patch as Go will at least
> > let you compile the errors on it's own. I can swap the
On Thu, Jan 19, 2017 at 05:14:35PM +0100, Olaf Hering wrote:
> On Tue, Jul 12, Juergen Gross wrote:
>
> > Instead of using a macro generating the code to merge xenstore and
> > json configuration data, use the generic device type support for
> > this purpose.
> > This requires to add some accessor
On 18/01/17 19:56, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
>
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
>
>
On Thu, Jan 19, 2017 at 04:02:46PM +, George Dunlap wrote:
> On 19/01/17 15:13, Ronald Rojas wrote:
> > On Wed, Jan 18, 2017 at 11:16:31PM +0100, Dario Faggioli wrote:
> >> On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote:
> >>> Create error type Errorxl for throwing proper xenlight
> >>>
On Tue, Jul 12, Juergen Gross wrote:
> Instead of using a macro generating the code to merge xenstore and
> json configuration data, use the generic device type support for
> this purpose.
> This requires to add some accessor functions to the framework and
> a structure for disks (as disks are add
flight 104283 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104283/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104238
test-armhf-armhf-libvirt-qcow2 1
On 19/01/17 15:13, Ronald Rojas wrote:
> On Wed, Jan 18, 2017 at 11:16:31PM +0100, Dario Faggioli wrote:
>> On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote:
>>> Create error type Errorxl for throwing proper xenlight
>>> errors.
>>>
>>> Update Ctx functions to throw Errorxl errors.
>>>
>>> Sig
flight 104278 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10
fail REGR. vs.
On Wed, Jan 18, 2017 at 07:13:23PM +, Julien Grall wrote:
> Hi,
>
> On 18/01/17 19:05, Stefano Stabellini wrote:
> > On Wed, 18 Jan 2017, Roger Pau Monné wrote:
> > > On Tue, Jan 17, 2017 at 02:20:54PM -0800, Stefano Stabellini wrote:
> > > > a) One option is to provide a Xen specific implemen
flight 104279 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104279/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5ab0ffc9f64f5a539a9bdb50446b7fbf92b845d6
baseline version:
ovmf 88fd27e5b2cae68ff5a11
On 19/01/17 13:51, Juergen Gross wrote:
> On 19/01/17 12:51, Wei Liu wrote:
>> On Wed, Jan 18, 2017 at 07:25:57PM +0100, Juergen Gross wrote:
>>> xl mem-max is setting the hypervisor memory limit of a domain, but not
>>> the memory/static-max value in Xenstore. This prohibits setting the
>>> memory
On Thu, Jan 19, 2017 at 12:03:22PM +, Wei Liu wrote:
> On Wed, Jan 18, 2017 at 02:56:39PM -0500, Ronald Rojas wrote:
>
> > diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> > new file mode 100644
> > index 000..a45336b
> > --- /dev/null
> > +++ b/tools/golang
On Wed, Jan 18, 2017 at 11:16:31PM +0100, Dario Faggioli wrote:
> On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote:
> > Create error type Errorxl for throwing proper xenlight
> > errors.
> >
> > Update Ctx functions to throw Errorxl errors.
> >
> > Signed-off-by: Ronald Rojas
> > ---
> > t
Hi Stefano,
On 01/13/2017 07:39 PM, Stefano Stabellini wrote:
> On Fri, 13 Jan 2017, Pooya.Keshavarzi wrote:
>> On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
>>> On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
Firstly sorry for the late reply on this.
Regarding the problem wit
Hi,
On 19/01/17 14:32, Julien Grall wrote:
> Hi Andre,
>
> On 19/01/2017 13:50, Andre Przywara wrote:
>> On 19/01/17 12:26, Vijay Kilari wrote:
>>>I see following issues when running on ThunderX platform with your
>>> patches.
>>> I have debugged and patched/workaround few issues. For issue (
On 01/19/2017 03:25 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> Quite a few users of qdict_put() were manually wrapping a
>> non-QObject. We can make such call-sites shorter, by providing
>> common macros to do the tedious work. Also shorten nearby
>> qdict_put_obj(,,QOBJECT()) sequen
Hi Andre,
On 19/01/2017 13:50, Andre Przywara wrote:
On 19/01/17 12:26, Vijay Kilari wrote:
I see following issues when running on ThunderX platform with your patches.
I have debugged and patched/workaround few issues. For issue (5) I
need your inputs.
thanks for the testing and the input
On 1/19/17 3:31 AM, Jan Beulich wrote:
On 18.01.17 at 18:38, wrote:
>>
>> What's controversial about it?
>
> The not insignificant amount of assembly code it adds, when our
> overall goal is to reduce the amount of assembly code. But
> Andrew has meanwhile indicated he's okay for this to go
On 1/19/17 6:56 AM, Daniel Kiper wrote:
>> Can you tell me what were the fixes to the relocation code?
>
> Unfortunately I have not received any details from you. Just vague
> statements that it does not work. So, I am not able to say anything
> about that. If you provide more details I am happy t
On 19/01/17 03:56, Doug Goldstein wrote:
> On 1/18/17 2:40 PM, Andrew Cooper wrote:
>> The VT-x/SVM features are hidden from PV dom0 by the pv_featureset[] upper
>> mask, but nothing thusfar has prevented the features being visible in
> thus far? Could be the difference between British English and
flight 104275 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104275/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail in 104250 pass in 104275
test-amd64-i386-qemut-rhel6hv
On Thu, Jan 19, 2017 at 01:56:34PM +, Andrew Cooper wrote:
> On 19/01/17 11:01, Wei Liu wrote:
> > On Wed, Jan 18, 2017 at 07:15:44PM +0100, Juergen Gross wrote:
> > [...]
> >> diff --git a/xen/include/public/io/xs_wire.h
> >> b/xen/include/public/io/xs_wire.h
> >> index 54c1d71..751bd17 10064
On 19/01/17 11:01, Wei Liu wrote:
> On Wed, Jan 18, 2017 at 07:15:44PM +0100, Juergen Gross wrote:
> [...]
>> diff --git a/xen/include/public/io/xs_wire.h
>> b/xen/include/public/io/xs_wire.h
>> index 54c1d71..751bd17 100644
>> --- a/xen/include/public/io/xs_wire.h
>> +++ b/xen/include/public/io/x
1 - 100 of 160 matches
Mail list logo
