* Jiri Slaby wrote:
> On 04/10/2017, 09:35 PM, Josh Poimboeuf wrote:
> > The code should be in a mergeable state after each patch. If only
> > patches 1-3 were merged, the code would be in an inconsistent state,
> > with some functions having confusing ENTRY/SYM_FUNC_END pairs. That
> > compli
On 04/10/2017, 09:35 PM, Josh Poimboeuf wrote:
> The code should be in a mergeable state after each patch. If only
> patches 1-3 were merged, the code would be in an inconsistent state,
> with some functions having confusing ENTRY/SYM_FUNC_END pairs. That
> complicates git history and also makes
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, 2017 a
On 17-04-11 10:03:21, Jan Beulich wrote:
> >>> On 01.04.17 at 15:53, wrote:
> > @@ -94,6 +102,13 @@ struct feat_node {
> > unsigned int cos_max;
> > unsigned int cbm_len;
> >
> > +/*
> > + * An array to save all 'enum cbm_type' values of the feature. It
> > is
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. */
> > -feat->props->get_val(feat, cos, &val[0]);
>
On 17-04-11 09:25:28, Jan Beulich wrote:
> >>> On 01.04.17 at 15:53, wrote:
> > +static void do_write_psr_msr(void *data)
> > +{
> > +struct cos_write_info *info = data;
> > +unsigned int cos= info->cos;
> > +struct feat_node *feat = info->feature;
> > +
> > +if (
On 17-04-11 09:11:20, Jan Beulich wrote:
> >>> On 01.04.17 at 15:53, wrote:
> > @@ -593,7 +616,21 @@ int psr_get_val(struct domain *d, unsigned int socket,
> > /* Set value functions */
> > static unsigned int get_cos_num(const struct psr_socket_info *info)
> > {
> > -return 0;
> > +uns
On 17-04-11 09:01:53, Jan Beulich wrote:
> >>> On 01.04.17 at 15:53, wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -157,10 +157,26 @@ static void free_socket_resources(unsigned int socket)
> > {
> > unsigned int i;
> > struct psr_socket_info *info = socket_info
flight 107372 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107372/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf e399b894f042d3f50d07a8619f7d7e7de410351d
baseline version:
xtf 7a69524b288907b6d29581
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.xenproject.org/2013/01/18/using-valgrind-to-debug-xen-toolstacks/
A starter patch
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/enlighten.c
between commit:
687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820
code")
from the tip tree and commit:
ca7b75377014 ("x86/xen: split off enlighten_pvh.c")
from th
On Wed, Apr 12, 2017 at 02:45:36AM +, Xuquan (Quan Xu) wrote:
>On April 07, 2017 11:24 AM, Chao Gao wrote:
>>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>>operation is operated during one event delivery and incur to inconsistent
>>views of vIOAPIC. For example, i
On 04/11/2017 03:50 PM, Eric Blake wrote:
We now have macros in place to make it less verbose to add a scalar
to QDict and QList, so use them. To make this patch smaller to
review, a couple of subdirectories were done in earlier patches.
Patch created mechanically via:
spatch --sp-file script
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/mmu.c
between commit:
66441bd3cfdc ("x86/boot/e820: Move asm/e820.h to asm/e820/api.h")
from the tip tree and commit:
5159dc315db8 ("x86/xen: split off mmu_pv.c")
from the xen-tip tree.
The code chang
flight 107367 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107367/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On Wed, Apr 12, 2017 at 02:45:36AM +, Xuquan (Quan Xu) wrote:
>On April 07, 2017 11:24 AM, Chao Gao wrote:
>>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>>operation is operated during one event delivery and incur to inconsistent
>>views of vIOAPIC. For example, i
On April 07, 2017 11:24 AM, Chao Gao wrote:
>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>operation is operated during one event delivery and incur to inconsistent
>views of vIOAPIC. For example, if a periodic timer interrupt is from PIT, when
>set the corresponding
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
segmentation fault after commit id d4906b5d05.
This patch will fix this issue and add ability
to set max
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 a guest.
Beside entering the VCPU and the virtual LPI
The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c
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 INVALL command,
for instance), put the VCPU ID in the
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.
Signed-off-by: Andre Przywara
Acked-by: Stefano Stabellini
---
xen/arch/arm
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 moment for the only
purpose of later being able to free them ag
The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just
iterate over all mapped LPIs and filter for those from that particular
VCPU.
Signed-off-by: A
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.
However a *new* LPI may get mapped with the same number
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 --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-i
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 nothing in this case or clean up the LR if the virtual LPI
Increase the count of MMIO regions needed by one for each ITS Dom0 has
to emulate. We emulate the ITSes 1:1 from the hardware, so the number
is the number of host ITSes.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 15 +++
xen/arch/arm/vgic-v3.c | 3
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
---
xen/arch/arm/vgic-v3-its.c | 41 +
1 file changed
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 protected by locks, to avoid any
changing of the property or
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 usage
of the pending_irq pointer is always happ
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 to match the hardware.
Signed-off-by: Andre Przywara
---
For LPIs we later want to dynamically allocate struct pending_irqs.
Let's export the vgic_init_pending_irq() to be able to reuse it.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
xen/arch/arm/vgic.c| 2 +-
xen/include/asm-arm/vgic.h | 1 +
2 files changed, 2 insertions(+), 1
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 for them.
Maintain a radix tree per domain where we d
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 removes a "TBD" comment, as we now populate the processor nu
The INV command instructs the ITS to update the configuration data for
a given LPI by re-reading its entry from the property table.
We don't need to care so much about the priority value, but enabling
or disabling an LPI has some effect: We remove or push virtual LPIs
to their VCPUs, also check the
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
---
xen/arch/arm/vgic-v3-its.c | 30 +++-
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 holding the lock.
Signed-off-by: Andre Przywara
---
x
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 address in the device table, and, if
this command comes fro
vgic_reg64_check_access() checks for a valid access width of a 64-bit
MMIO register, which is useful beyond the current GICv3 emulation only.
Move this function to the vgic-emul.h to be easily reusable.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
xen/arch/arm/vgic-v3.c | 9
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 to let the
GIC emulation deal with this interrupt.
Als
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
confusingly using ID_bits in GITS_TYPER to denote the number o
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 originally written by Vijaya as part of an earlier series:
ht
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 - and copy the
respective entries before using th
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).
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3.c| 6 +-
xen/arch
On Tue, Apr 11, 2017 at 04:04:59PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote:
> > When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
> > notify the guest about the change. This allows for custom udev rules, such
> > as au
On 12/04/17 10:23, Andrew Cooper wrote:
On 11/04/2017 23:13, Glenn Enright wrote:
On 11/04/17 21:49, Dietmar Hahn wrote:
Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
On 11/04/17 17:59, Juergen Gross wrote:
On 11/04/17 07:25, Glenn Enright wrote:
Hi all
We are seeing an odd i
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 PM, hrg wrote:
> >> > >>
On 11/04/2017 23:13, Glenn Enright wrote:
> On 11/04/17 21:49, Dietmar Hahn wrote:
>> Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
>>> On 11/04/17 17:59, Juergen Gross wrote:
On 11/04/17 07:25, Glenn Enright wrote:
> Hi all
>
> We are seeing an odd issue with domu d
This run is configured for baseline tests only.
flight 71173 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71173/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f8c1facf34a1f65082fa22fdbc20a6e0ab8887b4
baseline v
flight 107365 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107365/
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 REGR. vs.
106822
Tests whi
On 11/04/17 21:49, Dietmar Hahn wrote:
Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
On 11/04/17 17:59, Juergen Gross wrote:
On 11/04/17 07:25, Glenn Enright wrote:
Hi all
We are seeing an odd issue with domu domains from xl destroy, under
recent 4.9 kernels a (null) domain is
On Tue, 11 Apr 2017, Bhupinder Thakur wrote:
> Hi,
>
> Kindly let me know if my understanding is correct.
>
> Using a domctl API will allow us to keep the vUART configuration
> flexible. Currently, we can operate on one ring-buf PFN and an event
> channel port only for a single vUART but if we us
flight 107362 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107362/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107325
test-armhf-armhf-libvirt-xsm 13
On Fri, 7 Apr 2017, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Volodymyr Babchuk wrote:
> > >> Native application is an another domain type. It has own vCPU (only one
> > >> at this
> > >> moment) Native app is loaded as any other kernel, using ELF loader.
> > >> It looks like another stub-do
flight 107360 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107360/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 9 debian-install fail REGR. vs. 107219
Regressions which
flight 107358 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107358/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 2 hosts-allocate broken in 107313 pass in 107358
test-armhf-armhf-xl-multivcpu 15 gu
This run is configured for baseline tests only.
flight 71172 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71172/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start
On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote:
> When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
> notify the guest about the change. This allows for custom udev rules, such
> as automatically resizing a filesystem, when an event occurs.
Looks pretty reasonab
When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
notify the guest about the change. This allows for custom udev rules, such
as automatically resizing a filesystem, when an event occurs.
Signed-off-by: Marc Olson
---
drivers/block/xen-blkfront.c | 3 +++
1 file changed, 3
flight 107364 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107364/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f8c1facf34a1f65082fa22fdbc20a6e0ab8887b4
baseline version:
ovmf 1ea946d0f9ea7de963545
We now have macros in place to make it less verbose to add a scalar
to QDict and QList, so use them. To make this patch smaller to
review, a couple of subdirectories were done in earlier patches.
Patch created mechanically via:
spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-fil
flight 107359 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 15 guest-start.2fail REGR. vs. 107247
Regressions which
The patch actually doesn't impact the functionality as such. This only replaces
bool_t with bool in credit2.
Signed-off-by: Praveen Kumar
---
xen/common/sched_credit2.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sche
On Tue, Apr 04, 2017 at 11:59:03AM -0700, Dan Williams wrote:
> >> I don't think KVM has the same issue, but honestly I don't have the
> >> full mental model of how KVM supports mmap. I've at least been able to
> >> run a guest where the "pmem" is just dynamic page cache on the host
> >> side so th
On 04/11/2017 12:12 PM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> We now have macros in place to make it less verbose to add a scalar
>> to QDict and QList, so use them. To make this patch smaller to
>> review, a couple of subdirectories were done in earlier patches.
>>
>> Patch created
On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 15:00:58 +0200
> Daniel Kiper wrote:
>
> > On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > > On 03/04/17 14:42, Daniel Kiper wrote:
> > > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross
Eric Blake writes:
> We now have macros in place to make it less verbose to add a scalar
> to QDict and QList, so use them. To make this patch smaller to
> review, a couple of subdirectories were done in earlier patches.
>
> Patch created mechanically via:
> spatch --sp-file scripts/coccinelle
flight 107296 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107296/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 2 hosts-allocate broken REGR. vs. 1071
On 11/04/17 17:15, Praveen Kumar wrote:
> The patch introduces a new command line option 'cpu' that when used will
> create
> runqueue per logical pCPU. This may be useful for small systems, and also for
> development, performance evalution and comparison.
>
> Signed-off-by: Praveen Kumar
> Revi
Hello,
this is trying to make the point that having NULL pointer entries in the
radix tree and letting Xen handle that is a valid case.
To some degree this serves as a tag (LPI has been unmapped), so should
semantically come close to what we are discussing.
It has the big advantage of being able t
On 11/04/17 16:36, Jan Beulich wrote:
> No matter that we emulate IRET for (guest) real more only right now, we
> should get its effect on (virtual) NMI delivery right.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Adjust x86_emulate_wrapper() accordingly.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b
The patch introduces a new command line option 'cpu' that when used will create
runqueue per logical pCPU. This may be useful for small systems, and also for
development, performance evalution and comparison.
Signed-off-by: Praveen Kumar
Reviewed-by: Dario Faggioli
---
docs/misc/xen-command-li
For kdump to work correctly it needs the physical address of
vmcoreinfo_note. When running as dom0 this means the virtual address
has to be translated to the related machine address.
paddr_vmcoreinfo_note() is meant to do the translation via
__pa_symbol() only, but being attributed "weak" it can b
Hi,
On 06/04/17 01:45, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, 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 tr
>>> On 01.04.17 at 15:53, wrote:
> @@ -94,6 +102,13 @@ struct feat_node {
> unsigned int cos_max;
> unsigned int cbm_len;
>
> +/*
> + * An array to save all 'enum cbm_type' values of the feature. It is
> + * used with cos_num together to get/write a feat
Hi,
On 09/04/17 21:16, Julien Grall wrote:
> Hi Andre,
>
> On 04/07/2017 06:32 PM, 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).
>>
>> Signed-off
>>> 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. */
> -feat->props->get_val(feat, cos, &val[0]);
> +feat->props->get_val(feat, cos, 0, &val[0]);
No matter that we emulate IRET for (guest) real more only right now, we
should get its effect on (virtual) NMI delivery right.
Signed-off-by: Jan Beulich
---
v2: Adjust x86_emulate_wrapper() accordingly.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1955,25 +1955,32 @@ st
>>> On 01.04.17 at 15:53, wrote:
> +static void do_write_psr_msr(void *data)
> +{
> +struct cos_write_info *info = data;
> +unsigned int cos= info->cos;
> +struct feat_node *feat = info->feature;
> +
> +if ( cos > feat->props->cos_max )
> +return;
This che
>>> On 01.04.17 at 15:53, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -800,15 +800,82 @@ static int find_cos(const uint32_t val[], unsigned int
> array_len,
> return -ENOENT;
> }
>
> +static bool fits_cos_max(const uint32_t val[],
> + uint32_t
>>> On 01.04.17 at 15:53, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -720,8 +720,83 @@ static int find_cos(const uint32_t val[], unsigned int
> array_len,
> const struct psr_socket_info *info,
> spinlock_t *ref_lock)
> {
> +uns
>>> On 01.04.17 at 15:53, wrote:
> @@ -593,7 +616,21 @@ int psr_get_val(struct domain *d, unsigned int socket,
> /* Set value functions */
> static unsigned int get_cos_num(const struct psr_socket_info *info)
> {
> -return 0;
> +unsigned int num = 0, i;
> +
> +/* Get all features to
>>> On 01.04.17 at 15:53, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -157,10 +157,26 @@ static void free_socket_resources(unsigned int socket)
> {
> unsigned int i;
> struct psr_socket_info *info = socket_info + socket;
> +struct domain *d;
>
> if ( !in
On Tue, 11 Apr 2017 15:00:58 +0200
Daniel Kiper wrote:
> On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > On 03/04/17 14:42, Daniel Kiper wrote:
> > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> > >> For kdump to work correctly it needs the physical address
On 11/04/17 16:42, Raslan, KarimAllah wrote:
>
>> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky
>> wrote:
>>
>>
>>
I think the right thing is indeed to revert 72a9b186292 (and
therefore da72ff5bfcb02). Any objections?
>>>
>>> For the end result: depends. Is there a real error or n
> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky
> wrote:
>
>
>
>>>
>>> I think the right thing is indeed to revert 72a9b186292 (and
>>> therefore da72ff5bfcb02). Any objections?
>>
>> For the end result: depends. Is there a real error or not?
>> KarimAllah wrote that his concerns are of a t
Hi,
Kindly let me know if my understanding is correct.
Using a domctl API will allow us to keep the vUART configuration
flexible. Currently, we can operate on one ring-buf PFN and an event
channel port only for a single vUART but if we use DOMCTL interface,
then we can effectively get/set multipl
> On Apr 11, 2017, at 10:57 AM, Juergen Gross wrote:
>
> On 10/04/17 17:32, Raslan, KarimAllah wrote:
>>
>> Ahmed, Karim Allah
>> karah...@amazon.de
>>
>>
>>
>>> On Apr 10, 2017, at 3:57 PM, Juergen Gross wrote:
>>>
>>> On 10/04/17 15:47, Boris Ostrovsky wrote:
On 04/07/2017 06:11 PM,
I think the right thing is indeed to revert 72a9b186292 (and
therefore da72ff5bfcb02). Any objections?
For the end result: depends. Is there a real error or not?
KarimAllah wrote that his concerns are of a theoretical nature as
xen_strict_xenbus_quirk() would mask the problem. OTOH he tells
On 11/04/17 15:22, Boris Ostrovsky wrote:
>
>
> On 04/11/2017 05:53 AM, Andrew Cooper wrote:
>> On 10/04/17 19:48, Boris Ostrovsky wrote:
> The following is meant as a real question without any
> prejudice:
>
> How old a Xen version do we want to support in the Linux
> kernel
On Mon, 2017-04-10 at 14:50 -0700, Candida Haynes wrote:
> Hi,
>
> I apologize to anyone who receives this twice - I received an
> error/bounce message. I am writing because I am interested in
> applying to Outreachy and contributing to the Xen Code Review
> Dashboard. My most formal experience wi
flight 71171 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs.
71146
On 04/11/2017 05:53 AM, Andrew Cooper wrote:
On 10/04/17 19:48, Boris Ostrovsky wrote:
The following is meant as a real question without any prejudice:
How old a Xen version do we want to support in the Linux kernel?
- Only those being still maintained (meaning getting security fixes)
Defin
flight 107357 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107357/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-localmigrate/x10 fail REGR. vs. 107259
Regressions whi
Hi Wei,
On 11/04/17 12:03, Wei Liu wrote:
No quote is required when a string is provided as part of a spec string.
Reported-by: Doug Freed
Signed-off-by: Wei Liu
Documentation will always improve the release :). Unless there is a
commit moratorium, consider that release-ack is not necessar
On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> On 03/04/17 14:42, Daniel Kiper wrote:
> > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> >> For kdump to work correctly it needs the physical address of
> >> vmcoreinfo_note. When running as dom0 this means the virt
On 03/04/17 14:42, Daniel Kiper wrote:
> On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
>> For kdump to work correctly it needs the physical address of
>> vmcoreinfo_note. When running as dom0 this means the virtual address
>> has to be translated to the related machine address.
>>
On Tue, Apr 11, 2017 at 06:31:36AM -0600, Jan Beulich wrote:
> >>> On 11.04.17 at 13:24, wrote:
> > On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
> >> >>> On 10.04.17 at 21:44, wrote:
> >> wouldn't it be better to handle this with a static state variable,
> >> which gets checked/se
1 - 100 of 150 matches
Mail list logo
