On Thu, Feb 19, 2015 at 01:06:53PM +, David Vrabel wrote:
> Mel,
>
> The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not
> dereference pmd outside of the lock during NUMA hinting fault) and
> specifically 8a0516ed8b90 (mm: convert p[te|md]_numa users to
> p[te|md]_protnone_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2015 01:58 PM, Lars Kurth wrote:
> Adding the xen-devel list. Note that we are a long time
> participant of GSoC and OPW. Our project list is on
> wiki.xenproject.org/wiki/GSoC_2015
Do you have anything that you would want to do in joint or
flight 34696 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34696/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-amd 6 leak-check/basis(6) running in 34247
[st=running!]
test-a
I'm trying to use the memevent channel to extract the permission for a
particular text section. I expect to see rx as the permission, instead
I am seeing rwx. I have not spent a whole lot of time looking at
memaccess[] and p2m-ept.c, but I am puzzled. The OS definitely has
this text segment marked
On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
wrote:
>
> I'm feeling I miss very basic background on how Xen works, but why does it
> set _PAGE_GLOBAL on userspace entries? It sounds strange to me.
It is definitely strange. I'm guessing that it's some ancient Xen hack
for the early Intel vi
flight 34713 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34713/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
build-amd64-rumpuserx
> Do you have anything that you would want to do in joint or through
> CentOS GSoC efforts?
We probably do, but don't have time to put this together in there next 24
hours. A bit of thought and word smithing is needed. There is nothing on
our existing list that can be moved over.
Is there any inf
On Fri, Dec 12, 2014 at 9:29 AM, David Vrabel wrote:
> On 12/12/14 13:17, Juergen Gross wrote:
>> XEN_PVHVM
>
> Move XEN_PVHVM under XEN and have it select PARAVIRT and PARAVIRT_CLOCK.
FWIW, although it seems we do not want to let users just build
XEN_PVHVM hypervisors I have the changes required
flight 34690 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 5 xen-boot fail REGR. vs. 34227
test-amd64-i386-qemuu
On Thu, Feb 19, 2015 at 5:06 AM, David Vrabel wrote:
>
> The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not
> dereference pmd outside of the lock during NUMA hinting fault) and
> specifically 8a0516ed8b90 (mm: convert p[te|md]_numa users to
> p[te|md]_protnone_numa) breaks Xen
Adding the xen-devel list. Note that we are a long time participant of GSoC and
OPW. Our project list is on wiki.xenproject.org/wiki/GSoC_2015
We are both at CollabSummit, which is why we have not responded to KB's mail
Lars
From: Karsten Wade [kw...@redh
On 19/02/2015 17:56, Andrew Cooper wrote:
[1] along with a todo note suggesting that opening evtchn for each
domain is inefficient.
The evtchn device has per-fd locks so using only a single fd for all
events may scale badly.
David
___
Xen-devel
On Thu, Feb 12, 2015 at 07:19:12PM +0800, Ard Biesheuvel wrote:
> Prepare for making XenBusDxe suitable for use with non-PCI devices
> (such as the DT node exposed by Xen on ARM) by introducing a separate
> DXE driver that binds to the Xen virtual PCI device and exposes the
> abstract XENIO_PROTOCO
Hi Ian,
On 19/02/15 17:39, Ian Campbell wrote:
> ... and make it tunable via the command line.
>
> 1/8 of RAM is 128M on a 1GB system and 256M on a 2GB system etc,
> which is a lot. 1/32 of RAM seems more reasonable. Also drop the
> minimum to 32M.
>
> Leave the maximum at 1GB.
>
> Signed-off-b
On 19/02/15 17:01, Ian Campbell wrote:
> On Thu, 2015-02-19 at 16:58 +, Andrew Cooper wrote:
>> On 19/02/15 16:39, Ian Campbell wrote:
>>> On Thu, 2015-02-19 at 11:45 +, Andrew Cooper wrote:
>>>
+while ( iov_idx < iovcnt )
+{
+/* Skip over iov[] entries with 0
While it's easy to know which hardware IRQ is assigned to a domain, there
is no way to know which vIRQ is allocated by Xen for a specific domain.
Introduce a bitmap to keep track of every vIRQ used by a domain. This
will be used later to find free vIRQ for interrupt device assignment and
emulated
Use the new vgic interface to know which virtual PPI is free and use it
for the event channel code.
At the DOM0 creation time, Xen doesn't know which vIRQ will be free.
All the vIRQ will be reserved when we parse the device tree. So we can
allocate the vIRQ just after the device tree has been pars
On 18/02/2015 06:51, Juergen Gross wrote:
xen_set_identity_and_remap() is used to prepare remapping of memory
conflicting with the E820 map. It is tracking the pfn where to remap
new memory via a local variable which is passed to a subfunction
which in turn returns the new value for that variab
Hello,
This patch series replaces the per-platform hardcoded event channel interrupt
to a generic solution. It will make the port to a new platform easier and may
avoid to introduce per-platform code with the new upcoming ACPI support.
This could be done by keeping track of vIRQ (emulated and ass
On 18/02/2015 06:51, Juergen Gross wrote:
Currently especially for dom0 guest memory with guest pfns not
matching host areas populated with RAM are remapped to areas which
are RAM native as well. This is done to be able to use identity
mappings (pfn == mfn) for I/O areas.
Up to now it is not che
On 19/02/15 17:48, Ian Campbell wrote:
> On Thu, 2015-02-19 at 17:34 +, Julien Grall wrote:
>> On 19/02/15 17:21, Ian Campbell wrote:
>>> On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
>>>
>>> All applied, thanks.
>>>
Most of this patches should be backported to Xen 4.5/Xen 4.5 (se
On 19/02/15 16:30, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v3] tools/xenconsoled: Increase file descriptor
> limit"):
>> On Tue, Feb 17, 2015 at 05:55:52PM +, Andrew Cooper wrote:
>>> XenServer's VM density testing uncovered a regression when moving from
>>> sysvinit to systemd where
On 18/02/2015 11:51, Juergen Gross wrote:
On 02/18/2015 12:18 PM, David Vrabel wrote:
On 18/02/15 06:52, Juergen Gross wrote:
+if X86_64
+choice
+prompt "Support pv-domains larger than 512GB"
+default XEN_512GB_NONE
+help
+ Support paravirtualized domains with more than 512GB
On Thu, 2015-02-19 at 17:34 +, Julien Grall wrote:
> On 19/02/15 17:21, Ian Campbell wrote:
> > On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
> >
> > All applied, thanks.
> >
> >> Most of this patches should be backported to Xen 4.5/Xen 4.5 (see each
> >> patch).
> >> Although, the
On 18/02/2015 06:52, Juergen Gross wrote:
With adapting the memory layout of dom0 to that of the host care must
be taken not to remap the initial p2m list supported by the hypervisor.
"...supplied by the hypervisor" ?
If the p2m map is detected to be in a region which is going to be
remapped,
On Thu, Feb 12, 2015 at 07:19:10PM +0800, Ard Biesheuvel wrote:
> This moves all of the Xen hypercall code that was private to XenBusDxe
> to a new library class XenHypercallLib. This will allow us to reimplement
> it for ARM, and to export the Xen hypercall functionality to other parts
> of the co
On 18/02/2015 06:52, Juergen Gross wrote:
When adapting the dom0 memory layout to that of the host make sure
the initrd isn't moved to another pfn range, as it won't be found
there any more.
The easiest way to accomplish that is by copying the initrd to an
area which is RAM according to the E8
... and make it tunable via the command line.
1/8 of RAM is 128M on a 1GB system and 256M on a 2GB system etc,
which is a lot. 1/32 of RAM seems more reasonable. Also drop the
minimum to 32M.
Leave the maximum at 1GB.
Signed-off-by: Ian Campbell
Cc: Jintack Lim
Cc: Jan Beulich
---
v3:
- Clar
On 18/02/2015 06:52, Juergen Gross wrote:
Checks whether the pre-allocated memory of the loaded kernel is in
conflict with the target memory map. If this is the case, just panic
instead of run into problems later.
What ensures this doesn't actually happen?
David
__
On 18/02/2015 06:52, Juergen Gross wrote:
In case a pre-allocated memory area is to be moved in order to avoid
a conflict with the target E820 map we need a way to copy data between
physical addresses.
Add a function doing this via early_memremap().
[...]
--- a/arch/x86/xen/setup.c
+++ b/arch/
On 19/02/15 17:21, Ian Campbell wrote:
> On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
>
> All applied, thanks.
>
>> Most of this patches should be backported to Xen 4.5/Xen 4.5 (see each
>> patch).
>> Although, the one in GICv2 are not critical.
>
> Do you have a handy index of which
On Fri, 2015-02-06 at 15:18 +, Stefano Stabellini wrote:
> On Fri, 6 Feb 2015, Wei Liu wrote:
> > Albeit INVALID_P2M_ENTRY and INVALID_MFN are both ~0UL, conceptually
> > speaking we should use INVALID_P2M_ENTRY for setting P2M values.
> >
> > Signed-off-by: Wei Liu
> > Cc: Ian Campbell
> >
On 18/02/2015 06:52, Juergen Gross wrote:
Check whether the page tables built by the domain builder are at
memory addresses which are in conflict with the target memory map.
If this is the case just panic instead of running into problems
later.
Again, what ensures this never actually happens?
On Thu, 2015-02-19 at 09:49 +, Wei Liu wrote:
> On Thu, Feb 19, 2015 at 08:43:05AM +, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell
>
> Acked-by: Wei Liu
Thanks, applied.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists
On Wed, 2015-02-11 at 16:00 +0100, Olaf Hering wrote:
> Avoid late build failure in openSUSE 11.4, it has just pixman-0.20:
>
>
> [ 211s] ERROR: pixman >= 0.21.8 not present. Your options:
> [ 211s] (1) Preferred: Install the pixman devel package (any recent
> [ 211s]
On Thu, 2015-02-19 at 10:22 +, Ian Campbell wrote:
> > >>> +printk("Bad mode in %s handler detected", handler[reason]);
> > >>> +printk("ESR=0x%08"PRIx32": EC=%"PRIx32", IL=%"PRIx32",
> > >>> ISS=%"PRIx32"\n",
> > >>> + hsr.bits, hsr.ec, hsr.len, hsr.iss);
> > >> This would
On 18/02/2015 06:52, Juergen Gross wrote:
For being able to relocate pre-allocated data areas like initrd or
p2m list it is mandatory to find a contiguous memory area which is
not yet in use and doesn't conflict with the memory map we want to
be in effect.
In case such an area is found reserve i
On Thu, Feb 12, 2015 at 07:19:11PM +0800, Ard Biesheuvel wrote:
> This introduces the abstract XENIO_PROTOCOL that will be used to
> communicate the Xen grant table address to drivers supporting this
> protocol. Primary purpose is allowing us to change the XenBusDxe
> implementation so that it can
On 18/02/2015 06:51, Juergen Gross wrote:
Instead of using a function local static e820 map in xen_memory_setup()
and calling various functions in the same source with the map as a
parameter use a map directly accessible by all functions in the source.
Reviewed-by: David Vrabel
David
___
On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
All applied, thanks.
> Most of this patches should be backported to Xen 4.5/Xen 4.5 (see each patch).
> Although, the one in GICv2 are not critical.
Do you have a handy index of which ones do/don't need backporting to
save me trawling throug
On Sun, 2015-02-08 at 18:55 +, Dave Scott wrote:
>
> > On 8 Feb 2015, at 17:11, M A Young wrote:
> >
> > From 73bab9cb1cb95f35080fadaf1193cbe45327a89c Mon Sep 17 00:00:00 2001
> > From: Michael Young
> > Date: Sun, 8 Feb 2015 15:54:23 +
> > Subject: [PATCH] tools/ocaml: remove uint32 us
On 19/02/15 17:15, Ian Campbell wrote:
> On Wed, 2015-02-18 at 17:36 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 02/02/2015 15:09, Ian Campbell wrote:
>>> On Thu, 2015-01-29 at 15:51 +, Julien Grall wrote:
- Move the retry after looking for first/end. I keep the goto
On Thu, 2015-02-19 at 16:44 +, Ian Campbell wrote:
> On Thu, 2015-02-19 at 12:43 +, Andrew Cooper wrote:
> > It causes a suspend failure to emit
> >
> > libxl: error: libxl_dom.c:2035:remus_teardown_done: Remus: failed to
> > teardown device for guest with domid 17, rc -3
> >
> > for
Hi Stefano,
On 09/02/15 15:40, Julien Grall wrote:
>>
>>> static void arm_smmu_init_context_bank(struct arm_smmu_domain
>>> *smmu_domain)
>>> {
>>> @@ -757,6 +996,7 @@ static void arm_smmu_init_context_bank(struct
>>> arm_smmu_domain *smmu_domain)
>>> struct arm_smmu_cfg *cfg = &smmu_dom
On Wed, 2015-02-18 at 17:36 +, Julien Grall wrote:
> Hi Ian,
>
> On 02/02/2015 15:09, Ian Campbell wrote:
> > On Thu, 2015-01-29 at 15:51 +, Julien Grall wrote:
> >> - Move the retry after looking for first/end. I keep the goto
> >> rather than a loop because it's more cl
On 19/02/15 17:11, Dario Faggioli wrote:
> by providing the definition of the {w,r}rmsr_tsc_msr counters,
> used within Viridiam implementation.
"Viridian"
>
> Signed-off-by: Dario Faggioli
> Cc: Paul Durrant
> CC: Jan Beulich
> Cc: Andrew Cooper
Reviewed-by: Andrew Cooper
> ---
> xen/inc
by providing the definition of the {w,r}rmsr_tsc_msr counters,
used within Viridiam implementation.
Signed-off-by: Dario Faggioli
Cc: Paul Durrant
CC: Jan Beulich
Cc: Andrew Cooper
---
xen/include/xen/perfc_defn.h |4
1 file changed, 4 insertions(+)
diff --git a/xen/include/xen/perf
On Thu, 2015-02-19 at 16:58 +, Andrew Cooper wrote:
> On 19/02/15 16:39, Ian Campbell wrote:
> > On Thu, 2015-02-19 at 11:45 +, Andrew Cooper wrote:
> >
> >> +while ( iov_idx < iovcnt )
> >> +{
> >> +/* Skip over iov[] entries with 0 length. */
> >> +while ( iov[iov_
On Thu, Feb 19, 2015 at 01:06:53PM +, David Vrabel wrote:
> Mel,
>
> The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not
> dereference pmd outside of the lock during NUMA hinting fault) and
> specifically 8a0516ed8b90 (mm: convert p[te|md]_numa users to
> p[te|md]_protnone_
On 19/02/15 16:39, Ian Campbell wrote:
> On Thu, 2015-02-19 at 11:45 +, Andrew Cooper wrote:
>
>> +while ( iov_idx < iovcnt )
>> +{
>> +/* Skip over iov[] entries with 0 length. */
>> +while ( iov[iov_idx].iov_len == 0 )
>> +if ( ++iov_idx == iovcnt )
>> +
On 15/02/2015 08:19, Bob Liu wrote:
Prepare patch for multi hardware queues, the ring number was mandatory set to 1.
[...]
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -107,21 +110,108 @@ static void xen_update_blkif_status(struct xen_blkif
*blkif)
On 15/02/2015 08:19, Bob Liu wrote:
Move the request complete logic out of blkif_interrupt() to a work queue,
after that we can replace 'spin_lock_irq' with 'spin_lock' so that irq won't
be disabled too long in blk_mq_queue_rq().
I think using a threaded interrupt (like scsifront) is better t
On Thu, 2015-02-19 at 12:43 +, Andrew Cooper wrote:
> It causes a suspend failure to emit
>
> libxl: error: libxl_dom.c:2035:remus_teardown_done: Remus: failed to
> teardown device for guest with domid 17, rc -3
>
> for all domains, including those not using remus at all.
>
> Signed-off-
On 02/19/2015 10:23 AM, David Vrabel wrote:
Hypercalls submitted by user space tools via the privcmd driver can
take a long time (potentially many 10s of seconds) if the hypercall
has many sub-operations.
A fully preemptible kernel may deschedule such as task in any upcall
called from a hypercal
On Thu, 2015-02-19 at 11:45 +, Andrew Cooper wrote:
> +while ( iov_idx < iovcnt )
> +{
> +/* Skip over iov[] entries with 0 length. */
> +while ( iov[iov_idx].iov_len == 0 )
> +if ( ++iov_idx == iovcnt )
> +goto out;
Is this required for som
Wei Liu writes ("Re: [PATCH v3] tools/xenconsoled: Increase file descriptor
limit"):
> On Tue, Feb 17, 2015 at 05:55:52PM +, Andrew Cooper wrote:
> > XenServer's VM density testing uncovered a regression when moving from
> > sysvinit to systemd where the file descriptor limit dropped from 4096
On Tue, 2015-02-17 at 17:55 +, Andrew Cooper wrote:
> + /*
> + * In the likely case that we are a root process with
> + * CAP_SYS_RESOURCE, attempt to up our hard limit.
> + */
(Nit: also the soft limit...)
Acked-by: Ian Campbell
On 19.02.2015 12:20, Andrew Cooper wrote:
Is it perhaps
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=f1e0df14412ccc6933a68eda66ac5b7d89186b62
There are a number of correctness fixes in that range which will
adversely affect performance.
I now reverted:
http://xenbits.xen.org/gitwe
On Thu, 2015-02-19 at 14:23 +, Frediano Ziglio wrote:
> I actually wondering why the branch at
> http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=shortlog;h=refs/heads/hisilicon-d01-v3
> was not merged into the master branch after the release.
Because AFAIK it hasn't been re
On Thu, 2015-02-19 at 14:37 +, Frediano Ziglio wrote:
> Hi,
> I just realized that this patch:
> - was not applied;
> - patch at
> http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=shortlog;h=refs/heads/hisilicon-d01-v3
> is completely different;
> - is not directly connecte
On 19/02/15 16:10, Ian Campbell wrote:
> On Thu, 2015-02-19 at 15:41 +, Julien Grall wrote:
>>> I did consider overriding the incorrect DT on such systems but since
>>> so far it has only been observed on emulators and we have code in
>>> place to deal with edge triggering here I think warning
Hi Ian,
On 19/02/15 16:09, Ian Campbell wrote:
> On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
>> The current VGIC code doesn't support to change the pending and active status
>> of an IRQ via the (re-)distributor.
>>
>> Futhermore, all the access size wasn't support correctly and some
>>
On Thu, 2015-02-19 at 15:41 +, Julien Grall wrote:
> > I did consider overriding the incorrect DT on such systems but since
> > so far it has only been observed on emulators and we have code in
> > place to deal with edge triggering here I think warning is sufficient
> > for now.
[...]
> > + *
On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
> The current VGIC code doesn't support to change the pending and active status
> of an IRQ via the (re-)distributor.
>
> Futhermore, all the access size wasn't support correctly and some
> registers was implemented as write-ignore. The latter
On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
> - Drop wrong comment about the default stride. It's not always 2 * SZ_64K.
> When the re-distributor support VLPIs (from GICv4), the default
> stride is 4 * SZ_64K
>
> - Explain why SZ_64K * 2
>
> Signed-off-by: Julien Grall
On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
> All the GICv2 registers are word-accessible. Some them are also
> byte-accessible (see GICD_IPRIORITYR*).
>
> Those registers are incorrectly implemented when they should be RAZ. Only
> word-access size are currently allowed for them.
>
> T
On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, Feb 12, 2015 at 07:19:09PM +0800, Ard Biesheuvel wrote:
> This refactors the Xen hypercall implementation that is part of the
> XenBusDxe driver, in preparation of splitting it off entirely into
> a XenHypercallLib library. This involves:
> - removing the dependency on XENBUS_DEVICE* pointe
On 19/02/15 15:58, Ian Campbell wrote:
> On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
>> The stride may not be set if the hardware GIC is using the default
>> layout. It happens on the Foundation model.
>>
>> On GICv3, the default stride is 2 * 64K. Therefore it's possible to avoid
>> che
On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
> The stride may not be set if the hardware GIC is using the default
> layout. It happens on the Foundation model.
>
> On GICv3, the default stride is 2 * 64K. Therefore it's possible to avoid
> checking at every redistributor MMIO access if t
On Mon, 2015-02-16 at 14:50 +, Julien Grall wrote:
> Some of the registers are accessible via multiple size (see GICD_IPRIORITYR*).
>
> Those registers are incorrectly implemented when they should be RAZ. Only
> word-access size are currently allowed for them.
>
> The paragraph 5.3.1 in the G
Hi Ian,
On 19/02/15 15:24, Ian Campbell wrote:
> The ICFGR register is not necessarily writeable, in particular it is
> IMPLEMENTATION DEFINED for a PPI if the configuration register is
> writeable. Log a warning if the hardware has ignored our write and
> update the actual type in the irq descrip
Hi Ian,
On 19/02/15 15:24, Ian Campbell wrote:
> Edge trigger arch timer interrupts really don't make much sense, so if
> we discover we are booting on such a system issue a warning.
>
> So far this has only been seen on the fast model emulators which have
> both an incorrect DT description of th
On Thu, Feb 12, 2015 at 07:19:08PM +0800, Ard Biesheuvel wrote:
> On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
> 32 bits, so casting between them needs to go via (UINTN). Also
> move the xen_pfn_t cast outside the shift so that we can avoid
> shifting 64-bit quantities on 32-bit a
(Marc, you are just CCd FYI after our conversation last week, I don't
imagine you care much about the actual patches, so I didn't send them to
you, I can if you like)
In f688aec47c45 "xen/arm: Handle platforms with edge-triggered virtual
timer" we added a workaround for an issue seen on fast model
Each of these functions will have their vcpu paramters replaced with domain
parameters because they are part of domain-generic rather than vcpu specific
codepaths, which means that the use of 'v' will have to change. 'current' can
be used to obtain a vcpu when in an appropriate context.
The 'curr
The ICFGR register is not necessarily writeable, in particular it is
IMPLEMENTATION DEFINED for a PPI if the configuration register is
writeable. Log a warning if the hardware has ignored our write and
update the actual type in the irq descriptor so subsequent code can do
the right thing.
This mos
On 19/02/15 13:59, Jan Beulich wrote:
> All,
>
> in the context of someone seeing "The kernel doesn't support reset
> from sysfs for PCI device", is my understanding correct that the lack
> of error checking in any caller (perhaps intentional) means that any
> of the errors logged from this functi
On Thu, 2015-02-19 at 16:09 +0100, Sander Eikelenboom wrote:
> Thursday, February 19, 2015, 3:30:52 PM, you wrote:
>
> > On Thu, 2015-02-19 at 13:59 +, Jan Beulich wrote:
> >> All,
> >>
> >> in the context of someone seeing "The kernel doesn't support reset
> >> from sysfs for PCI device", is
Edge trigger arch timer interrupts really don't make much sense, so if
we discover we are booting on such a system issue a warning.
So far this has only been seen on the fast model emulators which have
both an incorrect DT description of the interrupt and a writeable
ICFGR allowing us to program t
Hypercalls submitted by user space tools via the privcmd driver can
take a long time (potentially many 10s of seconds) if the hypercall
has many sub-operations.
A fully preemptible kernel may deschedule such as task in any upcall
called from a hypercall continuation.
However, in a kernel with vol
On Thu, 2015-02-19 at 14:53 +, Julien Grall wrote:
> On 19/02/15 12:15, Ian Campbell wrote:
> > On Tue, 2015-02-17 at 15:07 +, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 10/02/15 04:45, Ian Campbell wrote:
> >>> default:
> >>> @@ -2047,8 +2070,7 @@ asmlinkage void do_trap_hypervisor
>>> On 19.02.15 at 15:47, wrote:
> On 19/02/15 14:28, Jan Beulich wrote:
> On 19.02.15 at 14:01, wrote:
>>> The patch was designed to be be minimally invasive so it could be backported
>>> easily.
>>
>> So why is this tagged XEN-4.2 then? The EPT misconfig handling got
>> introduced with 4.5
On Thu, 2015-02-19 at 14:42 +, Julien Grall wrote:
> >>
> >> [..]
> >>
> >>> @@ -2062,8 +2053,7 @@ asmlinkage void do_trap_hypervisor(struct
> >>> cpu_user_regs *regs)
> >>> do_cp15_32(regs, hsr);
> >>> break;
> >>> case HSR_EC_CP15_64:
> >>> -if ( !is_32bit_d
Thursday, February 19, 2015, 3:30:52 PM, you wrote:
> On Thu, 2015-02-19 at 13:59 +, Jan Beulich wrote:
>> All,
>>
>> in the context of someone seeing "The kernel doesn't support reset
>> from sysfs for PCI device", is my understanding correct that the lack
>> of error checking in any caller
On Thu, Feb 12, 2015 at 07:19:07PM +0800, Ard Biesheuvel wrote:
> Tiancore has its private copy of the Xen headers, and all drivers
> that depend on it should use the same Xen interface version, so
> let's move the #define to xen.h itself.
>
> Contributed-under: TianoCore Contribution Agreement 1.
On 19/02/15 12:23, Ian Campbell wrote:
> On Tue, 2015-02-17 at 15:25 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 10/02/15 04:45, Ian Campbell wrote:
>>> Previously we implemented all registers as RAZ/WI even if they
>>> shouldn't be accessible to userspace.
>>>
>>> Accesses to the *_EL1 register
On 19/02/15 12:15, Ian Campbell wrote:
> On Tue, 2015-02-17 at 15:07 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 10/02/15 04:45, Ian Campbell wrote:
>>> default:
>>> @@ -2047,8 +2070,7 @@ asmlinkage void do_trap_hypervisor(struct
>>> cpu_user_regs *regs)
>>> advance_pc(regs, hsr);
On 19/02/15 14:28, Jan Beulich wrote:
On 19.02.15 at 14:01, wrote:
>> Upstream commit 1c84d046735102e02d2df454ab07f14ac51f235d (XSA-60 fix)
>> Stopped tracking of setting/unsetting of uncached mode in an HVM guest.
>> (This was later fixed by the EPT misconfig changes in Xen 4.5.)
>>
>> On ho
On 19/02/15 12:10, Ian Campbell wrote:
> On Tue, 2015-02-10 at 14:41 +0800, Julien Grall wrote:
>> Hi Ian,
>>
>> On 10/02/2015 12:45, Ian Campbell wrote:
>>> Previously 32-bit userspace on 32-bit kernel and 64-bit userspace on 64-bit
>>> kernel could access these registers irrespective of whether t
On 19/02/15 14:21, Jan Beulich wrote:
On 19.02.15 at 14:08, wrote:
>> On 19/02/15 11:08, Andreas Kinzler wrote:
>>> Hello Xen developers,
>>>
>>> since we use Xen for our production systems, I run many tests on Xen
>>> (stability/performance). One test now uncovered a serious performance
>>>
Hi,
I just realized that this patch:
- was not applied;
- patch at
http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=shortlog;h=refs/heads/hisilicon-d01-v3
is completely different;
- is not directly connected to our board so should be considered standalone.
Should I sent patch
On Thu, 2015-02-19 at 13:59 +, Jan Beulich wrote:
> All,
>
> in the context of someone seeing "The kernel doesn't support reset
> from sysfs for PCI device", is my understanding correct that the lack
> of error checking in any caller (perhaps intentional) means that any
> of the errors logged
>>> On 19.02.15 at 14:01, wrote:
> Upstream commit 1c84d046735102e02d2df454ab07f14ac51f235d (XSA-60 fix)
> Stopped tracking of setting/unsetting of uncached mode in an HVM guest.
> (This was later fixed by the EPT misconfig changes in Xen 4.5.)
>
> On hosts which do not have forced IOMMU snooping
2015-01-13 15:48 GMT+00:00 Frediano Ziglio :
> 2015-01-13 15:23 GMT+00:00 Ian Campbell :
>> On Tue, 2015-01-13 at 15:11 +, Frediano Ziglio wrote:
>>> 2015-01-13 14:42 GMT+00:00 Ian Campbell :
>>> > On Tue, 2015-01-13 at 14:09 +, Frediano Ziglio wrote:
>>> >> 2015-01-13 11:58 GMT+00:00 Ian C
>>> On 19.02.15 at 14:08, wrote:
> On 19/02/15 11:08, Andreas Kinzler wrote:
>> Hello Xen developers,
>>
>> since we use Xen for our production systems, I run many tests on Xen
>> (stability/performance). One test now uncovered a serious performance
>> regression when updating from Xen 4.2.3 to 4
On 19/02/15 13:10, Tim Deegan wrote:
> At 17:16 + on 12 Feb (1423757763), Andrew Cooper wrote:
>> It is incorrect to be applying these heuristics because of toolstack actions.
> It might be incorrect if we did, but we don't. :P
>
> The guess_wrmap() heuristics should only be called on v == curr
On 09/02/15 07:08, Juergen Gross wrote:
> On 02/07/2015 04:31 AM, Rudy Zhang wrote:
>> From: Tao Chen
>>
>> Signed-off-by: Tao Chen
>
> Are some white space fixes in comments really worth a patch?
No.
David
___
Xen-devel mailing list
Xen-devel@lists
On 11/02/15 19:39, Boris Ostrovsky wrote:
> Commit d524165cb8db ("x86/apic: Check x2apic early") tests X2APIC_ENABLE
> bit of MSR_IA32_APICBASE when CONFIG_X86_X2APIC is off and panics
> the kernel when this bit is set.
>
> Xen's PV guests will pass this MSR read to the hypervisor which will
> ret
On 19/02/15 07:17, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> For arm memory for 1024 irq descriptors are allocated
> statically irrespective of number of interrupt supported
> by the platform.
>
> With this patch, irq descriptors are allocated at run time
> and managed using red-b
1 - 100 of 139 matches
Mail list logo
