flight 109928 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 11 guest-start fail REGR. vs. 109898
test-armhf-armhf-
On Tue, 2017-05-23 at 16:48 -0700, Bart Van Assche wrote:
> Target drivers must guarantee that struct se_cmd and struct se_tmr_req
> exist as long as target_tmr_work() is in progress. Since the last
> access by the LIO core is a call to .check_stop_free() and since the
> Xen scsiback .check_stop_fr
flight 109950 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109950/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a04ec6d9f70f7eedf5ab49b098970245270fa594
baseline version:
ovmf b0b626ea2f16faca9f864
On Tue, 2017-05-23 at 16:48 -0700, Bart Van Assche wrote:
> scsiback_release_cmd() must not dereference se_cmd->se_tmr_req
> because that memory is freed by target_free_cmd_mem() before
> scsiback_release_cmd() is called. Fix this use-after-free by
> inlining struct scsiback_tmr into struct vscsibk
On Tue, 2017-05-23 at 16:48 -0700, Bart Van Assche wrote:
> This patch simplifies the implementation of the scsiback driver
> but does not change its behavior.
>
> Signed-off-by: Bart Van Assche
> Cc: Juergen Gross
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> Cc: David Disseldorp
> Cc: xen
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 109926 qemu-upstream-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109926/
Fai
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 109925 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109925/
Failures :-/
Largely mechanical changes to aid unification of xen_vcpu_restore()
logic for PV, PVH and PVHVM.
xen_vcpu_setup(): the only change in logic is that clamp_max_cpus()
is now handled inside the "if (!xen_have_vcpu_info_placement)" block.
xen_vcpu_restore(): code movement from enlighten_pv.c to enlig
If CONFIG_SMP is disabled, xen_setup_vcpu_info_placement() is called from
xen_setup_shared_info(). This is fine as far as boot goes, but it means
that we also call it in the restore path. This results in an OOPS
because we assign to pv_mmu_ops.read_cr2 which is __ro_after_init.
Also, though less p
This patch series fixes a bunch of issues in the xen_vcpu setup
logic.
Simplify xen_vcpu related code: code refactoring in advance of the
rest of the patch series.
Support > 32 VCPUs at restore: unify all vcpu restore logic in
xen_vcpu_restore() and support > 32 VCPUs for PVH*.
Remove vcpu info
The hypercall VCPUOP_register_vcpu_info can fail. This failure is
handled by making per_cpu(xen_vcpu, cpu) point to its shared_info
slot and those without one (cpu >= MAX_VIRT_CPUS) be NULL.
For PVH/PVHVM, this is not enough, because we also need to pull
these VCPUs out of circulation.
Fix for PV
On PVH, PVHVM, at failure in the VCPUOP_register_vcpu_info hypercall
we limit the number of cpus to to MAX_VIRT_CPUS. However, if this
failure had occurred for a cpu beyond MAX_VIRT_CPUS, we continue
to function with > MAX_VIRT_CPUS.
This leads to problems at the next save/restore cycle when there
When Xen restores a PVHVM or PVH guest, its shared_info only holds
up to 32 CPUs. The hypercall VCPUOP_register_vcpu_info allows
us to setup per-page areas for VCPUs. This means we can boot
PVH* guests with more than 32 VCPUs. During restore the per-cpu
structure is allocated freshly by the hypervi
flight 109920 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109920/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-saverestore
fail REGR. vs. 109656
Since the SCSI core zeroes driver-private command data, remove
that code from the xen-scsifront driver.
Signed-off-by: Bart Van Assche
Reviewed-by: Hannes Reinecke
Reviewed-by: Juergen Gross
Reviewed-by: Christoph Hellwig
Cc: xen-de...@lists.xenproject.org
Cc: Johannes Thumshirn
---
drivers/
On Fri, 2 Jun 2017, Julien Grall wrote:
> Hi Andre,
>
> On 05/26/2017 06:35 PM, Andre Przywara wrote:
> > @@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned
> > int virtual_irq)
> > #endif
> > }
> > +/*
> > + * Find an unused LR to insert an IRQ into, starting with the
On Fri, 2 Jun 2017, Julien Grall wrote:
> Hi,
>
> On 05/31/2017 07:49 PM, Julien Grall wrote:
> > > I don't want to introduce any more hardcoding, I just would like the
> > > existing vgic_migrate_irq to be called.
> >
> > It is going to need a bit of rework to get it working with LPI as the code
On 02/06/17 21:02, Andrew Cooper wrote:
> On 01/06/17 13:11, Jan Beulich wrote:
>> Reported-by: Andrew Cooper
>> Signed-off-by: Jan Beulich
> I have finally managed to reproduce the original vmentry failure with an
> XTF test.
FWIW, the vmentry failure is quite subtle.
%es gets reloaded first.
Add name=value parsing options for com1 and com2 to add flexibility
in setting register values for MMIO UART devices.
Maintain backward compatibility with previous positional parameter
specfications.
eg. com1=115200,8n1,0x3f8,4
eg. com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2
eg. com1=baud=115
On 01/06/17 13:11, Jan Beulich wrote:
> Commit aac1df3d03 ("x86/HVM: introduce hvm_get_cpl() and respective
> hook") went too far in one aspect: When emulating a task switch we
> really shouldn't be looking at what hvm_get_cpl() returns, as we're
> switching all segment registers.
>
> However, inst
Implement poll on passive sockets by requesting a delayed response with
mappass->reqcopy, and reply back when there is data on the passive
socket.
Poll on active socket is unimplemented as by the spec, as the frontend
should just wait for events and check the indexes on the indexes page.
Only sup
Keep a list of connected frontends. Use a semaphore to protect list
accesses.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 22 ++
1 file changed, 22 insertions(+)
diff --gi
Introduce a per-frontend data structure named pvcalls_fedata. It
contains pointers to the command ring, its event channel, a list of
active sockets and a tree of passive sockets (passing sockets need to be
looked up from the id on listen, accept and poll commands, while active
sockets only on relea
Allocate a socket. Keep track of socket <-> ring mappings with a new data
structure, called sock_mapping. Implement the connect command by calling
inet_stream_connect, and mapping the new indexes page and data ring.
Allocate a workqueue and a work_struct, called ioworker, to perform
reads and write
Just reply with success to the other end for now. Delay the allocation
of the actual socket to bind and/or connect.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 29 -
1 file changed, 28 insertion
Also add pvcalls-back to the Makefile.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/Kconfig | 12
drivers/xen/Makefile | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index f15
We have one ioworker per socket. Each ioworker goes through the list of
outstanding read/write requests. Once all requests have been dealt with,
it returns.
We use one atomic counter per socket for "read" operations and one
for "write" operations to keep track of the reads/writes to do.
We also u
When the other end notifies us that there is data to be written
(pvcalls_back_conn_event), increment the io and write counters, and
schedule the ioworker.
Implement the write function called by ioworker by reading the data from
the data ring, writing it to the socket by calling inet_sendmsg.
Set
Introduce a xenbus backend for the pvcalls protocol, as defined by
https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
This patch only adds the stubs, the code will be added by the following
patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: boris.ostrov...@oracle.
Implement the accept command by calling inet_accept. To avoid blocking
in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get
scheduled on sk_data_ready (for a passive socket, it means that there
are connections to accept).
Use the reqcopy field to store the request. Accept the ne
Introduce the code to handle xenbus state changes.
Implement the probe function for the pvcalls backend. Write the
supported versions, max-page-order and function-calls nodes to xenstore,
as required by the protocol.
Introduce stub functions for disconnecting/connecting to a frontend.
Signed-off
When the other end notifies us that there are commands to be read
(pvcalls_back_event), wake up the backend thread to parse the command.
The command ring works like most other Xen rings, so use the usual
ring macros to read and write to it. The functions implementing the
commands are empty stubs f
Release both active and passive sockets. For active sockets, make sure
to avoid possible conflicts with the ioworker reading/writing to those
sockets concurrently. Set map->release to let the ioworker know
atomically that the socket will be released soon, then wait until the
ioworker finishes (flus
Introduce the C header file which defines the PV Calls interface. It is
imported from xen/include/public/io/pvcalls.h.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
include/xen/interface/io/pvcalls.h | 121
Allocate a socket. Track the allocated passive sockets with a new data
structure named sockpass_mapping. It contains an unbound workqueue to
schedule delayed work for the accept and poll commands. It also has a
reqcopy field to be used to store a copy of a request for delayed work.
Reads/writes to
Implement backend_disconnect. Call pvcalls_back_release_active on active
sockets and pvcalls_back_release_passive on passive sockets.
Implement module_exit by calling backend_disconnect on frontend
connections.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
When an active socket has data available, increment the io and read
counters, and schedule the ioworker.
Implement the read function by reading from the socket, writing the data
to the data ring.
Set in_error on error.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@
Call inet_listen to implement the listen command.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen
Hi all,
this series introduces the backend for the newly introduced PV Calls
procotol.
PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them an
On Fri, 26 May 2017, Boris Ostrovsky wrote:
> > static void __pvcalls_back_accept(struct work_struct *work)
> > {
> > + struct sockpass_mapping *mappass = container_of(
> > + work, struct sockpass_mapping, register_work);
> > + struct sock_mapping *map;
> > + struct pvcalls_iowork
On Fri, 26 May 2017, Boris Ostrovsky wrote:
> On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> > Just reply with success to the other end for now. Delay the allocation
> > of the actual socket to bind and/or connect.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: boris.ostrov...@oracle.com
>
On Fri, 26 May 2017, Boris Ostrovsky wrote:
> > static int pvcalls_back_socket(struct xenbus_device *dev,
> > struct xen_pvcalls_request *req)
> > {
> > - return 0;
> > + struct pvcalls_back_priv *priv;
> > + int ret;
> > + struct xen_pvcalls_response *rsp;
> > +
> > + priv
On Fri, 26 May 2017, Boris Ostrovsky wrote:
> On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> > +
> > static void pvcalls_back_work(struct work_struct *work)
> > {
> > + struct pvcalls_back_priv *priv = container_of(work,
> > + struct pvcalls_back_priv, register_work);
> > + int
flight 109918 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109918/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3)broken REGR. vs. 109793
Te
On 05/31/2017 11:42 AM, Julien Grall wrote:
Hi Stefano,
On 30/05/17 22:39, Stefano Stabellini wrote:
On Tue, 30 May 2017, Julien Grall wrote:
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock s
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has t
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
This introduces a function to initialize a virtual ITS.
We maintain a list of virtual ITSes, at the mome
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
+do
+{
+nr_lpis = radix_tree_gang_lookup(&its->d->arch.vgic.pend_lpi_tree,
+ (void **)pirqs, vlpi,
+ ARRAY_SIZE(pirqs));
+
+for ( i = 0;
And I obviously commented on the wrong version :/.I will replicate the
command on v10.
Sorry for the inconvenience.
On 06/02/2017 06:24 PM, Julien Grall wrote:
Hi Andre,
On 05/11/2017 06:53 PM, Andre Przywara wrote:
+do
+{
+nr_lpis =
radix_tree_gang_lookup(&its->d->arch.vgic
Hi Andre,
On 05/11/2017 06:53 PM, Andre Przywara wrote:
+do
+{
+nr_lpis = radix_tree_gang_lookup(&its->d->arch.vgic.pend_lpi_tree,
+ (void **)pirqs, vlpi,
+ ARRAY_SIZE(pirqs));
+
+for ( i = 0;
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.
Signed-off-by: Andre Przywara
Acke
Hi,
On 05/31/2017 07:49 PM, Julien Grall wrote:
I don't want to introduce any more hardcoding, I just would like the
existing vgic_migrate_irq to be called.
It is going to need a bit of rework to get it working with LPI as the
code is currently gated with (p->desc). For what benefits?
Not m
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts. MAPI is just a variant
of this comment, where the LPI ID is the same as the event ID.
We connect the already allocated host
c/s b28044226e1 "x86: make Xen early boot code relocatable" introduces
mov $sym_offs(__image_base__),%esi
to the legacy boot path. However, this is by definition 0, which means the
boot code only functions correctly when Xen is loaded at its preferred
physical address (2M at the time of writ
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
@@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int
virtual_irq)
#endif
}
+/*
+ * Find an unused LR to insert an IRQ into, starting with the LR given
+ * by @lr. If this new interrupt is a PRISTINE LPI, sc
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index d162e89..e78dadf 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -173,6 +173,11 @@ struct pending_irq *gicv3_its_
On 06/02/2017 05:32 PM, Julien Grall wrote:
/* Scan the DT for any ITS nodes and create a list of host ITSes out
of it. */
void gicv3_its_dt_init(const struct dt_device_node *node)
{
diff --git a/xen/include/asm-arm/gic_v3_its.h
b/xen/include/asm-arm/gic_v3_its.h
index 40f4ef5..d162e89
Hi,
Can you please provide comments on the shared patch.
Thanks in advance.
Regards,
~Praveen.
On Wed, 2017-04-19 at 23:15 +0530, Praveen Kumar wrote:
> The patch introduces a new, very flexible way of arranging runqueues
> in Credit2.
> It allows to specify, explicitly and precisely, what pCPU
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
As read_itte() is now eventually used, we add the static keyword.
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.
Signed-off-by: Andre Przywara ---
xen/arch/arm/vgic-v3-its.c | 21 +
1 file changed, 21 insertio
On Thu, 2017-06-01 at 09:43 +0200, Dario Faggioli wrote:
> On Thu, 2017-06-01 at 01:26 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > >
> > > > > On 31.05.17 at 23:20, wrote:
> > > I have not imported augmented and rcu rbtree functionality to the
> > > xen tree,
> > > as there was no spec
Add the missing pieces so that cr-daily-branch knows how to create a
FreeBSD flight. This has been tested by calling `./cr-daily-branch
freebsd`.
Note that there are two missing pieces. The first one is correctly
setting the FREEBSD_BUILDJOB environment variable when calling
make-freebsd-flight, w
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
For each device we allocate one struct pending_irq for each virtual
event (MSI).
Provide a helper function which returns the pointer to the appropriate
struct, to be able to find the right struct when given a virtual
deviceID/eventID pair.
flight 109913 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109913/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
On Thu, 2017-06-01 at 01:26 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 31.05.17 at 23:20, wrote:
> > The patch imports the changes and updates of the rbtree
> > implementaiton
> > from Linux tree. But since, the only current implementation is with
> > tmem.c,
> > which am not much a
On Thu, 2017-06-01 at 10:01 +0200, Dario Faggioli wrote:
> On Wed, 2017-05-31 at 23:56 +0100, Andrew Cooper wrote:
> >
> > As an example, see
> >
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=b01c2fb5834
> > ae
> > a0328db55c310caa34173021d3d
> >
> Nice, I especially like how the c
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap
>
> static int set_affinity_irq(struct irq_data *data, const struct cpumask
> *dest,
> bool force)
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index 10f1ef5..1192f24 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -58,6 +58,8 @@
Hi all,
There are some pending security issues that have been found during the
hardening period, which haven't been pre-disclosed yet.
I am going to delay the release until one week after the embargo has
lifted. I will give an exact time frame when they have been pre-disclosed.
Cheers,
--
On Thu, May 25, 2017 at 3:17 PM, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> These patches add PV display device to libxl and xl.
>
> Changes since v1:
> * add connector id;
> * set connector resolution and id to Xen store;
>
> Oleksandr Grytsov (3):
> libxl: add PV display device
I have two series on my inbox with the same patches. I assume it is a
mistake and only reviewed the "RFC PATCH v2" version.
Let me know if it is not right.
Cheers,
On 06/01/2017 04:18 PM, Sergej Proskurin wrote:
This commit adds (TCR_|TTBCR_)* defines to simplify access to the respective
regi
Hi Sergej,
On 06/01/2017 04:18 PM, Sergej Proskurin wrote:
This commit adds functionality to walk the guest's page tables using the
short-descriptor translation table format for both ARMv7 and ARMv8. The
implementation is based on ARM DDI 0487A-g G4-4189 and ARM DDI 0406C-b
B3-1506.
Signed-off-
On 02/06/17 16:49, Anoob Soman wrote:
> A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn)
> interrupts,in a short period of time. All these evtchn:qemu-dm are bound
> to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU.
> In one configuration, irqbalance ru
On 01/06/17 19:01, Anoob Soman wrote:
> Hi,
>
> Can someone explain, why evtchn_fifo_unmask() requires irqs_disabled().
> What happens, if irqs are not disabled ?
evtchn_fifo_unmask() seems to be not critical, but evtchn_2l_unmask()
might be racy if another event is coming in in the middle. The
B
A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn)
interrupts,in a short period of time. All these evtchn:qemu-dm are bound
to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU.
In one configuration, irqbalance runs every 10 seconds, which means
irqbalance do
Achieve this by expanding pt_irq_create_bind in order to support mapping
interrupts of type PT_IRQ_TYPE_PCI to a PVH Dom0. GSIs bound to Dom0 are always
identity bound, which means the all the fields inside of the u.pci sub-struct
are ignored, and only the machine_irq is actually used in order to d
The installation is performed using the bsdinstall tool, which is part
of the FreeBSD base system. The installer image is setup with the
osstest ssh keys and sshd enabled by default, which allows the test
harness to just ssh into the box, create the install config file and
launch the scripted insta
And introduce built_stash_debugfile in order the keep the previous
behavior of built_stash_file.
Signed-off-by: Roger Pau Monné
Acked-by: Ian Jackson
---
Osstest/TestSupport.pm | 14 --
ts-kernel-build| 4 ++--
ts-xen-build | 8
3 files changed, 18 inser
This is equivalent to the already existing authorized_keys function,
and generates the contents of the known_hosts file that should be
installed on targets.
Signed-off-by: Roger Pau Monné
Acked-by: Ian Jackson
---
Osstest/Debian.pm | 36 +---
Osstest/TestSup
Add the missing pieces so that cr-daily-branch knows how to create a
FreeBSD flight. This has been tested by calling `./cr-daily-branch
freebsd`.
Note that there are two missing pieces. The first one is correctly
setting the FREEBSD_BUILDJOB environment variable when calling
make-freebsd-flight, w
In order to generate the FreeBSD installer image and the install
media.
The install sets are the vanilla ones generated by the 'ftp' release
target. The installer image is handcrafted based on the filesystem
created by the 'bootonly' target, which is then populated with the ssh
host keys, and set
Hello,
This series introduces initial FreeBSD host support to osstest. The
current series allow installing a bare-metal host with FreeBSD and
building FreeBSD on it in order to generate new install media that can
be fed into the installer script.
This is still very limited, since no Xen testing i
This is used in order to get the per-host tftp prefix, used to store
the host initrd file.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
Osstest/TestSupport.pm | 8 +++-
ts-host-install| 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff -
This requires changes in several places in order to accommodate the
FreeBSD build, which although it's a build job, it doesn't have the
same set of dependencies as the current builds.
First, a new build recipe is added to sg-run-job, and accordingly
sg-run-job is also made aware about the differen
Due to the nature of the FreeBSD install media, which is
self-generated from the ts-freebsd-build script, the hostflags set to
FreeBSD jobs are related to the current version under test.
The following hostflags might need to be fetched from the runvars of a
previous build-$arch-freebsd job:
- sh
This run is configured for baseline tests only.
flight 71481 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71481/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
flight 109935 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109935/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
flight 109910 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109910/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
106776
build-armhf-xs
Hi Sergej,
On 06/01/2017 04:18 PM, Sergej Proskurin wrote:
This commit adds functionality to walk the guest's page tables using the
long-descriptor translation table format for both ARMv7 and ARMv8.
Similar to the hardware architecture, the implementation supports
different page granularities (4
On 06/02/2017 04:41 AM, Roger Pau Monne wrote:
> On Thu, Jun 01, 2017 at 06:13:22PM -0400, Boris Ostrovsky wrote:
>>> @@ -696,7 +777,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
>>> struct hvm_irq_dpci *dpci = domain_get_irq_dpci(d);
>>> struct hvm_pirq_dpci *pirq_dpci =
This run is configured for baseline tests only.
flight 71480 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71480/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
On Fri, Jun 02, 2017 at 12:16:06PM +0100, Anthony PERARD wrote:
> On Fri, Jun 02, 2017 at 10:58:54AM +0100, Roger Pau Monné wrote:
> > On Fri, Jun 02, 2017 at 11:33:50AM +0200, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > >
> > > Is there any method to boot PVHv2 domain using a kernel fetched f
On Fri, Jun 02, 2017 at 10:58:54AM +0100, Roger Pau Monné wrote:
> On Fri, Jun 02, 2017 at 11:33:50AM +0200, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > Is there any method to boot PVHv2 domain using a kernel fetched from
> > that domain's disk image, _without_ mounting it in dom0? Something
On Wed, May 31, 2017 at 05:45:14AM -0600, Jan Beulich wrote:
> >>> On 31.05.17 at 13:14, wrote:
> > On Tue, May 30, 2017 at 11:59:31PM -0600, Jan Beulich wrote:
> >> >>> On 30.05.17 at 19:40, wrote:
> >> > On 29/05/17 16:40, Jan Beulich wrote:
> >> > On 18.05.17 at 19:09, wrote:
> >> >>> The
Hi,
I'm trying to passthrough USB controllers (details below) to a HVM domain
with qemu running in stubdomain. There are two of them (EHCI and xHCI),
neither of them works. The stubdomain is non-standard Linux
based with Qemu 2.8.0. Both dom0 and guest are running Linux 4.9.29 very
close to vanil
flight 109932 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109932/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b0b626ea2f16faca9f864599384fd184a89e0195
baseline version:
ovmf b33b1055b0026f36be97f
On 02/06/17 00:54, Paratey, Swapnil wrote:
>
>>> Should I submit a v8 with the "CONFIG_HAS_PCI" macro specifications for
>>> the case statements? I apologize for not trying the build for ARM
>>> beforehand.
>> Yes please.
>>
>> ~Andrew
>
> Should the contents of "enum serial_param_type" and
> "stat
flight 109903 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109903/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 3 host-install(3)broken REGR. vs. 10984
On Fri, Jun 02, 2017 at 11:33:50AM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
>
> Is there any method to boot PVHv2 domain using a kernel fetched from
> that domain's disk image, _without_ mounting it in dom0? Something like
> pvgrub was for PV.
Hello,
Anthony (Cced) is working on an OVMF po
Hi,
Is there any method to boot PVHv2 domain using a kernel fetched from
that domain's disk image, _without_ mounting it in dom0? Something like
pvgrub was for PV.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read tex
1 - 100 of 113 matches
Mail list logo
