On Sun, Jan 25, Wei Liu wrote:
> In d9740237a ("tools: unhook blktap1 from the build and remove all
> references to it"), one spot was left unchanged, which leads to failure
> in building qemu-xen-traditional.
Another one. I suspect there is more like that in qemu-xen-traditional.
Should I spent
On 2015.1.23 19:15, Roger Pau Monné wrote:
> Hello,
>
> El 23/01/15 a les 8.59, Ouyang Zhaowei (Charles) ha escrit:
>> Hi Roger,
>>
>> We are testing the indirect feature of xen-blkfront module these days.
>> And we found that, after VM live-migrate a couple of times, the "%util" of
>> iostat ke
flight 33770 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33770/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 33664
test-amd64-i386-freebsd10-amd6
Hi, all:
I want to compile the Dom0 based on Linux 3.17.4 kernel, and make sure all
of that the necessary config options for supporting Dom0 on official wiki ([1])
enabled. However, if I test the "network forwarding" performance for Dom0 using
traffic generator, I find that the performance
On 01/23/15 16:03, Ard Biesheuvel wrote:
> While Xen on Intel uses a virtual PCI device to communicate the
> base address of the grant table, the ARM implementation uses a DT
> node, which is fundamentally incompatible with the way XenBusDxe is
> implemented, i.e., as a UEFI Driver Model implementa
>>> On 23.01.15 at 18:21, wrote:
> On Fri, Jan 23, 2015 at 04:03:55PM +, Jan Beulich wrote:
>> >>> On 23.01.15 at 16:46, wrote:
>> > Subject: [PATCH] domain: In vcpu_destroy_pagetables we can return -ERESTART
>> > instead of -EINTR
>> >
>> > which has the side effect that domain_relinquish_
>>> On 26.01.15 at 03:41, wrote:
> On Fri, Jan 23, 2015 at 02:28:04PM +, Jan Beulich wrote:
>> >>> On 23.01.15 at 14:40, wrote:
>> > @@ -133,10 +135,39 @@ static void resource_access(void *info)
>> > switch ( entry->u.cmd )
>> > {
>> > case XEN_RESOURCE_OP_MSR_READ:
On 26 January 2015 at 09:27, Laszlo Ersek wrote:
> On 01/23/15 16:03, Ard Biesheuvel wrote:
>> While Xen on Intel uses a virtual PCI device to communicate the
>> base address of the grant table, the ARM implementation uses a DT
>> node, which is fundamentally incompatible with the way XenBusDxe is
On Mon, 2015-01-26 at 03:03 +, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-xl
> test xen-boot
>
> Tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
On 23/01/15 16:39, Jan Beulich wrote:
> Following a compiler change done in 2012, make use of the fact that for
> non-zero input BSF and TZCNT produce the same numeric result (EFLAGS
> setting differs), and that CPUs not knowing of TZCNT will treat the
> instruction as BSF (i.e. ignore what looks l
[ Cc += Anil ]
On 25 January 2015 at 18:25, Wei Liu wrote:
> Cc Ian and Ian and some folks who might be interested in this work.
>
> On Sun, Jan 25, 2015 at 06:13:41PM +, Wei Liu wrote:
>> There has been increasing use of mini-os in unikernel world and basically
>> everybody has their own for
On Sun, 2015-01-25 at 15:38 +, Wei Liu wrote:
> In d9740237a ("tools: unhook blktap1 from the build and remove all
> references to it"), one spot was left unchanged, which leads to failure
> in building qemu-xen-traditional.
Well spotted, which make invocation hits this path? make dist (what I
On Mon, Jan 26, 2015 at 09:39:06AM +, Jan Beulich wrote:
> >>> On 26.01.15 at 03:41, wrote:
> > On Fri, Jan 23, 2015 at 02:28:04PM +, Jan Beulich wrote:
> >> >>> On 23.01.15 at 14:40, wrote:
> >> > @@ -133,10 +135,39 @@ static void resource_access(void *info)
> >> > switch ( entr
On Mon, Jan 26, 2015 at 09:31:44AM +0100, Olaf Hering wrote:
> On Sun, Jan 25, Wei Liu wrote:
>
> > In d9740237a ("tools: unhook blktap1 from the build and remove all
> > references to it"), one spot was left unchanged, which leads to failure
> > in building qemu-xen-traditional.
>
> Another one.
On Mon, 2015-01-26 at 10:01 +, Wei Liu wrote:
> On Mon, Jan 26, 2015 at 09:31:44AM +0100, Olaf Hering wrote:
> > On Sun, Jan 25, Wei Liu wrote:
> >
> > > In d9740237a ("tools: unhook blktap1 from the build and remove all
> > > references to it"), one spot was left unchanged, which leads to fai
On Fri, Jan 23, 2015 at 02:28:04PM +, Jan Beulich wrote:
> >>> On 23.01.15 at 14:40, wrote:
> > @@ -133,10 +135,39 @@ static void resource_access(void *info)
> > switch ( entry->u.cmd )
> > {
> > case XEN_RESOURCE_OP_MSR_READ:
> > -ret = rdmsr_safe(entry-
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments,
keeping track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
arch/x86/xen/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
Oops, cc'ing lkml.
On Mon, 2015-01-26 at 02:10 -0800, Davidlohr Bueso wrote:
> Call __set_current_state() instead of assigning the new state directly.
> These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments,
> keeping track of who changed the state.
>
> Signed-off-by: Davidlohr Bueso
>>> On 26.01.15 at 11:10, wrote:
> On Fri, Jan 23, 2015 at 02:28:04PM +, Jan Beulich wrote:
>> >>> On 23.01.15 at 14:40, wrote:
>> > --- a/xen/include/public/platform.h
>> > +++ b/xen/include/public/platform.h
>> > @@ -540,6 +540,16 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_core_parking_t);
>> > #def
On 26/01/15 10:10, Davidlohr Bueso wrote:
> Call __set_current_state() instead of assigning the new state directly.
> These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments,
> keeping track of who changed the state.
Applied to devel/for-linus-3.20, thanks.
David
___
On 01/26/15 10:46, Ard Biesheuvel wrote:
> So it would be sufficient to install the XENIO_PROTOCOL on the
> existing ControllerHandle containing the EFI_PCI_IO_PROTOCOL?
Yes.
Because there would be only one PCI (b,d,f) that would qualify (you'd
write up the Supported() check appropriately), ther
flight 33774 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33774/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33668
test-amd64-i386-xl-qemut-w
>>> On 25.01.15 at 19:13, wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -245,13 +245,16 @@ OVMF_UPSTREAM_URL ?=
> http://xenbits.xen.org/git-http/ovmf.git
> QEMU_UPSTREAM_URL ?=
> http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
> QEMU_TRADITIONAL_URL ?=
> http://xenbits.xen.org
>>> On 23.01.15 at 19:58, wrote:
> On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
>> On 23/01/15 00:29, Luis R. Rodriguez wrote:
>> > @@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>> >set_irq_regs(old_regs);
>> > }
>> >
>> > +/*
>> > + * CONFIG_PREEMP
On 23/01/15 18:58, Luis R. Rodriguez wrote:
>
> Its not just hypercalls though, this is all about the interactions
> with multicalls no?
No. This applies to any preemptible hypercall and the toolstack doesn't
use multicalls for most of its work.
David
__
On Fri, 2014-11-21 at 17:00 +, Stefano Stabellini wrote:
> Need to pass the pointer within the swiotlb internal buffer to the
> swiotlb library, that in the case of xen_unmap_single is dev_addr, not
> paddr.
>
> Signed-off-by: Stefano Stabellini
> CC: konrad.w...@oracle.com
> CC: sta...@vger.
Reviewed-By: Olivier Martin
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 January 2015 15:03
> To: edk2-de...@lists.sourceforge.net; ler...@redhat.com; Olivier
> Martin; roy.fr...@linaro.org; leif.lindh...@linaro.org;
> stefano.stabell...@eu.cit
On 23 January 2015 at 19:38, Laszlo Ersek wrote:
> On 01/23/15 16:02, Ard Biesheuvel wrote:
>> This removes an instance of FixedPcdGet () so that the self relocating
>> PrePi instance can poke another value into it.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ar
On 26 Jan 2015, at 09:53, Thomas Leonard wrote:
>
> [ Cc += Anil ]
>
> On 25 January 2015 at 18:25, Wei Liu wrote:
>> Cc Ian and Ian and some folks who might be interested in this work.
>>
>> On Sun, Jan 25, 2015 at 06:13:41PM +, Wei Liu wrote:
>>> There has been increasing use of mini-os
>>> On 24.01.15 at 13:54, wrote:
> flight 33690 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33690/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen
On Thu, 2015-01-22 at 15:57 +, Ian Campbell wrote:
> On Thu, 2015-01-22 at 15:52 +, Ian Campbell wrote:
> > Pushing the ~1 to the output will force a test run, once that is done I
> > will push the osstest patches.
>
> Actually using the result will require me to push this along with the
>
I would suggest to move gFdtHobGuid definition and Include/Guid/FdtHob.h
into EmbeddedPkg.
They are not specific to ArmVirtualizationPkg and could even be used by HW
platforms and non ARM architectures.
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent:
On Mon, 26 Jan 2015, Mao Mingy wrote:
> On 23/01/2015 18:56, Ian Campbell wrote:
>
> If you are trying to get the guest framebuffer onto a physical graphics
> device then PVFB is not what you need. Instead you need to do device
> passthrough of that device to the guest (which means denying it to
>
On Mon, Jan 26, 2015 at 10:53:27AM +, Ian Campbell wrote:
> On Fri, 2014-11-21 at 17:00 +, Stefano Stabellini wrote:
> > Need to pass the pointer within the swiotlb internal buffer to the
> > swiotlb library, that in the case of xen_unmap_single is dev_addr, not
> > paddr.
> >
> > Signed-o
On Mon, Jan 26, 2015 at 09:55:41AM +, Ian Campbell wrote:
> On Sun, 2015-01-25 at 15:38 +, Wei Liu wrote:
> > In d9740237a ("tools: unhook blktap1 from the build and remove all
> > references to it"), one spot was left unchanged, which leads to failure
> > in building qemu-xen-traditional.
On Mon, Jan 26, 2015 at 10:43:58AM +, Jan Beulich wrote:
> >>> On 25.01.15 at 19:13, wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -245,13 +245,16 @@ OVMF_UPSTREAM_URL ?=
> > http://xenbits.xen.org/git-http/ovmf.git
> > QEMU_UPSTREAM_URL ?=
> > http://xenbits.xen.org/git-http/qemu-
On Fri, Jan 23, 2015 at 10:18:41AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 22, 2015 at 03:12:08PM -0500, Konrad Rzeszutek Wilk wrote:
> > Hey,
> >
> > I will becoming more involved in OpenStack to the point that
> > I cannot see myself wearing the Release Manager hat as well.
> >
> > As
On 01/26/15 11:57, Ard Biesheuvel wrote:
> On 23 January 2015 at 19:38, Laszlo Ersek wrote:
>> On 01/23/15 16:02, Ard Biesheuvel wrote:
>>> This removes an instance of FixedPcdGet () so that the self relocating
>>> PrePi instance can poke another value into it.
>>>
>>> Contributed-under: TianoCore
Hi all,
do we have any other nominations? How about waiting say till Thursday. If
there are no others, I will organise a vote
Regards
Lars
On 26/01/2015 10:56, "Wei Liu" wrote:
>On Fri, Jan 23, 2015 at 10:18:41AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jan 22, 2015 at 03:12:08PM -0500, Ko
On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
> On 23 January 2015 at 18:54, Stefano Stabellini
> wrote:
> > On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
> >> This implements a SerialPortLib instance that wires up to the
> >> PV console ring used by domU guests. Also imports the required
> >> upstream
On 23 January 2015 at 20:59, Laszlo Ersek wrote:
> some notes
>
> On 01/23/15 16:02, Ard Biesheuvel wrote:
>> This implements a MemoryInitPeiLib instance that differs from the
>> stock ArmPlatformPkg version only in the fact that it does not remove
>> the memory used by the flash device (FD). The
>>> On 26.01.15 at 12:04, wrote:
On 24.01.15 at 13:54, wrote:
>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs.
>> 33637
>
> Jan 24 00:35:16.262627 (XEN) [ Xen-4.6-unstable x86_64 debug=y Not
> tainted ]
> Jan 24 00:35:16.478599 (XEN) CPU:1
> Jan
On Fri, 2015-01-23 at 16:53 +, Ian Jackson wrote:
> Ian Campbell writes ("[OSSTEST PATCH] README.dev: Document how to do a force
> push."):
> > Signed-off-by: Ian Campbell
> ...
> > +Force pushing a branch
> > +==
> > +
> > +As osstest user on test controller
> > +$ cd ~/b
I am a bit lost with this patch. I am looking for the definition of
FDT_PADDING. I cannot find it in the previous patches and in subversion.
And it looks like it is going to be removed later on as I cannot find it
anymore in the HEAD of your branch
https://git.linaro.org/people/ard.biesheuvel/uefi-
On 26 January 2015 at 11:47, Olivier Martin wrote:
> I am a bit lost with this patch. I am looking for the definition of
> FDT_PADDING. I cannot find it in the previous patches and in subversion.
It is in the first hunk of *this* patch
> And it looks like it is going to be removed later on as I
Oops, Monday morning...
I actually wanted to check if it was a PCD. And I think it should be a PCD in
case we have different build variations that require more or less padding.
And it does not explain why this value disappear later on. Maybe a later patch
will give me the answer...
> -Ori
... when available, i.e. by runtime patching. This saves the
conditional move, having a back-to-back dependency on BSF's (EFLAGS)
result.
The need to include asm/cpufeatures.h from asm/bitops.h requires a
workaround for an otherwise resulting circular header file dependency:
Provide a mode by whic
The following changes since commit b3a4755a67a52aa7297eb8927b482d09dabdefec:
Merge remote-tracking branch 'remotes/kraxel/tags/pull-vnc-20150122-1' into
staging (2015-01-22 12:14:19 +)
are available in the git repository at:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2015
xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an
unsigned long argument (in fact xen_pfn_t is defined as uint64_t on
ARM).
Also use xc_hvm_param_get instead of the deprecated xc_get_hvm_param.
Signed-off-by: Stefano Stabellini
Reviewed-by: Don Slutz
---
include/hw/xen/xen_commo
On Thu, 22 Jan 2015, Sander Eikelenboom wrote:
> While this fixes the race and error on shutdown of a HVM guest with
> pci-passthrough,
> i don't know if this could give problems in other areas (migration ?),
> hence posted as RFC.
I think the patch should be OK. Maybe you could test it with loca
flight 33780 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 33341
test-amd64-i386-xl-qem
On 26/01/15 12:03, Jan Beulich wrote:
> ... when available, i.e. by runtime patching. This saves the
> conditional move, having a back-to-back dependency on BSF's (EFLAGS)
> result.
>
> The need to include asm/cpufeatures.h from asm/bitops.h requires a
> workaround for an otherwise resulting circul
Hi Oleksandr,
Thank you for the patch. See few comments below.
On 23/01/15 15:49, Oleksandr Tyshchenko wrote:
> Create preinit_xen_time() and move to it minimum required
> subset of operations needed to properly initialized
> cpu_khz and boot_count vars. This is allow us to use udelay()
> immedia
On 01/26/2015, 11:53 AM, Ian Campbell wrote:
> On Fri, 2014-11-21 at 17:00 +, Stefano Stabellini wrote:
>> Need to pass the pointer within the swiotlb internal buffer to the
>> swiotlb library, that in the case of xen_unmap_single is dev_addr, not
>> paddr.
>>
>> Signed-off-by: Stefano Stabelli
On 26 January 2015 at 12:00, Stefano Stabellini
wrote:
> The following changes since commit b3a4755a67a52aa7297eb8927b482d09dabdefec:
>
> Merge remote-tracking branch 'remotes/kraxel/tags/pull-vnc-20150122-1' into
> staging (2015-01-22 12:14:19 +)
>
> are available in the git repository at:
On 26 January 2015 at 10:28, Laszlo Ersek wrote:
> On 01/26/15 10:46, Ard Biesheuvel wrote:
>
>> So it would be sufficient to install the XENIO_PROTOCOL on the
>> existing ControllerHandle containing the EFI_PCI_IO_PROTOCOL?
>
> Yes.
>
> Because there would be only one PCI (b,d,f) that would quali
On Mon, Jan 26, 2015 at 3:32 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
Thank you for your comments.
>
> Thank you for the patch. See few comments below.
>
> On 23/01/15 15:49, Oleksandr Tyshchenko wrote:
>> Create preinit_xen_time() and move to it minimum required
>> subset of operations n
On 01/26/15 14:52, Ard Biesheuvel wrote:
> Well, the problem is that the XenConsoleSerialPortLib implementation
> also needs to issue Xen hypercalls, and needs to do so very early.
In general virtual serial consoles, be they Xen or virtio, are a huge
"impedance mismatch" (is that the right term?)
Signed-off-by: Andrew Cooper
CC: Keir Fraser
CC: Jan Beulich
CC: Tim Deegan
CC: Ian Campbell
CC: Ian Jackson
---
docs/misc/xen-command-line.markdown |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.
On 26 January 2015 at 14:10, Laszlo Ersek wrote:
> On 01/26/15 14:52, Ard Biesheuvel wrote:
>
>> Well, the problem is that the XenConsoleSerialPortLib implementation
>> also needs to issue Xen hypercalls, and needs to do so very early.
>
> In general virtual serial consoles, be they Xen or virtio,
Ping?
I think it would be great to have multiboot support in grub.
As a matter of fact without it grub cannot load xen on arm.
On Wed, 21 Jan 2015, Fu Wei wrote:
> Hi everybody,
> any suggestion for my patchset?
> if these patches look fine, can they be merged?
>
> Any feedback is welcome! :-)
Ping?
I think it would be great to have multiboot support in grub.
As a matter of fact without it grub cannot load xen on arm.
On Wed, 21 Jan 2015, Fu Wei wrote:
> Hi everybody,
> any suggestion for my patchset?
> if these patches look fine, can they be merged?
>
> Any feedback is welcome! :-)
The following series switches osstest to implement the toolstack via
get_host_method_object()->method rather than toolstack()->{Command}."
method" etc.
This is needed because virsh differs from xm/xl in a few commands.
It also implements partial virsh support (simple lifecycle stuff, but
not e.g.
Signed-off-by: Ian Campbell
---
v3: Timeout is set in the caller, not the method handler. "Different
guests might take different times to shut down - but different
toolstacks shouldn't."
---
Osstest/Toolstack/libvirt.pm | 6 ++
Osstest/Toolstack/xl.pm | 7 +++
ts-guest-stop
Refactor the guts of guest_await_reboot into a helper and use for both
shutdown and reboot handling.
Signed-off-by: Ian Campbell
---
v3: Refactor common code with guest_await_reboot.
---
Osstest/TestSupport.pm | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff
This will allow us to more easily have per-toolstack methods etc.
The previous hash of toolstack parameters is now a blessed object. For
now the callers don't need to change but over the following patches we
will refactor things to use method calls. In particular we will be
aiming to remove Comman
Unless the toolstack is xend (for compatibility with pre-xl Xen
versions), when we use xm.
For several operations in TestSupport.pm the actual toolstack isn't
really relevant, since we want info straight from Xen. For simplicity
just use xl (or xm) in these cases, to avoid needing to implement the
Signed-off-by: Ian Campbell
---
Osstest/Toolstack/libvirt.pm | 6 ++
Osstest/Toolstack/xl.pm | 6 ++
ts-logs-capture | 2 +-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 0d09ffc..fb9b9a9
Currently we rely on all apt-get invocations being in a single
ts-xen-build-prep job which can't run on a shared host.
That is a bit inflexible so instead use our own lock. We wait
indefinitely and rely on osstest's existing command timeout
infrastructure to catch problems.
target_install_package
virsh does not include a --wait option to shutdown as xl and xm do, so
we implement it by hand.
Needs new guest_await_destroy helper. Note the guest_await_shutdown
requires on_shutdown='preserve'
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
v3: Drop $ho parameter frm guest_await_destro
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
ts-logs-capture | 4
1 file changed, 4 insertions(+)
diff --git a/ts-logs-capture b/ts-logs-capture
index 21974a9..6cf51c1 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -117,6 +117,9 @@ sub fetch_logs_host_guests () {
Use $gho->{CfgPath} rather than constructing it again.
Still stubbed out for libvirt.
Signed-off-by: Ian Campbell
---
v3: Switch to CfgPath defered from incorrect home in earlier patch to
here.
RestoreNeedsConfig is an xl/xm ism, not relevant to libvirt, so
remove $cfg parameter from
Implement destory/create as per toolstack methods, including
implementing the libvirt version which previously didn't work. To do
this we use the virsh capability to convert an xl/xm style config file
into the correct XML.
xend basically calls into the xl helper since they are compatible.
xl/xm,
This allows us to abolish CfgPathVar which was inconsistently used,
appears redundant with $gho->{CfgPath} and in any case never set to
anything other than 'cfgpath'.
I suppose it was intended to deal with toolstacks with a cfg format
completely dissimilar to xm/xl's. I think if this arises in a f
The cfg file can be obtained from $gho->{CfgPath}. This is more
consistent with other methods.
Signed-off-by: Ian Campbell
---
v3: New patch, implementing suggesting from review of "Toolstack:
Refactor guest lifecycle."
---
Osstest/TestSupport.pm | 2 +-
Osstest/Toolstack/libvirt.pm |
Note that since the previous patch arranges for
ts-migration-support-check to continue to fail for libvirt the libvirt
code is not actually called yet (and will die if it is). This patch is
mainly included to reduce the number of users of
toolstack()->{Command} closer to zero.
Signed-off-by: Ian C
... by refactoring start/stop actions into the functions which are
expected by restart.
Signed-off-by: Ian Campbell
---
v3: Refactor into start/stop functions
---
ts-libvirt-build | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/ts-libvirt-build b/ts-libv
This will be needed in a future patch.
Everywhere already has a $ho in hand. Also cache the answer as
$ho->{Toolstack}.
I scanned the source with:
find -name \*.pm -exec perl -c {} \;
for i in ts-* ; do perl -c $i; done
which reported "Not enough arguments for Osstest::TestSupport::toolst
The host can be looked up from $gho->{Host} and the toolstack can be
looked up from the host.
Signed-off-by: Ian Campbell
---
v3: This replaces "TestSupport: guest_create takes a $ho"
---
Osstest/TestSupport.pm | 12 +++-
ts-debian-hvm-install | 9 +++--
ts-guest-de
Nothing in generic code uses this now, so remove.
xl+xend retain as _Command for internal use only.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
Osstest/Toolstack/libvirt.pm | 1 -
Osstest/Toolstack/xend.pm| 2 +-
Osstest/Toolstack/xl.pm | 18 +-
3 files cha
On Fri, 23 Jan 2015, Eric Shelton wrote:
> On Jan 23, 2015 10:10 AM, "Stefano Stabellini"
> wrote:
> >
> > On Fri, 23 Jan 2015, Ian Campbell wrote:
> > > On Fri, 2015-01-23 at 14:42 +, Stefano Stabellini wrote:
> > >
> > > > HVM guest -(PV)--> QEMU in Dom0 for guest
> > > >
Specifically guest_create and guest_find_domid.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
ts-rumpuserxen-demo-xenstorels | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index a2a6a77..6698848 1
On 26/01/15 11:38, Jan Beulich wrote:
On 26.01.15 at 12:04, wrote:
> On 24.01.15 at 13:54, wrote:
>>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs.
>>> 33637
>> Jan 24 00:35:16.262627 (XEN) [ Xen-4.6-unstable x86_64 debug=y Not
>> tainted ]
>> Jan
On 01/26/2015 09:49 AM, Andrew Cooper wrote:
On 26/01/15 11:38, Jan Beulich wrote:
On 26.01.15 at 12:04, wrote:
On 24.01.15 at 13:54, wrote:
test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637
Jan 24 00:35:16.262627 (XEN) [ Xen-4.6-unstable x86_64 debug=y
On 26/01/15 14:51, Boris Ostrovsky wrote:
> On 01/26/2015 09:49 AM, Andrew Cooper wrote:
>> On 26/01/15 11:38, Jan Beulich wrote:
>> On 26.01.15 at 12:04, wrote:
>>> On 24.01.15 at 13:54, wrote:
> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail
> REGR. vs. 33637
>
Not implemented for libvirt (the check itself that is, the hook is
present).
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
Osstest/Toolstack/libvirt.pm | 5 +
Osstest/Toolstack/xend.pm| 3 +++
Osstest/Toolstack/xl.pm | 9 +
ts-migrate-support-check | 10 +
On 23/01/15 16:00, David Vrabel wrote:
> On 23/01/15 15:47, Roger Pau Monné wrote:
>> El 23/01/15 a les 15.54, David Vrabel ha escrit:
>>> On 23/01/15 14:31, Roger Pau Monné wrote:
El 19/01/15 a les 16.51, David Vrabel ha escrit:
> + if (invcount) {
> + ret = gn
On 19/01/15 15:51, David Vrabel wrote:
> From: Jenny Herbert
>
> Use gnttab_unmap_refs_async() to wait until the mapped pages are no
> longer in use before unmapping them.
>
> This allows blkback to use network storage which may retain refs to
> pages in queued skbs after the block I/O has compl
On 01/26/2015 09:56 AM, Andrew Cooper wrote:
On 26/01/15 14:51, Boris Ostrovsky wrote:
On 01/26/2015 09:49 AM, Andrew Cooper wrote:
On 26/01/15 11:38, Jan Beulich wrote:
On 26.01.15 at 12:04, wrote:
On 24.01.15 at 13:54, wrote:
test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install f
Hello,
I try to compile xen-4.5.0 in the uclibc buildroot.
On "make xen" I get this error:
mkdir -p compat/.xlat
grep -v '^[[:blank:]]*#' xlat.lst | sed -ne 's,@arch@,x86_32,g' -re
's,[[:blank:]]+xen\.h[[:blank:]]*$,,p' >compat/.xlat/xen.lst.new
if ! cmp -s compat/.xlat/xen.lst.new compat/.xla
Wei Liu writes ("Re: [PATCH RFC 0/5] Split off mini-os to a separate tree"):
> Cc Ian and Ian and some folks who might be interested in this work.
Thanks.
This is all good.
I think we need some changes to osstest too because we will want a
push gate for xen's minios. I don't think we want to ke
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does)
To do this introduce the concept of routing a PPI to the currently
running VCPU. For such interrupts irq_get_domain re
>>> On 26.01.15 at 16:38, wrote:
> I try to compile xen-4.5.0 in the uclibc buildroot.
Of course a first step would be to try to build in a more conventional
environment.
> On "make xen" I get this error:
>
> mkdir -p compat/.xlat
> grep -v '^[[:blank:]]*#' xlat.lst | sed -ne 's,@arch@,x86_32,g
On 01/22/15 03:32, Jan Beulich wrote:
On 21.01.15 at 18:52, wrote:
>> On 01/16/15 05:09, Jan Beulich wrote:
>> On 03.10.14 at 00:40, wrote:
This is a new domain_create() flag, DOMCRF_vmware_port. It is
passed to domctl as XEN_DOMCTL_CDF_vmware_port.
>>> Can you explain why a H
Hey Jan, Andrew,
I am hoping you can help me in directing me where I ought to go next
in debugging this.
This is a Lenovo Thinkpad x230 with the latest BIOS and Xen 4.6 (todays
'staging' + my patches). Initially when I installed Xen the first time
it would hang when loading the efi_vars module in
Tim,
in the course of adding >16Tb support to the hypervisor, I ran into
issues with you having added several open-coded page list accesses
while breaking up non-order-0 allocations there. I looked at that
code for quite a while, but wasn't really able to figure how to
properly convert these. In p
On 26/01/15 16:27, Konrad Rzeszutek Wilk wrote:
> Hey Jan, Andrew,
>
> I am hoping you can help me in directing me where I ought to go next
> in debugging this.
>
> This is a Lenovo Thinkpad x230 with the latest BIOS and Xen 4.6 (todays
> 'staging' + my patches). Initially when I installed Xen the
We want to begin this year by making sure that our documentation is
correct for the recent 4.5 release.
Do you have new feature information? Do you see old information which
will confuse new users (especially those which rely on the xm command
instead of xl)? Do you know of best practices which
>>> On 26.01.15 at 16:58, wrote:
> On 01/22/15 03:32, Jan Beulich wrote:
> On 21.01.15 at 18:52, wrote:
>>> On 01/16/15 05:09, Jan Beulich wrote:
>>> On 03.10.14 at 00:40, wrote:
> +
> +/* Only adjust byte_cnt 1 time */
> +if ( bytes[0] == 0x66 ) /* operan
If the new target is relative to the current target, do not remove
videoram again: it has already been removed from the current target.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- add videoram when setting maxmem.
---
tools/libxl/libxl.c | 12 ++--
1 file changed, 6 insert
1 - 100 of 192 matches
Mail list logo
