Hi Julien,
On 2017/3/15 19:01, Julien Grall wrote:
> On 15/03/17 07:19, Wei Chen wrote:
>> Hi Stefano,
>
> Hello,
>
>> On 2017/3/15 8:24, Stefano Stabellini wrote:
>>> On Mon, 13 Mar 2017, Wei Chen wrote:
We want to add HCR_EL2 register to Xen context switch. And each copy
of HCR_EL2 in
Hi Julien,
On 2017/3/15 19:12, Julien Grall wrote:
> Hi Wei,
>
> On 15/03/17 08:34, Wei Chen wrote:
>> On 2017/3/15 8:25, Stefano Stabellini wrote:
>>> On Mon, 13 Mar 2017, Wei Chen wrote:
Different domains may have different HCR_EL2 flags. For example, the
64-bit domain needs HCR_RW fla
* Jiri Slaby wrote:
> SYM_LOCAL_ALIAS_START -- use where there are two local names for one code
> SYM_ALIAS_START -- use where there are two global names for one code
> SYM_LOCAL_FUNC_START -- use for local functions
> SYM_FUNCTION_START -- use for global functions
> SYM_WEAK_FUNC_START -- use f
* Thomas Garnier wrote:
> This patch aligns MODULES_END to the beginning of the Fixmap section.
> It optimizes the space available for both sections. The address is
> pre-computed based on the number of pages required by the Fixmap
> section.
>
> It will allow GDT remapping in the Fixmap sectio
On Wed, Mar 15, Jan Beulich wrote:
> ..., and iirc PV migration didn't have any issue with TSC freq
> changing during migration prior to the introduction of vTSC.
When was this introduced? There is a claim that this slowdown is a
regression.
Olaf
signature.asc
Description: PGP signature
__
On 03/16/2017, 09:02 AM, Ingo Molnar wrote:
>
> * Jiri Slaby wrote:
>
>> SYM_LOCAL_ALIAS_START -- use where there are two local names for one code
>> SYM_ALIAS_START -- use where there are two global names for one code
>> SYM_LOCAL_FUNC_START -- use for local functions
>> SYM_FUNCTION_START -- u
On 03/16/2017 06:50 AM, Bhupinder Thakur wrote:
Hi,
Hi Bhupinder,
On 5 March 2017 at 13:51, Julien Grall wrote:
Hi Bhupinder,
Commit title: s/atleat/at least/
On 02/21/2017 11:26 AM, Bhupinder Thakur wrote:
Ensure that nr_spis intialized in in vgic_init is atleast 1 to allow
allocation
flight 106698 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs.
106652
Regression
On Tue, 14 Mar 2017 09:15:04 -0400
Boris Ostrovsky wrote:
>
>
> On 03/14/2017 08:50 AM, Razvan Cojocaru wrote:
> > On 03/14/2017 02:15 PM, Vlad-Ioan TOPAN wrote:
> @@ -2642,6 +2660,38 @@ void svm_vmexit_handler(struct cpu_user_regs
> *regs)
> case VMEXIT_PAUSE:
>
Hi Sreya,
I had missed this mail as I wasn't CC'ed
> On 5 Mar 2017, at 11:34, Sreya Mittal wrote:
>
> Hi,
> I am Sreya Mittal pursuing my Btech in Computer Science at International
> Institute of Information Technology, Hyderabad.
>
> I am interested in open-source contributions and looking f
We have provided an option to administrator to determine how to
handle the SErrors. In order to avoid add overhead to check the
option at every trap, we want to use the alternative to skip
this check.
In this series:
1. Introduce alternative patching support for ARM32.
2. Update the ARM32 SErrors
This patch is based on the implementation of ARM64, it introduces
alternative runtime patching to ARM32. This allows to patch assembly
instruction at runtime to either fix hardware bugs or optimize for
certain hardware features on ARM32 platform.
Xen hypervisor is using ARM execution state only on
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.
The ARM3
On 15/03/17 16:00, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
> ---
> Cc: George Dunlap
> Cc: Jan Beulich
> ---
> Changes from v1:
> * improved subject line.
> ---
> xen/common/sched_credit2.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/xe
>>> On 16.03.17 at 09:13, wrote:
> On Wed, Mar 15, Jan Beulich wrote:
>
>> ..., and iirc PV migration didn't have any issue with TSC freq
>> changing during migration prior to the introduction of vTSC.
>
> When was this introduced? There is a claim that this slowdown is a
> regression.
Many, ma
>>> On 15.03.17 at 22:21, wrote:
> On Wed, Mar 15, 2017 at 10:41:13AM -0600, Jan Beulich wrote:
> On 15.03.17 at 06:11, wrote:
>>> --- a/xen/drivers/passthrough/vtd/intremap.c
>>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>>> @@ -552,11 +552,12 @@ static int msi_msg_to_remap_entry(
>>>
>>> On 15.03.17 at 23:39, wrote:
> On Wed, Mar 15, 2017 at 10:48:25AM -0600, Jan Beulich wrote:
> On 15.03.17 at 06:11, wrote:
>>> +/*
>>> + * The following method to update IRTE is safe on condition that
>>> + * only the high qword or the low qword is to be updated.
>
On 16 March 2017 at 13:54, Julien Grall wrote:
>>
>> The other option is to reserve a SPI for pl011 at compile time and use
>> that value. Let me know.
>
>
> Whilst I am ok to have the pl011 SPI number hardcoded, I don't like the
> approach taken in this patch because the toolstack is in charge of
>>> On 15.03.17 at 20:48, wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -2051,17 +2051,11 @@ void tsc_set_info(struct domain *d,
> d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
> d->arch.tsc_khz = gtsc_khz ?: cpu_khz;
> set_time_scale(&d->arch.
There is an interface in user space to show feature value of
domains.
This patch implements get value flow in hypervisor including
L3 CAT callback function.
It also changes domctl interface to make it more general.
With this patch, 'psr-cat-show' can work for L3 CAT but not for
L3 code/data whic
Hi all,
We plan to bring a new PSR (Platform Shared Resource) feature called
Intel L2 Cache Allocation Technology (L2 CAT) to Xen. It has been enabled
in Linux Kernel.
Besides the L2 CAT implementaion, we refactor the psr.c to make it more
flexible and easily to extend to add new features. We abs
This patch moves 'cpuid_count_leaf' from cpuid.c to processor.h to
make it available to external codes.
Signed-off-by: Yi Sun
---
v9:
- create this patch alone to move 'cpuid_count_leaf'.
(suggested by Wei Liu)
v6:
- use 'struct cpuid_leaf' in psr.c. So we have to access 'cpuid_coun
To construct an extendible framework, we need analyze PSR features
and abstract the common things and feature specific things. Then,
encapsulate them into different data structures.
By analyzing PSR features, we can get below map.
+--+--+--+
->| Dom0 | Dom
As set value flow is the most complicated one in psr, it will be
divided to some patches to make things clearer. This patch
implements the set value framework to show a whole picture firstly.
It also changes domctl interface to make it more general.
To make the set value flow be general and can s
This patch implements get HW info flow including L3 CAT callback
function.
It also changes sysctl interface to make it more general.
With this patch, 'psr-hwinfo' can work for L3 CAT.
Signed-off-by: Yi Sun
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Wei Liu
---
v9:
- replace feature l
Continue from previous patch:
'x86: refactor psr: L3 CAT: set value: implement cos finding flow.'
If fail to find a COS ID, we need pick a new COS ID for domain. Only COS ID
that ref[COS_ID] is 1 or 0 can be picked to input a new set feature values.
Signed-off-by: Yi Sun
---
v9:
- modify ret
This patch implements the CPU init and free flow including L3 CAT
initialization and feature array free. It includes below flows:
1. presmp init:
- parse command line parameter.
- allocate socket info for every socket.
- allocate feature resource.
- initialize socket info, get featu
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 affected. So, we firstly need gather an array which
Continue from previous patch:
'x86: refactor psr: L3 CAT: set value: implement cos id picking flow.'
We have got the feature value and COS ID to set. Then, we write MSR of the
designated feature.
Till now, set value process is completed.
Signed-off-by: Yi Sun
---
v9:
- replace feature list
This patch creates CAT and CDP feature document in doc/features/. It describes
key points to implement L3 CAT/CDP and L2 CAT which is described in details in
Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION
FEATURES".
Signed-off-by: Yi Sun
Reviewed-by: Konrad Rzeszutek Wilk
This patch implements the Domain init/free and schedule flows.
- When domain init, its psr resource should be allocated.
- When domain free, its psr resource should be freed too.
- When domain is scheduled, its COS ID on the socket should be
set into ASSOC register to make corresponding COS MSR v
This patch implements get HW info flow for CDP including L3 CDP callback
function. The flow is almost same as L3 CAT.
It also changes sysctl function to make it work for CDP.
With this patch, 'psr-hwinfo' can work for L3 CDP.
Signed-off-by: Yi Sun
---
v9:
- modify commit message to explain
The current cache allocation codes in psr.c do not consider
future features addition and are not friendly to extend.
To make psr.c be more flexible to add new features and fulfill
the program principle, open for extension but closed for
modification, we have to refactor the psr.c:
1. Analyze cache
Continue from patch:
'x86: refactor psr: L3 CAT: set value: assemble features value array'
We can try to find if there is a COS ID on which all features' COS registers
values are same as the array assembled before.
Signed-off-by: Yi Sun
---
v9:
- modify comments of 'compare_val' to be same a
This patch implements L2 CAT set value related callback functions
and domctl interface.
Signed-off-by: Yi Sun
---
v9:
- reuse some CAT common functions for L2 CAT to reduce redundant codes.
(suggested by Roger Pau)
- remove parameter 'found' from 'cat_compare_val' and modify the ret
This patch implements the CPU init and free flow for L2 CAT including
L2 CAT initialization callback function.
Signed-off-by: Yi Sun
---
v9:
- modify error handling process in 'psr_cpu_prepare' to reduce redundant
codes.
- reuse 'cat_init_feature' and 'cat_get_cos_max' for L2 CAT to
This patch implements L2 CAT get value callback function and
interface in domctl.
Signed-off-by: Yi Sun
---
v9:
- reuse 'cat_get_val' for L2 CAT to reduce redundant codes
(suggested by Roger Pau)
- changes about 'uint64_t' to 'uint32_t'.
(suggested by Jan Beulich)
v5:
- re
This patch implements L3 CDP set value related callback functions.
With this patch, 'psr-cat-cbm-set' command can work for L3 CDP.
Signed-off-by: Yi Sun
---
v9:
- add comment to explain why CDP uses 2 COSs.
(suggested by Wei Liu)
- use 'cat_default_val'.
(suggested by Wei Liu
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 Allocation Technology (CAT): L2
Socket ID : 0
M
This patch implements get HW info flow for L2 CAT including L2 CAT callback
function.
Signed-off-by: Yi Sun
---
v9:
- reuse 'cat_get_feat_info' for L2 CAT to reduce redundant codes.
(suggested by Roger Pau)
- modify sysctl implementation of L2 CAT to input data[3] to use
'cat_
This patch implements changes in xl/xc changes to support
showing CBM of L2 CAT.
The new level option is introduced to original CAT showing
command in order to show CBM for specified level CAT.
- 'xl psr-cat-show' is updated to show CBM of a domain
according to input cache level.
Examples:
root
This patch implements L3 CDP get value callback function.
With this patch, 'psr-cat-show' can work for L3 CDP.
Signed-off-by: Yi Sun
---
v9:
- modify the type of 'l3_cdp_get_val' to 'void'.
- cos checking has been done in common function so remove related codes
in CDP callback func
This patch adds L2 CAT description in related documents.
Signed-off-by: He Chen
Signed-off-by: Yi Sun
Acked-by: Wei Liu
---
docs/man/xl.pod.1.in | 25 ++---
docs/misc/xl-psr.markdown | 18 --
2 files changed, 34 insertions(+), 9 deletions(-)
diff --git
This patch implements the xl/xc changes to support set CBM
for L2 CAT.
The new level option is introduced to original CAT setting
command in order to set CBM for specified level CAT.
- 'xl psr-cat-set' is updated to set cache capacity bitmasks(CBM)
for a domain according to input cache level.
r
This patch implements the CPU init and free flow for CDP including L3 CDP
initialization callback function. The flow is almost same as L3 CAT.
Signed-off-by: Yi Sun
---
v9:
- modify commit message to describe flow clearer.
- handle cpu offline and online again case to read MSRs registers
>>> On 16.03.17 at 10:03, wrote:
> flight 106698 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106698/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-qemuu-nested-intel 16 debian-h
The ARM GICv3 provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate the required memory, initialize it and hand it over to each
r
Parse the DT GIC subnodes to find every ITS MSI controller the hardware
offers. Store that information in a list to both propagate all of them
later to Dom0, but also to be able to iterate over all ITSes.
This introduces an ITS Kconfig option.
Signed-off-by: Andre Przywara
---
xen/arch/arm/Kconf
The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID.
We store the given guest physical address in the device table, and, if
this command comes from Dom0, tell the host ITS driver about this new
mapping, so it can issue the corresponing host MAPD c
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
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
---
Create a new file to hold the emulation code for the ITS widget.
For now we 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-by: Andre Przywara
---
xen/arch/arm/Makefi
Hi,
a revised version of the series to emulate an ARM GICv3 ITS interrupt
controller, for Dom0 only at the moment.
The ITS is an interrupt controller widget providing a sophisticated way
of dealing with MSIs in a scalable manner. For more explanations, see
below.
Some remarks on this version:
- I
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 35 +--
1 file changed, 33
For some reason (probably because there was no user before) the 64-bit
atomic access wrappers were commented out so far.
As we will need them in the next patch, active (and fix) them now.
Signed-off-by: Andre Przywara
---
xen/include/asm-arm/atomic.h | 6 +++---
1 file changed, 3 insertions(+),
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. However we actually only need those when an
interrupt is on a vCPU (or is about to be injected).
Maintain a list of those structs that we can
Upon receiving an LPI, 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.
Signed-off-by:
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush the command queue (SYNC).
Start using these commands fo
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 scan
the pending table and inject _every_ LPI found there that got enabled.
Signed-off-by: An
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.
Since the final interrupt translation tables can be smaller than a page,
we map them on demand (which is
The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs, as every LPI will be injected
into a guest (Dom0 for n
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 IRQ on the host can be quickly forwarded to a guest.
Signed-off-by: Andre Przywara
---
xen/arc
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 | 30 ++
1 file changed, 30 insert
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
---
xen/arch/arm/gic-v3-its.c | 4
xen/a
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 | 23 +++
1 file changed, 23 insertions(+)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/a
Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer in normal system memory to the ITS h/w
to create or alter the LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be able
to send ITS commands.
Signed-off-by: Andre Przywara
Each ITS maps a pair of a DeviceID (for instance derived from a PCI
b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
pair of LPI number and collection ID, which points to the target CPU.
This mapping is stored in the device and collection tables, which software
has to provide fo
If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but have to save the pending state on the
virtual side.
Signed-of
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 and map those pages into Xen's address space to have easy
access.
Signed-off-by: Andre Przywara
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 | 33
The ITS uses device IDs to map LPIs to a device. Dom0 will later use
those IDs, which we directly pass on to the host.
For this we have to map each device that Dom0 may request to a host
ITS device with the same identifier.
Allocate the respective memory and enter each device into an rbtree to
late
For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 29 +
xen/arch/arm/vgic-v3.c | 12
xen/i
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3.c | 88
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
>>> On 16.03.17 at 12:07, wrote:
> Acked and Reviewed list before V9:
>
> a - Acked-by
> r - Reviewed-by
>
> r patch 1 - docs: create Cache Allocation Technology (CAT) and Code and
> Data Prioritization (CDP) feature document
> ar patch 2 - x86: refactor psr: remove L3 CAT
flight 106707 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106707/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106678
test-armhf-armhf-libvirt 13
Hello,
This patch series removes the PVHv1 code, both from the hypervisor and the
tools, and also gets rid of the has_hvm_container_{domain/vcpu} macro, since
from Xen's point of view there are only two types of guests: PV or HVM.
Last patch is a minor code movement to have all the domain build P
Hello,
This patch series removes the PVHv1 code, both from the hypervisor and the
tools, and also gets rid of the has_hvm_container_{domain/vcpu} macro, since
from Xen's point of view there are only two types of guests: PV or HVM.
Last patch is a minor code movement to have all the domain build P
From: Ian Jackson
This patch adds support for union members which have their own type name.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Acked-by: David Scott
---
This is no longer a pre-requisite for the PVHv1 removal patch, but it's
probably still nice to have it.
---
Cc: David Scott
Cc
This removal applies to both the hypervisor and the toolstack side of PVHv1.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: George Dunlap
Reviewed-by: Paul Durrant
Acked-by: Elena Ufimtseva
Reviewed-by: Kevin Tian
---
Changes since v3:
- Remove pvh option from xl/libxl.
This function is only used by PVHv2 domain build, so move it together with the
other PVH domain build functions.
Just code motion, no functional change.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/domain_build.c | 134 ++
It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's
point of view.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Tim Deegan
Reviewed-by: Kevin Tian
Reviewed-by: Boris Ostrovsky
Acked-by: George Dunlap
Acked-by: Elena Ufimtseva
---
Cc: Christop
flight 106699 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106699/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On Wed, Mar 15, 2017 at 09:27:27AM -0500, Doug Goldstein wrote:
> On 3/15/17 6:35 AM, Daniel Kiper wrote:
> > On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
> >
> > [...]
> >
> >> Still missing 'xl info'.
> >
> > Got Intel NUC5i3MYHE (internally it is NUC5i3MYBE board) into my hand
flight 106700 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106700/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
test-amd64-i386-xl-qemuu-
On Wed, Mar 15, 2017 at 04:01:19PM +, Igor Druzhinin wrote:
> Saving/restoring the physmap to/from xenstore was introduced to
> QEMU majorly in order to cover up the VRAM region restore issue.
> The sequence of restore operations implies that we should know
> the effective guest VRAM address *b
xc_altp2m_set_mem_access() and xc_set_mem_access() end up doing the same thing
in the hypervisor, but the former is a HVMOP and the latter a DOMCTL. Since
nobody is currently using, or has stated intent to use, this functionality
specifically as an HVMOP, this patch removes the HVMOP while adding a
On 03/16/2017 06:40 AM, Jan Beulich wrote:
On 15.03.17 at 20:48, wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -2051,17 +2051,11 @@ void tsc_set_info(struct domain *d,
>> d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
>> d->arch.tsc_khz = gtsc_kh
On 16/03/17 12:26, Anthony PERARD wrote:
> On Wed, Mar 15, 2017 at 04:01:19PM +, Igor Druzhinin wrote:
>> Saving/restoring the physmap to/from xenstore was introduced to
>> QEMU majorly in order to cover up the VRAM region restore issue.
>> The sequence of restore operations implies that we sho
Stop creating an excessively large array on the stack, by properly
taking into account the array element size when establishing its
element count (and of course also when calculating the pointer to
be actually used to access the memory).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/
>>> On 16.03.17 at 13:12, wrote:
> Everything works. I am not able to reproduce any issues reported by Doug.
> Andrew, Jan, Doug, are there still any objections to commit the rest of v16?
Well, Andrew has been telling me privately that even the part that
was already committed regresses XenServer
On 16/03/17 13:05, Jan Beulich wrote:
> Stop creating an excessively large array on the stack, by properly
> taking into account the array element size when establishing its
> element count (and of course also when calculating the pointer to
> be actually used to access the memory).
What in practi
flight 106702 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106702/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106574
test-amd64-amd64-xl-qemuu-
>>> On 16.03.17 at 13:44, wrote:
> On 03/16/2017 06:40 AM, Jan Beulich wrote:
> On 15.03.17 at 20:48, wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -2051,17 +2051,11 @@ void tsc_set_info(struct domain *d,
>>> d->arch.vtsc_offset = get_s_time() - elapsed_ns
>>> On 16.03.17 at 14:09, wrote:
> On 16/03/17 13:05, Jan Beulich wrote:
>> Stop creating an excessively large array on the stack, by properly
>> taking into account the array element size when establishing its
>> element count (and of course also when calculating the pointer to
>> be actually use
On Thu, Mar 16, 2017 at 07:12:21AM -0600, Jan Beulich wrote:
> >>> On 16.03.17 at 13:12, wrote:
> > Everything works. I am not able to reproduce any issues reported by Doug.
> > Andrew, Jan, Doug, are there still any objections to commit the rest of v16?
>
> Well, Andrew has been telling me privat
>>> On 16.03.17 at 14:35, wrote:
> On Thu, Mar 16, 2017 at 07:12:21AM -0600, Jan Beulich wrote:
>> >>> On 16.03.17 at 13:12, wrote:
>> > Everything works. I am not able to reproduce any issues reported by Doug.
>> > Andrew, Jan, Doug, are there still any objections to commit the rest of
> v16?
>
On 16/03/17 13:31, Jan Beulich wrote:
On 16.03.17 at 14:09, wrote:
>> On 16/03/17 13:05, Jan Beulich wrote:
>>> Stop creating an excessively large array on the stack, by properly
>>> taking into account the array element size when establishing its
>>> element count (and of course also when ca
Hello,
I try to pass-through a device with 8G large bar, such as nvidia M60(note1,
pci-e info as below). It takes about '__15 sconds__' to update 8G large bar in
QEMU::xen_pt_region_update()..
Specifically, it is xc_domain_memory_mapping() in xen_pt_region_update().
Digged into xc_domain_memory
>>> On 16.03.17 at 14:55, wrote:
> I try to pass-through a device with 8G large bar, such as nvidia M60(note1,
> pci-e info as below). It takes about '__15 sconds__' to update 8G large bar
> in
> QEMU::xen_pt_region_update()..
> Specifically, it is xc_domain_memory_mapping() in xen_pt_region_up
1 - 100 of 241 matches
Mail list logo
