>>> On 29.05.17 at 21:05, wrote:
> Creating the domains with
>
> xl -vvv create ...
>
> showed the numbers of superpages and normal pages allocated for the
> domain.
>
> The following allocation pattern resulted in a slow domain:
>
> xc: detail: PHYSICAL MEMORY ALLOCATION:
> xc: detail: 4KB
>>> On 30.05.17 at 08:36, wrote:
> On Mon, May 29, Jan Beulich wrote:
>
>> Well, no, what jitter may be acceptable depends on the
>> applications running inside the guest. I.e. you can only know
>> for yourself or ask the application vendor(s). I think such an
>> option, if we really want to have
>>> On 30.05.17 at 08:41, wrote:
> On Mon, May 29, Jan Beulich wrote:
>
>> Finally I don't think a host wide option will do. If it is to be of use
>> (considering that it used wrong may break applications), it needs
>> to be per-domain, and its value needs to be migrated (perhaps
>> in the form o
On Mon, May 29, 2017 at 10:28:03AM -0700, PGNet Dev wrote:
> On 5/29/17 10:03 AM, Roger Pau Monné wrote:
[...]
> > In any case, please
> > hold off before trying Dom0, it's still not in a working state.
>
> Does "hold off" -- in this fuzzy interim -- simply mean -- do NOT specify any
> dom0=XXX?
(Using the correct address for Julien)
On Mon, May 29, 2017 at 06:29:48PM +0100, Roger Pau Monne wrote:
> The current misc/pvh.markdown document refers to PVHv1, remove it to
> avoid confusion with PVHv2 since the PVHv1 code has already been
> removed.
>
> Signed-off-by: Roger Pau Monné
> ---
>
On Fri, May 26, 2017 at 06:14:09PM +0100, Julien Grall wrote:
[...]
> ## Who is in charge of the host bridge?
>
> There are numerous implementation of host bridges which exist on ARM. A part
> of
> them requires a specific driver as they cannot be driven by a generic host
> bridge
> driver. Port
On Mon, May 29, 2017 at 07:14:55PM +0100, Julien Grall wrote:
> On 05/29/2017 03:30 AM, Manish Jaggi wrote:
> > On 5/26/2017 10:44 PM, Julien Grall wrote:
[...]
> > > ## Discovering and registering PCI devices
> > >
> > > The hardware domain will scan the host bridge to find the list of PCI
> > >
flight 109836 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109836/
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
PVHv1 is gone so:
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 17.05.17 at 17:15, wrote:
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -2537,3 +2537,162 @@ bool_t hvm_domain_use_pirq(const struct domain *d,
> const struct pirq *pirq)
> return is_hvm_domain(d) && pirq &&
> pirq->arch.hvm.emuirq != IRQ_UNBOUND;
> }
> +
>
Hi Thanks for the patch.
I welcome the improvement to our documentation.
FAOD I will leave this patch to Ian because he's a native English
speaker.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Wed, May 24, Konrad Rzeszutek Wilk wrote:
> Is there some form of tests that they can run to verify and test
> that this is safe? Or perhaps this is something that is based on the kernel
> versions? Like 4.11 are safe, but 3.18 is not?
I'm not sure why you are asking for specific kernel versio
On 30/05/17 06:53, Manish Jaggi wrote:
Hi Julien,
On 5/29/2017 11:44 PM, Julien Grall wrote:
On 05/29/2017 03:30 AM, Manish Jaggi wrote:
Hi Julien,
Hello Manish,
On 5/26/2017 10:44 PM, Julien Grall wrote:
PCI pass-through allows the guest to receive full control of
physical PCI
device
On Lu, 2017-05-29 at 09:01 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 26.05.17 at 15:41, wrote:
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -37,7 +37,7 @@
> > #include "hvm/save.h"
> > #include "memory.h"
> >
> > -#define XEN_DOMCTL_INTERFACE_VE
Hi Roger,
On 30/05/17 08:53, Roger Pau Monné wrote:
On Mon, May 29, 2017 at 07:14:55PM +0100, Julien Grall wrote:
On 05/29/2017 03:30 AM, Manish Jaggi wrote:
On 5/26/2017 10:44 PM, Julien Grall wrote:
[...]
## Discovering and registering PCI devices
The hardware domain will scan the host br
This patchset enables masking the reception of write_ctrlreg events depending
on the value of certain bits in that register.
The most representative example is filtering out events when the CR4.PGE
bit is being flipped (global TLB flushes)
___
Xen-devel
Add support for filtering out the write_ctrlreg monitor events if they
are generated only by changing certains bits.
A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg
function in order to mask the event generation if the changed bits are
set.
Signed-off-by: Petre Pircalabu
---
Add test for write_ctrlreg event handling.
Signed-off-by: Petre Pircalabu
---
tools/tests/xen-access/xen-access.c | 47 -
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-access.c
i
Hi Roger,
On 30/05/17 08:40, Roger Pau Monné wrote:
On Fri, May 26, 2017 at 06:14:09PM +0100, Julien Grall wrote:
[...]
## Who is in charge of the host bridge?
There are numerous implementation of host bridges which exist on ARM. A part of
them requires a specific driver as they cannot be driv
>>> On 17.05.17 at 17:15, wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -126,6 +126,49 @@ void hvm_pci_intx_deassert(
> spin_unlock(&d->arch.hvm_domain.irq_lock);
> }
>
> +void hvm_gsi_assert(struct domain *d, unsigned int gsi)
> +{
> +struct hvm_irq *hvm_ir
>>> On 17.05.17 at 17:15, wrote:
> Changes since v2:
> - s/vioapic_dom0_map_gsi/vioapic_hwdom_map_gsi/.
> - Don't set hvm_domid in xen_domctl_bind_pt_irq_t (it's ignored).
The implication of the respective earlier comment was for there to
first be a prereq patch added removing this dead field.
Just wanted to give this a nudge to try and get some suggestions on
where to go / what to do about this.
On 28/05/17 09:44, Steven Haigh wrote:
> The last couple of days running on kernel 4.9.29 and 4.9.30 with Xen
> 4.9.0-rc6 I've had a number of ethernet lock ups that have taken my
> system off
On Tue, May 23, 2017 at 11:32:52AM +0200, Felix Schmoll wrote:
> Hi,
>
> I'm Felix Schmoll, one of the GSoC students this year. Go Xen!
>
[...]
>
> ==
> 2.1.1 Function content
> ==
> The "struct domain" as defined in xen/include/xen
On 30/05/17 09:24, Jan Beulich wrote:
On 29.05.17 at 21:05, wrote:
>> Creating the domains with
>>
>> xl -vvv create ...
>>
>> showed the numbers of superpages and normal pages allocated for the
>> domain.
>>
>> The following allocation pattern resulted in a slow domain:
>>
>> xc: detail: PHY
Hello Manish,
On 30/05/17 07:07, Manish Jaggi wrote:
This patch is an RFC on top of Andre's v10 series.
https://www.mail-archive.com/xen-devel@lists.xen.org/msg109093.html
This patch deny's access to ITS region for the guest and also updates
s/deny's/denies/
the acpi tables for dom0.
This
On Mon, May 22, 2017 at 12:50:09PM +0100, Andrew Cooper wrote:
> xc_{get,set}_hvm_param() are deprecated because they truncate their value
> parameter in 32bit builds of libxc, and are therefore unfit for use.
>
> As there is only a single remaining user, switch that user over to
> xc_hvm_param_ge
>>> On 30.05.17 at 12:33, wrote:
> On 30/05/17 09:24, Jan Beulich wrote:
> On 29.05.17 at 21:05, wrote:
>>> Creating the domains with
>>>
>>> xl -vvv create ...
>>>
>>> showed the numbers of superpages and normal pages allocated for the
>>> domain.
>>>
>>> The following allocation pattern res
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 so far.
However for forwarded interrupts (Dom0 only so far) this may lead to a
deadlock with the following call chain:
- MMIO access to change the IR
Sorry for not replying earlier. I was on vacation.
On Wed, May 24, 2017 at 01:29:59AM +0800, Zhongze Liu wrote:
> Hi there,
>
> Thanks for your comments. They are all very insightful.
>
> Having read through the discussions so far, I can draw the
> following conclusions:
>
> 0. The syntax and s
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
The host supports a certain number of LPI identifiers, as stored in
the GICD_TYPER register.
Store this number from the hardware register in vgic_v3_hw to allow
injecting the very same number into a guest (Dom0).
DomUs get the legacy number of 1
flight 71457 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71457/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-daily-netboot-pygrub 10 guest-start fail REGR. vs. 71408
test-
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
So far irq_to_pending() is just a convenience function to lookup
statically allocated arrays. This will change with LPIs, which are
more dynamic, so the memory for their struct pending_irq might go away.
The proper answer to the issue of prevent
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
The function name gic_remove_from_queues() was a bit of a misnomer,
since it just removes an IRQ from the pending queue, not both queues.
Rename the function to make this more clear, also give it a pointer to
a struct pending_irq directly and re
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
To avoid code duplication in a later patch, introduce a generic function
to remove a virtual IRQ from the VGIC.
Call that function instead of the open-coded version in vgic_migrate_irq().
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c
On Mon, May 29, 2017 at 09:57:58AM +0200, Olaf Hering wrote:
> On Fri, May 26, Ian Jackson wrote:
>
> > This seems like a real problem which should be improved. But maybe we
> > should use Xen's EXTRAVERSION by default ?
>
> After thinking about it, why does the tools build not just enforce a
>
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, teach the VGIC how to deal with irq_to_pending() returning
a NULL pointer.
We just do nothin
On Tue, May 30, 2017 at 12:33:15PM +0100, Wei Liu wrote:
> On Mon, May 29, 2017 at 09:57:58AM +0200, Olaf Hering wrote:
> > On Fri, May 26, Ian Jackson wrote:
> >
> > > This seems like a real problem which should be improved. But maybe we
> > > should use Xen's EXTRAVERSION by default ?
> >
> >
On Mon, May 22, 2017 at 04:05:44PM +0530, Bhupinder Thakur wrote:
> Hi Wei,
>
>
> >> --- a/tools/libxl/libxl_dom.c
> >> +++ b/tools/libxl/libxl_dom.c
> >> @@ -688,6 +688,15 @@ static int libxl__build_dom(libxl__gc *gc, uint32_t
> >> domid,
> >> goto out;
> >> }
> >>
> >> +if (
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
Upon receiving an LPI on the host, we need to find the right VCPU and
virtual IRQ number to get this IRQ injected.
Iterate our two-level LPI table to find the domain ID and the virtual
LPI number quickly when the host takes an LPI. We then look
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.
In that case, why don't
On Mon, May 22, 2017 at 04:33:15PM +0530, Bhupinder Thakur wrote:
> Hi Wei,
>
>
> > [...]
> >> >> @@ -151,13 +154,19 @@ retry_transaction:
> >> >> if (rc) goto out;
> >> >>
> >> >> if (!libxl_only) {
> >> >> -rc = libxl__xs_write_checked(gc, t,
> >> >> GCSPRINTF("%s/frontend",l
On Tue, May 30, Wei Liu wrote:
> What I meant was: this is passing EXTRAVERSION to all subdir targets,
> which seems unnecessary to me. And you already specified a version
> string for seabios.
True, but scripts/buildversion.py insists on --extra 'whatever'.
Olaf
signature.asc
Description: PGP
On 5/30/17 12:29 AM, Roger Pau Monné wrote:
...
> dom0=pvh is what should be used once it's finished. Right now there's
> no PVHv2 Dom0 support in Linux, and the Xen side is not finished. If
> you manage to get this booting, you are going to hit a panic in Xen
> code [0].
...> I think builder='linu
Hi, Dmitry!
On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:
On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in t
On Tue, May 30, 2017 at 02:25:11PM +0200, Olaf Hering wrote:
> On Tue, May 30, Wei Liu wrote:
>
> > What I meant was: this is passing EXTRAVERSION to all subdir targets,
> > which seems unnecessary to me. And you already specified a version
> > string for seabios.
>
> True, but scripts/buildversi
Hi, Dmitry!
On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksan
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.
I am not
>>> On 03.05.17 at 10:44, wrote:
> +/*
> + * PSR features are managed per socket. Below structure defines the members
> + * used to manage these features.
> + * ref_lock - A lock to protect cos_ref.
> + * features - A feature node array used to manage all features enabled.
> + * cos_ref - A re
On 05/29/2017 05:13 AM, Juergen Gross wrote:
> When registering for the Xenstore watch of the node control/sysrq the
> handler will be called at once. Don't issue an error message if the
> Xenstore node isn't there, as it will be created only when an event
> is being triggered.
>
> Signed-off-by: J
>>> On 03.05.17 at 10:44, wrote:
> +static unsigned int get_max_cos_max(const struct psr_socket_info *info)
> +{
> +unsigned int cos_max = 0, i;
> +
> +for ( i = 0; i < PSR_SOCKET_FEAT_NUM; i++ )
> +{
> +const struct feat_node *feat = info->features[i];
> +if ( !feat )
>>> On 03.05.17 at 10:44, wrote:
> +int psr_get_info(unsigned int socket, enum cbm_type type,
> + uint32_t data[], unsigned int array_len)
> +{
> +const struct psr_socket_info *info = get_socket_info(socket);
> +const struct feat_node *feat;
> +enum psr_feat_type feat_t
>>> On 03.05.17 at 10:44, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -476,23 +476,34 @@ static struct psr_socket_info *get_socket_info(unsigned
> int socket)
> return socket_info + socket;
> }
>
> +static struct feat_node *psr_get_feat_and_type(unsigned int socket,
Occasionally, on certain Broadwell CPUs MSR_IA32_LASTINTTOIP has been
observed to have the top three bits corrupted as though the MSR is using
the LBR_FORMAT_EIP_FLAGS_TSX format. This is incorrect and causes a
vmentry failure -- the MSR should contain an offset into the current
code segment. This
flight 109839 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109839/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 7 host-ping-check-xen fail REGR. vs. 109656
test-amd64-amd64-xl
Wei Liu writes ("Re: [PATCH 1/1] xl man page cleanup and fixes"):
> Hi Thanks for the patch.
>
> I welcome the improvement to our documentation.
>
> FAOD I will leave this patch to Ian because he's a native English
> speaker.
Thanks. I read the first half of the patch and it was good. Good
eno
Armando Vega writes ("[PATCH 0/1] xl man page cleanup and fixes proposal"):
> If you accept this patch I would gladly donate my time to fixing the
> rest of the man pages, as I did notice the same problems in some of
> them.
I'd love more patches like that one.
> I have a personal fork of this re
On 05/30/2017 06:27 AM, Steven Haigh wrote:
> Just wanted to give this a nudge to try and get some suggestions on
> where to go / what to do about this.
>
> On 28/05/17 09:44, Steven Haigh wrote:
>> The last couple of days running on kernel 4.9.29 and 4.9.30 with Xen
>> 4.9.0-rc6 I've had a number
Hello,
Your Signed-off-by is missing in the commit message.
Cheers,
On 29/05/17 19:01, Armando Vega wrote:
---
docs/man/xl.pod.1.in | 362 +--
1 file changed, 179 insertions(+), 183 deletions(-)
diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.p
On 30/05/17 15:05, Ross Lagerwall wrote:
> Occasionally, on certain Broadwell CPUs MSR_IA32_LASTINTTOIP has been
> observed to have the top three bits corrupted as though the MSR is using
> the LBR_FORMAT_EIP_FLAGS_TSX format. This is incorrect and causes a
> vmentry failure -- the MSR should conta
On Tue, May 30, Wei Liu wrote:
> In that case, can you confine such hackery to be seabios only?
Is it worth the hassle? It seems only ipxe would recognize the
EXTRAVERSION. And how would I actually limit it to seabios? Something
like "make $(filter-out subdir-seabios-dir, subdirs-$@)"?
Olaf
si
Ian Jackson writes ("[OSSTEST PATCH 2/3] ap-common: Switch to Linux 4.9 by
default"):
> I ran a special report[1] to see what to expect and:
...
It seems I ran or read this wrong. In fact, my change is stuck in the
osstest self push gate because:
osstest service owner writes ("[osstest test] 10
On Tue, May 30, 2017 at 11:27:05AM +0200, Olaf Hering wrote:
> On Wed, May 24, Konrad Rzeszutek Wilk wrote:
>
> > Is there some form of tests that they can run to verify and test
> > that this is safe? Or perhaps this is something that is based on the kernel
> > versions? Like 4.11 are safe, but 3
flight 109855 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109855/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf d1a237abf651f181e6b11fbd7358abf07684c7c8
baseline version:
xtf 59f844ed70f7370da58fa5
>>> On 03.05.17 at 10:44, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -118,11 +118,13 @@ static const struct feat_props {
> * COS ID. Every entry of cos_ref corresponds to one COS ID.
> */
> struct psr_socket_info {
> -bool feat_init;
> -spinlock_t re
On Tue, May 30, 2017 at 04:24:18PM +0200, Olaf Hering wrote:
> On Tue, May 30, Wei Liu wrote:
>
> > In that case, can you confine such hackery to be seabios only?
>
> Is it worth the hassle? It seems only ipxe would recognize the
> EXTRAVERSION. And how would I actually limit it to seabios? Somet
On 31/05/17 00:18, Boris Ostrovsky wrote:
> On 05/30/2017 06:27 AM, Steven Haigh wrote:
>> Just wanted to give this a nudge to try and get some suggestions on
>> where to go / what to do about this.
>>
>> On 28/05/17 09:44, Steven Haigh wrote:
>>> The last couple of days running on kernel 4.9.29 an
On Tue, May 30, Wei Liu wrote:
> subdirs-seabios-dir: EXTRAVERSION=XXX
> Limit it to the one that needs the environment variable -- seabios or
> ipxe.
Ok, I will try it. Last time I looked environment did not work.
Olaf
signature.asc
Description: PGP signature
>>> On 30.05.17 at 16:05, wrote:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -28,6 +28,9 @@
> #define PADDR_MASK ((1UL << PADDR_BITS)-1)
> #define VADDR_MASK ((1UL << VADDR_BITS)-1)
>
> +#define VADDR_TOP_BIT (1UL
On 05/30/2017 10:28 AM, Ian Jackson wrote:
> Ian Jackson writes ("[OSSTEST PATCH 2/3] ap-common: Switch to Linux 4.9 by
> default"):
>> I ran a special report[1] to see what to expect and:
> ...
>
> It seems I ran or read this wrong. In fact, my change is stuck in the
> osstest self push gate bec
On 30/05/17 12:43, Jan Beulich wrote:
On 30.05.17 at 12:33, wrote:
>> On 30/05/17 09:24, Jan Beulich wrote:
>> On 29.05.17 at 21:05, wrote:
Creating the domains with
xl -vvv create ...
showed the numbers of superpages and normal pages allocated for the
domai
On 30/05/17 15:25, Boris Ostrovsky wrote:
> On 05/29/2017 05:13 AM, Juergen Gross wrote:
>> When registering for the Xenstore watch of the node control/sysrq the
>> handler will be called at once. Don't issue an error message if the
>> Xenstore node isn't there, as it will be created only when an e
>>> On 30.05.17 at 16:57, wrote:
> On 30/05/17 12:43, Jan Beulich wrote:
> On 30.05.17 at 12:33, wrote:
>>> On 30/05/17 09:24, Jan Beulich wrote:
But if the OS allocated large pages internally for relevant data
structures, those obviously won't come from that necessarily 4k-
ma
>>> On 03.05.17 at 10:44, wrote:
> Only can one COS ID be used by one domain at one time. That means all enabled
> features' COS registers at this COS ID are valid for this domain at that
> time.
>
> When user updates a feature's value, we need make sure all other features'
> values are not affe
On 16/05/17 20:02, Boris Ostrovsky wrote:
Hi Boris,
Sorry for the delay, I was out traveling.
rc = evtchn_bind_to_user(u, bind_interdomain.local_port);
-if (rc == 0)
+if (rc == 0) {
rc = bind_interdomain.local_port;
+selected_cpu = cpumask_ne
>>> On 03.05.17 at 10:44, wrote:
> static int find_cos(const uint32_t val[], unsigned int array_len,
> enum psr_feat_type feat_type,
> const struct psr_socket_info *info)
> {
> +unsigned int cos, i;
> +const unsigned int *ref = info->cos_ref;
> +
With gcc7 the aarch64 build in staging fails:
xc_dom_arm.c: In function 'meminit':
xc_dom_arm.c:229:31: error: 'domctl.u.address_size.size' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
if ( domctl.u.address_size.size == 0 )
~^
On 30/05/17 16:27, Olaf Hering wrote:
> With gcc7 the aarch64 build in staging fails:
>
> xc_dom_arm.c: In function 'meminit':
> xc_dom_arm.c:229:31: error: 'domctl.u.address_size.size' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> if ( domctl.u.address_size.
>>> On 03.05.17 at 10:44, wrote:
> +struct cos_write_info
> +{
> +unsigned int cos;
> +struct feat_node *feature;
> +uint32_t *val;
> +enum psr_feat_type feat_type;
> +};
> +
> +static void do_write_psr_msrs(void *data)
> +{
> +struct cos_write_info *info = data;
> +unsigne
On Thu, May 18, 2017 at 01:34:31AM -0400, Lan Tianyu wrote:
> This patch is to introduct an abstract layer for arch vIOMMU implementation
> to deal with requests from dom0. Arch vIOMMU code needs to provide callback
> to perform create, destroy and query capabilities operation.
>
> Signed-off-by:
On Thu, May 18, 2017 at 01:34:33AM -0400, Lan Tianyu wrote:
> This patch is to add irq request callback for platform implementation
> to deal with irq remapping request.
>
> Signed-off-by: Lan Tianyu
> ---
> xen/common/viommu.c | 15 +
> xen/include/asm-x86/viommu.h | 73
>
On Thu, May 18, 2017 at 01:34:36AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> This patch is to add XEN_DOMCTL_viommu_op hypercall. This hypercall
> comprise three sub-command:
> - query capabilities of one specific type vIOMMU emulated by Xen
> - create vIOMMU in Xen hypervisor with viommu typ
On Thu, May 18, 2017 at 01:34:40AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> If guest is configured to have a vIOMMU, create it during domain construction.
>
> Signed-off-by: Chao Gao
> Signed-off-by: Lan Tianyu
> ---
> tools/libxl/libxl_arch.h | 5 +
> tools/libxl/libxl_arm.c|
On Thu, May 18, 2017 at 01:34:42AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> This patch adds VVTD MMIO handler to deal with MMIO access.
>
> Signed-off-by: Chao Gao
> Signed-off-by: Lan Tianyu
> ---
> xen/arch/x86/hvm/vvtd.c | 127
>
> 1 f
On Thu, May 18, 2017 at 01:34:51AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> Introduce a new binding relationship and provide a new interface to
> manage the new relationship.
>
> Signed-off-by: Chao Gao
> Signed-off-by: Lan Tianyu
> ---
> tools/libxc/include/xenctrl.h | 17 ++
> too
On Thu, May 18, 2017 at 01:34:41AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> This patch adds create/destroy/query function for the emulated VTD
> and adapts it to the common VIOMMU abstraction.
>
> Signed-off-by: Chao Gao
> Signed-off-by: Lan Tianyu
> ---
> xen/arch/x86/hvm/Makefile
On Thu, May 18, 2017 at 01:34:32AM -0400, Lan Tianyu wrote:
> This patch is to introduce create, destroy and query capabilities
> command for vIOMMU. vIOMMU layer will deal with requests and call
> arch vIOMMU ops.
>
> Signed-off-by: Lan Tianyu
> ---
> xen/common/domctl.c | 3 +++
> xen
On Thu, May 18, 2017 at 01:34:34AM -0400, Lan Tianyu wrote:
> This patch is to add get_irq_info callback for platform implementation
> to convert irq remapping request to irq info (E,G vector, dest, dest_mode
> and so on).
>
> Signed-off-by: Lan Tianyu
> ---
> xen/common/viommu.c | 16 +
On Tue, May 30, Andrew Cooper wrote:
> Does
> +domctl.u.address_size.size = 0;
> help?
Likely yes. I just scanned the buildlogs and found this failure.
I do not have a ARM toolchain around to double check.
Not sure why the marco, or its usage, is not like 'struct xen_domctl domctl =
{}'
Ola
>>> On 30.05.17 at 17:36, wrote:
> On Thu, May 18, 2017 at 01:34:31AM -0400, Lan Tianyu wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -73,6 +73,17 @@ config TMEM
>>
>>If unsure, say Y.
>>
>> +config VIOMMU
>> +def_bool y
>> +prompt "Xen vIOMMU Support" if
On 30/05/17 16:40, Olaf Hering wrote:
> On Tue, May 30, Andrew Cooper wrote:
>
>> Does
>> +domctl.u.address_size.size = 0;
>> help?
> Likely yes. I just scanned the buildlogs and found this failure.
> I do not have a ARM toolchain around to double check.
> Not sure why the marco, or its usage,
>>> On 30.05.17 at 17:36, wrote:
> On Thu, May 18, 2017 at 01:34:41AM -0400, Lan Tianyu wrote:
>> --- a/xen/arch/x86/hvm/Makefile
>> +++ b/xen/arch/x86/hvm/Makefile
>> @@ -22,6 +22,7 @@ obj-y += rtc.o
>> obj-y += save.o
>> obj-y += stdvga.o
>> obj-y += vioapic.o
>> +obj-y += vvtd.o
>
> Please
Boris Ostrovsky writes ("Re: Nested virt broken in Linux 4.9 (was Re: [OSSTEST
PATCH 2/3] ap-common: Switch to Linux 4.9 by default [and 1 more messages])"):
> On 05/30/2017 10:28 AM, Ian Jackson wrote:
> > osstest service owner writes ("[osstest test] 109837: regressions - FAIL"):
> >> Tests whic
Hi Ian,
On 30/05/17 16:47, Ian Jackson wrote:
Boris Ostrovsky writes ("Re: Nested virt broken in Linux 4.9 (was Re: [OSSTEST PATCH
2/3] ap-common: Switch to Linux 4.9 by default [and 1 more messages])"):
On 05/30/2017 10:28 AM, Ian Jackson wrote:
osstest service owner writes ("[osstest test]
Julien Grall writes ("Re: Nested virt broken in Linux 4.9 (was Re: [OSSTEST
PATCH 2/3] ap-common: Switch to Linux 4.9 by default [and 1 more messages])"):
> There are two missing patches in Linux 4.9 to be able to boot on the
> Arndale:
> - c827283586a4 "ARM: 8636/1: Cleanup sanity_check_me
Hi Ian,
On 30/05/17 17:13, Ian Jackson wrote:
Julien Grall writes ("Re: Nested virt broken in Linux 4.9 (was Re: [OSSTEST PATCH
2/3] ap-common: Switch to Linux 4.9 by default [and 1 more messages])"):
There are two missing patches in Linux 4.9 to be able to boot on the
Arndale:
- c8272
From: Gregory Herrero
Since fn_result member is shared across all cpus, it must be filled
only if an error happens. Assume CPU1 detects an error and set fn_result
to -1, then CPU2 doesn't detect an error and set fn_result to 0. The
error detected by CPU1 will be ignored.
Signed-off-by: Gregory H
Julien Grall writes ("Re: Nested virt broken in Linux 4.9 (was Re: [OSSTEST
PATCH 2/3] ap-common: Switch to Linux 4.9 by default [and 1 more messages])"):
> On 30/05/17 17:13, Ian Jackson wrote:
...
> > I see. Can you do that please ? It's blocking moving our testing to
> > a non-ancient kernel.
Hi all
We just finished branching 4.9. The staging branch is now open for
committing new patches.
As always please be cautious about what patches are accepted into
staging until 4.9 is released. For bug fixes please commit them to
staging first then backport them to staging-4.9.
Thanks,
--
Jul
On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
>
> On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
> >On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
> >>Hi, Dmitry!
> >>
> >>On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
> >>>Hi Olek
On 25/05/17 16:54, Julien Grall wrote:
Hi,
The patches fixing the 2 outstanding regressions have been merged.
I would like to make another attempt to branch with the RC (4.9 RC7). I
don't want to branch when master != staging, so please avoid committing
new patches to staging now to let maste
1 - 100 of 137 matches
Mail list logo
