fix two flaws in the patch (93358e8e VT-d: introduce update_irte to update
irte safely).
Signed-off-by: Chao Gao
---
xen/drivers/passthrough/vtd/intremap.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/intremap.c
b/xen/drivers/passthroug
>>> On 11.04.17 at 18:09, wrote:
> On 11/04/17 16:36, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1955,25 +1955,32 @@ static int _hvm_emulate_one(struct hvm_e
>> memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf,
>> vio->mmio_insn_bytes);
flight 107371 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 107176
Tests which are f
On 12/04/2017 08:43, Jan Beulich wrote:
On 11.04.17 at 18:09, wrote:
>> On 11/04/17 16:36, Jan Beulich wrote:
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> +++ b/xen/arch/x86/hvm/emulate.c
>>> @@ -1955,25 +1955,32 @@ static int _hvm_emulate_one(struct hvm_e
>>> memcpy(vio->mmio_insn, hvme
flight 71174 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71174/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like
71149
test-amd64-i
On 11/04/17 19:08, Praveen Kumar wrote:
> The patch actually doesn't impact the functionality as such. This only
> replaces
> bool_t with bool in credit2.
>
> Signed-off-by: Praveen Kumar
Reviewed-by: George Dunlap
Julien, is this sort of thing allowed in at this point? It's not
exactly a bu
flight 107370 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107370/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qcow2 16 guest-localmigrate/x10 fail in 107357 pass in
107370
test-armhf-armhf-libvirt
>>> On 12.04.17 at 10:06, wrote:
> On 12/04/2017 08:43, Jan Beulich wrote:
> On 11.04.17 at 18:09, wrote:
>>> On 11/04/17 16:36, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1955,25 +1955,32 @@ static int _hvm_emulate_one(struct hvm_e
>>> On 12.04.17 at 02:04, wrote:
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -200,8 +200,9 @@ static void update_irte(struct iommu *iommu, struct
> iremap_entry *entry,
> else
> {
> /*
> - * If the caller requests a
flight 107376 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107376/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 971a2d520e5e5e4c46452e6a99f343f1f8892e32
baseline version:
ovmf f8c1facf34a1f65082fa2
>>> On 12.04.17 at 07:53, wrote:
> On 17-04-11 09:01:53, Jan Beulich wrote:
>> >>> On 01.04.17 at 15:53, wrote:
>> > +info->cos_ref[cos]--;
>> > +spin_unlock(&info->ref_lock);
>> > +
>> > +d->arch.psr_cos_ids[socket] = 0;
>> > +}
>>
>> Overall, while you say in the re
>>> On 12.04.17 at 07:55, wrote:
> On 17-04-11 09:11:20, Jan Beulich wrote:
>> >>> On 01.04.17 at 15:53, wrote:
>> > @@ -611,7 +679,40 @@ static int insert_val_to_array(uint32_t val[],
>> > enum cbm_type type,
>> > uint32_t new_val)
>>> On 12.04.17 at 08:05, wrote:
> On 17-04-11 09:39:55, Jan Beulich wrote:
>> >>> On 01.04.17 at 15:53, wrote:
>> > @@ -755,7 +765,7 @@ static int gather_val_array(uint32_t val[],
>> > cos = 0;
>> >
>> > /* Value getting order is same as feature array. */
>> > -fe
On Wed, Apr 12, 2017 at 02:57:23AM -0600, Jan Beulich wrote:
On 12.04.17 at 02:04, wrote:
>> --- a/xen/drivers/passthrough/vtd/intremap.c
>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>> @@ -200,8 +200,9 @@ static void update_irte(struct iommu *iommu, struct
>> iremap_entry *entry,
>>
Hi,
On 12/04/17 01:44, Andre Przywara wrote:
> When LPIs get unmapped by a guest, they might still be in some LR of
> some VCPU. Nevertheless we remove the corresponding pending_irq
> (possibly freeing it), and detect this case (irq_to_pending() returns
> NULL) when the LR gets cleaned up later.
>
On Wed, Apr 12, 2017 at 05:04:41PM +1200, Glenn Enright wrote:
> Hi there
>
> Has anyone seen or been working on patches for valgrind for recent versions
> of xen?
>
> I was trying 3.13 from SVN against xen 4.7.2 and see that support for that
> version is not present. Per
> https://blog.xenproje
Hi Andre,
On 12/04/17 01:44, 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).
DOM0 number should be derived
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
So far irq_to_pending() is just a convenience function to lookup
in statically allocated arrays. This will change with LPIs, which are
more dynamic.
So move the irq_to_pending() call under the VGIC VCPU lock, so we
only use this pointer while ho
On 2017/4/12 14:17, Alexey G wrote:
On Tue, 11 Apr 2017 15:32:09 -0700 (PDT)
Stefano Stabellini wrote:
On Tue, 11 Apr 2017, hrg wrote:
On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini
wrote:
On Mon, 10 Apr 2017, Stefano Stabellini wrote:
On Mon, 10 Apr 2017, hrg wrote:
On Sun, Apr 9,
On 2017/4/12 6:32, Stefano Stabellini wrote:
On Tue, 11 Apr 2017, hrg wrote:
On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini
wrote:
On Mon, 10 Apr 2017, Stefano Stabellini wrote:
On Mon, 10 Apr 2017, hrg wrote:
On Sun, Apr 9, 2017 at 11:55 PM, hrg wrote:
On Sun, Apr 9, 2017 at 11:52
Hi Andre,
On 12/04/17 01:44, 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 handle with irq_to_pending() returning
a NULL pointer.
We just do noth
>>> On 12.04.17 at 04:41, wrote:
> On Wed, Apr 12, 2017 at 02:57:23AM -0600, Jan Beulich wrote:
> On 12.04.17 at 02:04, wrote:
>>> + * If a caller want an atomic update from the views of VT-d
>>
>>wants
>>
>>Also what do you mean by "from the views of VT-d"?
>
> OK. will fix this too
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. We only care about mapped LPIs, so we can get away
with having struct pending_irq's only
Hi Andre,
On 12/04/17 01:44, 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 this information quickly when
the host takes an LPI. Call the existing injection function
Signed-off-by: Ishani Chugh
---
tools/clang-format/tests/.clang-format | 88 ++
tools/clang-format/tests/correct.c | 73
tools/clang-format/tests/test.c| 69 ++
3 files changed, 230 insertions(+)
cre
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers.
The MMIO read and write accesses are protec
On 12/04/17 09:57, Jan Beulich wrote:
On 12.04.17 at 02:04, wrote:
>> --- a/xen/drivers/passthrough/vtd/intremap.c
>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>> @@ -200,8 +200,9 @@ static void update_irte(struct iommu *iommu, struct
>> iremap_entry *entry,
>> else
>> {
>>
On Wed, Apr 12, 2017 at 04:32:06AM -0600, Jan Beulich wrote:
On 12.04.17 at 04:41, wrote:
>> On Wed, Apr 12, 2017 at 02:57:23AM -0600, Jan Beulich wrote:
>> On 12.04.17 at 02:04, wrote:
+ * If a caller want an atomic update from the views of VT-d
>>>
>>>wants
>>>
>>>Also wha
flight 107394 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107394/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd646 coverity-upload fail REGR. vs. 106549
version t
Hi Ishani,
> On 12 Apr 2017, at 11:49, Ishani Chugh
> wrote:
Here you would normally add a short description of the patch (also called cover
letter). In this case, you probably want to describe:
a) What you have done
b) Link to
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Code_S
On 12/04/17 11:13, Julien Grall wrote:
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
So far irq_to_pending() is just a convenience function to lookup
in statically allocated arrays. This will change with LPIs, which are
more dynamic.
So move the irq_to_pending() call under the VGIC VCPU
Hello,
Thanks for the comments.
I have created a markdown file for clang-format doc which I will add.
>If so, you want to include this information in the cover letter (see above).
>Or you >could write little bash script which shows how this works
Can you elaborate on the task of bash script? S
>>> On 12.04.17 at 12:58, wrote:
> On 12/04/17 09:57, Jan Beulich wrote:
> On 12.04.17 at 02:04, wrote:
>>> --- a/xen/drivers/passthrough/vtd/intremap.c
>>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>>> @@ -200,8 +200,9 @@ static void update_irte(struct iommu *iommu, struct
>>> iremap_ent
>>> On 12.04.17 at 05:56, wrote:
> On Wed, Apr 12, 2017 at 04:32:06AM -0600, Jan Beulich wrote:
> On 12.04.17 at 04:41, wrote:
>>> On Wed, Apr 12, 2017 at 02:57:23AM -0600, Jan Beulich wrote:
>>> On 12.04.17 at 02:04, wrote:
> + * If a caller want an atomic update from the vi
> On 12 Apr 2017, at 12:51, Ishani wrote:
>
> Hello,
>
> Thanks for the comments.
> I have created a markdown file for clang-format doc which I will add.
>
>> If so, you want to include this information in the cover letter (see above).
>> Or you >could write little bash script which shows ho
On 17-04-12 03:09:56, Jan Beulich wrote:
> >>> On 12.04.17 at 07:53, wrote:
> > On 17-04-11 09:01:53, Jan Beulich wrote:
> >> >>> On 01.04.17 at 15:53, wrote:
> >> > +info->cos_ref[cos]--;
> >> > +spin_unlock(&info->ref_lock);
> >> > +
> >> > +d->arch.psr_cos_ids[socket] =
On 17-04-12 03:13:12, Jan Beulich wrote:
> >>> On 12.04.17 at 07:55, wrote:
> > On 17-04-11 09:11:20, Jan Beulich wrote:
> >> >>> On 01.04.17 at 15:53, wrote:
> >> > @@ -611,7 +679,40 @@ static int insert_val_to_array(uint32_t val[],
> >> > enum cbm_type type,
> >>
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
From: Vijaya Kumar K
This function allows to copy a chunk of data from and to guest physical
memory. It looks up the associated page from the guest's p2m tree
and maps this page temporarily for the time of the access.
This function was origina
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
The target CPU for an LPI is encoded in the interrupt translation table
entry, so can't be easily derived from just an LPI number (short of
walking *all* tables and find the matching LPI).
To avoid this in case we need to know the VCPU (for the
Hi,
On 12/04/17 13:32, Julien Grall wrote:
> Hi Andre,
>
> On 12/04/17 01:44, Andre Przywara wrote:
>> The target CPU for an LPI is encoded in the interrupt translation table
>> entry, so can't be easily derived from just an LPI number (short of
>> walking *all* tables and find the matching LPI).
Fix two flaws in the patch (93358e8e VT-d: introduce update_irte to update
irte safely):
1. Expand a comment in update_irte() to make it clear that VT-d hardware
doesn't update IRTE and software can't update IRTE behind us since we hold
iremap_lock.
2. remove an useless if() statement
Signed-off-b
Hi Andre,
On 12/04/17 01:44, 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.
This remove
>>> On 12.04.17 at 14:23, wrote:
> On 17-04-12 03:09:56, Jan Beulich wrote:
>> >>> On 12.04.17 at 07:53, wrote:
>> > On 17-04-11 09:01:53, Jan Beulich wrote:
>> >> >>> On 01.04.17 at 15:53, wrote:
>> >> > +info->cos_ref[cos]--;
>> >> > +spin_unlock(&info->ref_lock);
>> >> > +
>>
>>> On 12.04.17 at 07:35, wrote:
> Fix two flaws in the patch (93358e8e VT-d: introduce update_irte to update
> irte safely):
> 1. Expand a comment in update_irte() to make it clear that VT-d hardware
> doesn't update IRTE and software can't update IRTE behind us since we hold
> iremap_lock.
> 2.
Hi,
On 12/04/17 13:38, Julien Grall wrote:
> Hi Andre,
>
> On 12/04/17 01:44, 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 capabili
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
Emulate the memory mapped ITS registers and provide a stub to introduce
the ITS command handling framework (but without actually emulating any
commands at this time).
This fixes a misnomer in our virtual ITS structure, where the spec is
confusin
On 12/04/17 13:48, Andre Przywara wrote:
On 12/04/17 13:38, Julien Grall wrote:
On 12/04/17 01:44, Andre Przywara wrote:
+static void vgic_vcpu_enable_lpis(struct vcpu *v)
+{
+uint64_t reg = v->domain->arch.vgic.rdist_propbase;
+unsigned int nr_lpis = BIT((reg & 0x1f) + 1);
+
+if
Hi,
On 12/04/17 11:55, Julien Grall wrote:
> Hi Andre,
>
> On 12/04/17 01:44, Andre Przywara wrote:
>> Allow a guest to provide the address and size for the memory regions
>> it has reserved for the GICv3 pending and property tables.
>> We sanitise the various fields of the respective redistribut
On 12/04/17 14:12, Andre Przywara wrote:
Hi,
Hi,
On 12/04/17 11:55, Julien Grall wrote:
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the vari
On Fri, Apr 07, 2017 at 12:58:14PM +0100, Ian Jackson wrote:
> tl;dr:
> Please apply
>
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> partially revert "xen: Remove event channel notification through
> Xen PCI platform device"
>
> to all stable branches which have a version of the or
flight 107374 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107374/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-vhd 15 guest-start.2fail in 107359 pass in 107374
test-amd64-amd64-xl-qemut-debian
On 12/04/17 01:44, 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 on arm64 - an
On 12/04/17 15:13, Greg KH wrote:
> On Fri, Apr 07, 2017 at 12:58:14PM +0100, Ian Jackson wrote:
>> tl;dr:
>> Please apply
>>
>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>> partially revert "xen: Remove event channel notification through
>> Xen PCI platform device"
>>
>> to all stab
Hi,
On 12/04/17 14:22, Julien Grall wrote:
>
>
> On 12/04/17 01:44, 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.
>>
On Wed, Apr 12, 2017 at 03:26:53PM +0200, Juergen Gross wrote:
> On 12/04/17 15:13, Greg KH wrote:
> > On Fri, Apr 07, 2017 at 12:58:14PM +0100, Ian Jackson wrote:
> >> tl;dr:
> >> Please apply
> >>
> >> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> >> partially revert "xen: Remove event chan
On 12/04/17 14:36, Andre Przywara wrote:
Hi,
On 12/04/17 14:22, Julien Grall wrote:
On 12/04/17 01:44, 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 pai
Greg KH writes ("Re: Please apply "partially revert "xen: Remove event
channel...""):
> On Wed, Apr 12, 2017 at 03:26:53PM +0200, Juergen Gross wrote:
> > On 12/04/17 15:13, Greg KH wrote:
> > > Is this still true? This long thread is totally confusing, is that what
> > > you really want to have
Hi Andre,
On 12/04/17 01:44, 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.
Sign
Hi, Juergen!
On 04/11/2017 03:30 PM, Juergen Gross wrote:
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
While at it remove the pointless second reading of parameters from
Xenstore in the device conn
On 12/04/17 01:44, Andre Przywara wrote:
Hi,
this is a reworked version of the second part of the ITS emulation series,
where the first part has been merged already.
It extends the concept of letting Xen deal with irq_to_pending()
potentially returning NULL, by making sure the retrieval and us
Hi,
On 12/04/17 15:10, Julien Grall wrote:
> Hi Andre,
>
> On 12/04/17 01:44, 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_itt
On 12/04/17 16:13, Oleksandr Andrushchenko wrote:
> Hi, Juergen!
>
>
> On 04/11/2017 03:30 PM, Juergen Gross wrote:
>> Add a parameter for setting the resolution of xen-kbdfront in order to
>> be able to cope with a (virtual) frame buffer of arbitrary resolution.
>>
>> While at it remove the poin
On 12/04/17 15:29, Andre Przywara wrote:
Hi,
On 12/04/17 15:10, Julien Grall wrote:
Hi Andre,
On 12/04/17 01:44, 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
Hi,
On 12/04/17 11:25, Julien Grall wrote:
> Hi Andre,
>
> On 12/04/17 01:44, 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 handle with i
Hi,
On 12/04/17 01:44, 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 insertions(+)
diff -
On 12/04/17 01:44, Andre Przywara wrote:
The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
xen/arch/arm/vgi
On 12/04/17 15:51, Andre Przywara wrote:
Hi,
On 12/04/17 11:25, Julien Grall wrote:
Hi Andre,
On 12/04/17 01:44, 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, tea
On Wed, Apr 12, 2017 at 09:19:34AM +0800, Luwei Kang wrote:
> User can set max freq to specific cpu by
> "xenpm set-scaling-maxfreq "
> or set max freq to all cpu with default cpuid by
> "xenpm set-scaling-maxfreq ".
>
> Set max freq with defaule cpuid will cause
default
> segmentation fault af
On Mon, Mar 27, 2017 at 05:06:25AM -0400, Joshua Otto wrote:
[...]
>
> +int try_read_record(struct xc_sr_read_record_context *rrctx, int fd,
> +struct xc_sr_record *rec)
> +{
> +int rc;
> +xc_interface *xch = rrctx->ctx->xch;
> +size_t offset_out, dataoff, datasz;
On Thu, Mar 30, 2017 at 12:49:07AM -0400, Joshua Otto wrote:
> On Tue, Mar 28, 2017 at 08:52:26PM +0100, Andrew Cooper wrote:
> > On 27/03/17 10:06, Joshua Otto wrote:
> > > diff --git a/tools/libxc/xc_sr_stream_format.h
> > > b/tools/libxc/xc_sr_stream_format.h
> > > index 3291b25..32400b2 100644
Hi Juergen,
On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote:
> Add a parameter for setting the resolution of xen-kbdfront in order to
> be able to cope with a (virtual) frame buffer of arbitrary resolution.
>
> While at it remove the pointless second reading of parameters from
> Xen
>>> On 12.04.17 at 12:49, wrote:
> --- /dev/null
> +++ b/tools/clang-format/tests/correct.c
Is this file supposed to be in correct Xen style? Its name suggests so,
but its contents don't.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https:/
On Thu, Mar 30, 2017 at 01:19:41AM -0400, Joshua Otto wrote:
> >
> > > +};
> > > +
> > > /* callbacks provided by xc_domain_save */
> > > struct save_callbacks {
> > > /* Called after expiration of checkpoint interval,
> > > @@ -46,6 +54,17 @@ struct save_callbacks {
> > > */
> > >
>>> On 01.04.17 at 15:53, wrote:
> @@ -304,10 +305,14 @@ static void cat_init_feature(const struct cpuid_leaf
> *regs,
> switch ( type )
> {
> case PSR_SOCKET_L3_CAT:
> +case PSR_SOCKET_L2_CAT:
> /* cos=0 is reserved as default cbm(all bits within cbm_len are 1).
> */
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID. Since it features a valid bit,
MAPD also covers the "unmap" functionality, which we also cover here.
We store the given guest physical addre
>>> On 01.04.17 at 15:53, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1466,6 +1466,16 @@ long arch_do_domctl(
>PSR_CBM_TYPE_L3_DATA);
> break;
>
> +case XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM:
> +if ( domctl-
>>> On 01.04.17 at 15:53, wrote:
> This patch implements xl/xc changes to support get HW info
> for L2 CAT.
>
> 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
> info.
>
> Example(on machine which only supports L2 CAT):
> Cache Monitoring Technology (CMT):
> Enabled : 0
> Cache
On Thu, Mar 30, 2017 at 02:03:29AM -0400, Joshua Otto wrote:
> On Wed, Mar 29, 2017 at 10:08:02PM +0100, Andrew Cooper wrote:
> > On 27/03/17 10:06, Joshua Otto wrote:
> > > In the context of the live migration algorithm, the precopy iteration
> > > count refers to the number of page-copying iterat
Hello,
I seemed to have overwritten the correct file by the output of the clang-format
tool. My main idea is to compare output file and correct file and take their
comparison. Since there are features which are partially implemented, they are
not bound to be same. Will it be better to refine th
These are things I noticed should be fixed, while trying to make
4.9.0-rc1.
Signed-off-by: Ian Jackson
---
misc/release-checklist.txt | 43 ++-
1 file changed, 18 insertions(+), 25 deletions(-)
diff --git a/misc/release-checklist.txt b/misc/release-checkl
Add some better checking and make the runes a bit more robust.
Signed-off-by: Ian Jackson
---
misc/release-checklist.txt | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/misc/release-checklist.txt b/misc/release-checklist.txt
index f9e7e06..b96964e 100644
--- a/m
In qemu-trad, I made xen-4.9.0-rc1 refer erroneously to the 4.8
branch. That doesn't build. So we are burning the version number
4.9.0-rc1 in xen.git and qemu-trad. (The other trees can remain as
they are.)
Signed-off-by: Ian Jackson
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 del
* Update Config.mk REVISION values to refer to relevant tags.
* Update README version number
* Update xen/Makefile version number
Signed-off-by: Ian Jackson
---
Config.mk| 6 +++---
README | 10 +-
xen/Makefile | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --
Contrary to what I wrote in d0db50ced1f7 "Config.mk: Update for
4.9.0-rc1.1", the build failure with 4.9.0-rc1 was not due to a wrong
qemu tag, but a wrong mini-os tag. So burn 4.9.0-rc1.1 too :-(. (We
can rewind the qemu-trad tag to 4.9.0-rc1; the -rc1 and -rc1.1 tags
are identical.)
Signed-off
On Fri, Mar 31, 2017 at 12:51:46AM -0400, Joshua Otto wrote:
> >
> > > We've also noticed that,
> > > when performing a postcopy without any leading precopy iterations, the
> > > time
> > > required at the destination to 'evict' all of the outstanding pages is
> > > substantial - possibly becau
This series is being posted pro-format. I've pushed them already.
The first patch is routine administrivia. The next two are the result
of me messing up. The final two are release checklist updates,
including attempts to make this kind of mistake less likely.
Thanks,
Ian.
On Mon, Apr 10, 2017 at 09:43:13AM -0400, Konrad Rzeszutek Wilk wrote:
[...]
>
> .. Except that we need some way of doing FLR and Pciback
> is the one doing it.
>
> The right way would be to expand pciback to support the do_flr ioctl
> and combine it with your patch.
>
OK. Does that mean the bu
No matter that we emulate IRET for (guest) real more only right now, we
should get its effect on (virtual) NMI delivery right. Note that we can
simply check the other retire flags also in the !OKAY case, as the
insn emulator now guarantees them to only be set on OKAY.
Signed-off-by: Jan Beulich
-
On 12/04/17 17:16, Dmitry Torokhov wrote:
> Hi Juergen,
>
> On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote:
>> Add a parameter for setting the resolution of xen-kbdfront in order to
>> be able to cope with a (virtual) frame buffer of arbitrary resolution.
>>
>> While at it remove th
This run is configured for baseline tests only.
flight 71176 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71176/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 971a2d520e5e5e4c46452e6a99f343f1f8892e32
baseline v
flight 107378 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107378/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107219
test-amd64-amd64-xl-qemuu-
>>> On 03.04.17 at 18:50, wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1043,16 +1043,44 @@ static struct page_info *merge_chunks(struct
> page_info *pg, unsigned int node,
> return pg;
> }
>
> -static void scrub_free_pages(unsigned int node)
> +static nodem
Hi Andre,
On 12/04/17 01:44, Andre Przywara wrote:
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering LPI on the host can be quickly forwarded to
On 12/04/17 15:44, Ian Jackson wrote:
> Greg KH writes ("Re: Please apply "partially revert "xen: Remove event
> channel...""):
>> On Wed, Apr 12, 2017 at 03:26:53PM +0200, Juergen Gross wrote:
>>> On 12/04/17 15:13, Greg KH wrote:
Is this still true? This long thread is totally confusing, i
flight 107381 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107381/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 107365
REGR. vs. 106822
On Wed, Apr 12, 2017 at 06:04:30PM +0200, Juergen Gross wrote:
> On 12/04/17 17:16, Dmitry Torokhov wrote:
> > Hi Juergen,
> >
> > On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote:
> >> Add a parameter for setting the resolution of xen-kbdfront in order to
> >> be able to cope with a
Hi,
On 12/04/17 17:18, Julien Grall wrote:
> Hi Andre,
>
> On 12/04/17 01:44, Andre Przywara wrote:
>> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
>> pair and actually instantiates LPI interrupts.
>> We connect the already allocated host LPI to this virtual LPI, so that
>
On Mon, Apr 03, 2017 at 03:14:28PM +0530, Bhupinder Thakur wrote:
> 1. Allocate a new pfn and pass on to Xen using a hvm call.
>
> 2. Change in xc_hvm_param_deprecated_check () to allow new vpl011 HVM params,
> which are reusing some deprecated x86 HVM params.
>
> Signed-off-by: Bhupinder Thakur
On Mon, Apr 03, 2017 at 03:14:27PM +0530, Bhupinder Thakur wrote:
[...]
> _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index a612d1f..fe7f795 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/lib
On Mon, Apr 03, 2017 at 03:14:30PM +0530, Bhupinder Thakur wrote:
> Modify the domain structure to to make console specific fields as an array
> indexed
> by the console type. Two console types are defined - PV and VCON.
Why? Can you have both for an ARM guest?
Also this patch alone is going to
1 - 100 of 145 matches
Mail list logo
