On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> When a system has PAT support enabled you don't need to be
> using MTRRs. Andy had added arch_phys_wc_add() long ago to
> help with this but not all drivers were converted over. We
> have to take care to onl
From: "Luis R. Rodriguez"
The crusade to replace mtrr_add() with architecture agnostic
arch_phys_wc_add() is complete, this will ensure write-combining
implementations (PAT on x86) is taken advantage instead of using
MTRR. With the crusade done now, hide direct MTRR access for
drivers.
Cc: Sures
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
flight 36527 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36527/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 36516
Tests which did not succee
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
The same area used for MTRR is used for the ioremap() area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that al
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR and ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also en
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
Hello Vijay,
On 19/03/2015 14:38, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K
Add Virtual ITS command processing support to
Virtual ITS driver. Also add API's to in physical
ITS driver to send commands from Virtual ITS driver.
In this patch, following are done
-Physical ITS driver wi
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
This driver uses the same ioremap()'d area for the MTRR.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also
From: "Luis R. Rodriguez"
Although this driver gives the framebuffer layer a different
size for the framebuffer it uses the entire aperture PCI BAR
size for the MTRR. Since the framebuffer is included in that
range and MTRR was used on the entire PCI BAR WC will have
been preferred on that range
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
This driver never removed the MTRRs. Fix that.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christophe Plagniol-Villard
Cc: To
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that al
From: "Luis R. Rodriguez"
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that al
From: "Luis R. Rodriguez"
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Hyong
From: "Luis R. Rodriguez"
There is only one user but since we're going to bury
MTRR next out of access to drivers expose this last
piece of API to drivers in a general fashion only
needing io.h for access to helpers.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Linus Torvalds
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap_wc(), if
anything it just uses a smaller size in case MTRR reservation fails.
ioremap_wc() API is already used to take advantage of architecture
write-combining when available.
Convert the driver from using the
From: "Luis R. Rodriguez"
The MTRR added was never being deleted.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valk
From: "Luis R. Rodriguez"
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB,
the other MTRR types were implemented and supported here but with
no real good reason. The ioremap() APIs are architecture agnostic and
at least on x86 PAT is a new design that extends MTRRs and
can repla
From: "Luis R. Rodriguez"
If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Moln
From: "Luis R. Rodriguez"
Sadly this driver requires a bit of work in order
to use ioremap_wc() on the range currently used
for MTRR write-combining. We'd need to ensure two
ioremap() calls are done. Annotate this.
Cc: Andy Lutomirski
Cc: Andy Walls
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> The atyfb driver uses an MTRR work around since some
> cards use the same PCI BAR for the framebuffer and MMIO.
> In such cards the last page is used for MMIO, the rest for
> the framebuffer, so on those car
flight 36570 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
From: "Luis R. Rodriguez"
This driver sadly does not have the MMIO registers and WC
desired areas (PIO buffers in this case) properly split up
and addressing a split is considerable work, as such this
such requires using the __arch_phys_wc_add() call to
ensure write combining is enforced using MT
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> This lets drivers take advanate of PAT when available. This
> should help with the transition of converting video drivers over
> to ioremap_wc() to help with the goal of eventually using
> _PAGE_CACHE_UC ove
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christophe Plagni
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> We have devm_ioremap_nocache() but no devm_ioremap_wc()
> so add that. This will be used later.
>
> Cc: Suresh Siddha
> Cc: Venkatesh Pallipadi
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc: Juergen Gross
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> Ideally on systems using PAT we can expect a swift
> transition away from MTRR. There can be a few exceptions
> to this, one is where device drivers are known to exist
> on PATs with errata, another situatio
From: "Luis R. Rodriguez"
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
Cc: Rickard Strandqvist
Cc: Dennis Dalessandro
Cc: Mike Marciniszyn
Cc: Roland Dreier
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Mol
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christophe Plagni
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
the framebuffer, so on those cards we ioremap() the MMIO
page alone, then again ioremap() the full fra
From: "Luis R. Rodriguez"
This has no functional changes, it just adjusts
the ioremap() call for the framebuffer to use
the same values we later use for the framebuffer,
this will make it easier to review the next change.
The size of the framebuffer varies but since this is
for PCI we *know* thi
From: "Luis R. Rodriguez"
The size of the framebuffer to be used needs to
be fudged to account for the different type of
devices that are out there. This captures what
is required to do well, we'll resuse this later.
This has no functional changes.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc
From: "Luis R. Rodriguez"
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few exceptions
to this, one is where device drivers are known to exist
on PATs with errata, another situation is observed on
old device drivers where devices had combined MMIO
re
From: "Luis R. Rodriguez"
This allows drivers to take advantage of write-combining
when possible. Ideally we'd have pci_read_bases() just
peg an IORESOURCE_WC flag for us but where exactly
video devices memory lie varies *largely* and at times things
are mixed with MMIO registers, sometimes we ca
From: "Luis R. Rodriguez"
This lets drivers take advanate of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e)
Cc: Su
From: "Luis R. Rodriguez"
We have devm_ioremap_nocache() but no devm_ioremap_wc()
so add that. This will be used later.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Dapla
From: "Luis R. Rodriguez"
It is possible to enable CONFIG_MTRR and up with it
disabled at run time and yet CONFIG_X86_PAT continues
to kick through fully functionally. This can happen
for instance on Xen where MTRR is not supported but
PAT is, this can happen now on Linux as of commit
47591df50 b
From: "Luis R. Rodriguez"
There area few users of mtrr_type_lookup(), including PAT.
Note that PAT can be in theory enabled without MTRR fully
kicking in, such is the case with Xen.
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen
From: "Luis R. Rodriguez"
When a system has PAT support enabled you don't need to be
using MTRRs. Andy had added arch_phys_wc_add() long ago to
help with this but not all drivers were converted over. We
have to take care to only convert drivers where we know that
the proper ioremap_wc() API has b
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary. When ballooning large amounts of memory
from dom0, freemem() would
On 03/20/2015 12:26 PM, Jan Beulich wrote:
On 19.03.15 at 22:54, wrote:
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -399,6 +399,67 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
break;
#endif
+#ifdef HAS_PCI
+case XEN_SYSCTL_pcitopoinfo:
+{
On 03/17/15 06:37, Ian Campbell wrote:
> On Tue, 2015-03-17 at 00:10 +, Slutz, Donald Christopher wrote:
>> @@ -715,7 +715,7 @@ static int hvm_ioreq_server_map_pages(struct
>> hvm_ioreq_server *s,
>>bool_t is_default, bool_t
>> handle_bufioreq)
>> {
>>
On 20/03/2015 01:22, Edgar E. Iglesias wrote:
Hi Julien,
Hello Edgar,
The partial device-tree support is nice and very flexible. I couldn't help
thinking that it would be nice to be able to describe more of the
guest with device-trees. It may be controversial but it would be cool
to be able t
It is already used in the runlevel script and the service file.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 8
1 file changed, 8 insertions(+)
diff --git a/tools/hotplug/Linu
An increasing version and/or release number helps to update existing
packages without --force as in "rpm Uvh --force xen.rpm". Instead its
possible to do "rpm -Fvh *.rpm" to update only already installed
packages.
The usage of --force disables essentials checks such as file conflict
detection. As
The following series is a resend of changes I already sent earlier
this year:
* Not sure if the last discussion about mkrpm was a yes or no for
inclusion. I find rpm -U --force dist/xen.rpm cumbersome...
* The XENSTORED_ARGS= should be fine according to IanJ
* The changes for reproducible buil
Mention two variables introduced by commit ac977f5 ("use more fixed
strings to build the hypervisor").
Signed-off-by: Olaf Hering
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
INSTALL | 6 ++
1 file changed, 6 insertions(+)
diff --git a/INSTALL b/I
To allow reproducible builds of hvmloader introduce a make variable
VGABIOS_REL_DATE="dd Mon " to provide a fixed date string. Without
this change the hvmloader binary changes with every rebuild.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
To allow reproducible builds of hvmloader introduce a make variable
SMBIOS_REL_DATE=mm/dd/ to provide a fixed date string. Without this
change the hvmloader binary changes with every rebuild.
Signed-off-by: Olaf Hering
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc:
>>> On 19.03.15 at 11:41, wrote:
> +static unsigned int get_socket_cpu(unsigned int socket)
> +{
> +unsigned int cpu;
> +
> +for_each_online_cpu ( cpu )
> + if ( cpu_to_socket(cpu) == socket )
> + return cpu;
> +return nr_cpu_ids;
> +}
This can be a rather long loop fo
I've been testing this and found a few problems:
1) I could not read a policy with sedispol (in the checkpolicy/test directory)
when the devicetreecon statement was included (checkpolicy built ok).
I've attached a patch that fixes this problem and included CIL Ref Guide
updates for the
On Fri, 2015-03-20 at 16:04 +, Ross Lagerwall wrote:
> 6d896e1357ff ("tools/libxl: Extend datacopier to support reading into a
> buffer") changed the semantics of the errnoval parameter for the datacopier
> callback without updating all callers. Restore the original behavior for now.
>
> Sign
On Fri, 2015-03-20 at 11:45 -0400, Konrad Rzeszutek Wilk wrote:
> From 45bd7cd377b0b8364757cc2bc0bd8d6a13523a97 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk
> Date: Fri, 13 Mar 2015 14:57:44 -0400
> Subject: [PATCH] libxc: Check xc_domain_maximum_gpfn for negative return
> values
>
> I
On Fri, 2015-03-20 at 17:44 +0100, Olaf Hering wrote:
> + ("dev", Struct(None, [("m", libxl_vscsi_hctl)])),
> + ("wwn", Struct(None, [("m", string)])),
> + ("hctl", Struct(None, [("m", libxl_vscsi_hctl)])),
> > Aside: What is the difference between dev and hctl in this cont
>>> On 19.03.15 at 11:41, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1090,9 +1090,9 @@ This option can be specified more than once (up to 8
> times at present).
> > `= `
>
> ### psr (Intel)
> -> `= List of ( cmt: | rmid_max: )`
> +> `=
From: Imre Palik
Date: Thu, 19 Mar 2015 11:05:42 +0100
> From: "Palik, Imre"
>
> With the current netback, the bandwidth limiter's parameters are only
> settable during vif setup time. This patch register a watch on them, and
> thus makes them runtime changeable.
>
> When the watch fires, the
>>> On 19.03.15 at 11:41, wrote:
> +static void __init parse_psr_bool(char* s, char* value, char* feature, int
> bit)
> +{
> +if ( !strcmp(s, feature) )
> +{
> +if ( !value )
> +opt_psr |= bit;
> +else
> +{
> +int val_int = parse_bool(value)
Hello Vijay,
On 19/03/2015 14:37, vijay.kil...@gmail.com wrote:
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 435dfcd..f091739 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -17,6 +17,8 @@ struct arch_pirq
struct arch_irq_desc {
int e
On Fri, Mar 20, Ian Campbell wrote:
> The name at (*) must be the enum member, which I've duplicated at (**)
> but you might like to thing about whether (**) would have a better name
> in the context of e.g. vscsi_dev->u.dev.dev or vscsi_dev->u.wwn.wwn.
Thanks Ian. For some reason I have ocaml di
>>> On 20.03.15 at 17:19, wrote:
> This reverts commit dd748d128d86996592afafea02e578cc7d4e6d42.
>
> We don't need this workaround anymore since we have fixed the toolstack
> interlock problem that affects stubdom.
>
> Signed-off-by: Wei Liu
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Acked-by: I
Hello Vijay,
On 19/03/2015 14:37, vijay.kil...@gmail.com wrote:
+struct page_info *get_page_from_paddr(struct domain *d, paddr_t paddr,
+ unsigned long flags)
+{
+struct p2m_domain *p2m = &d->arch.p2m;
+struct page_info *page = NULL;
+
+ASSERT(d =
... and not devices_destroy_cb because it is the right place to clean up
device model stuff.
And the path should use LIBXL_TOOLSTACK_DOMID instead of hardcoded 0.
Signed-off-by: Wei Liu
Acked-by: Ian Campbell
---
Changes in v2:
1. Use helper function to generate xenstore path.
---
tools/libxl/
This reverts commit dd748d128d86996592afafea02e578cc7d4e6d42.
We don't need this workaround anymore since we have fixed the toolstack
interlock problem that affects stubdom.
Signed-off-by: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
Acked-by: Ian Campbell
---
xen/arch/x86/hvm/hvm.c |
This patch series tries to reason about various hardcoded "/local/domain/0" in
libxl and 1) replace them with something sensible, 2) fix QEMU startup
protocol.
Please apply a patch to QEMU traditional first, squash the update to Config.mk
into "libxl: use new QEMU xenstore protocol" to keep the tr
The function in question is libxl__spawn_local_dm. We should use
LIBXL_TOOLSTACK_DOMID when constructing xenstore path.
Currently LIBXL_TOOLSTACK_DOMID is 0, so this patch introduces no
functional change.
Use helper function to generate xenstore path.
Signed-off-by: Wei Liu
Acked-by: Ian Campbe
Factor out libxl__vsprintf. Use it to implement
libxl__device_model_xs_patch helper to return xenstore path for device
model to avoid handcoded paths.
Signed-off-by: Wei Liu
---
Changes in v3:
1. Factor out libxl__vsprintf.
---
tools/libxl/libxl_internal.c | 40 ++
Originally both QEMU traditional and QEMU upstream used hardcoded
/local/domain/0 paths. This patch changes the protocol to use
/local/domain/$dm_domid path.
For QEMU traditional and upstream without stubdom, $dm_domid is 0 so
the path is in fact still /local/domain/0.
For QEMU traditional stubdo
Again because Xen doesn't get to see all guest writes, it shouldn't
serve reads from its cache before having seen a write to the respective
address.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -153,12 +153,15 @@ struct msixtbl_entry
/* TODO: res
Commit 74fd0036de ("x86: properly handle MSI-X unmask operation from
guests") didn't go far enough: it fixed an issue with unmasking, but
left an issue with masking in place: Due to the (late) point in time
when qemu requests the hypervisor to set up MSI-X interrupts (which is
where the MMIO interc
>>> On 19.03.15 at 22:54, wrote:
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -399,6 +399,67 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> u_sysctl)
> break;
> #endif
>
> +#ifdef HAS_PCI
> +case XEN_SYSCTL_pcitopoinfo:
> +{
> +xen_sysctl_pcit
Hi Vijay,
On 19/03/2015 14:37, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K
Add ITS support for arm. Following major features
are supported
- GICv3 ITS support for arm64 platform
- Supports multi ITS node
- LPI descriptors are allocated on-demand
- Only ITS Dom0 is supported
Tes
>>> On 19.03.15 at 22:54, wrote:
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -274,53 +274,62 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> u_sysctl)
>
> case XEN_SYSCTL_numainfo:
> {
> -uint32_t i, j, max_node_index, last_online_node;
> +uin
On Fri, 2015-03-20 at 16:02 +, Ross Lagerwall wrote:
> On 03/20/2015 11:15 AM, Ian Campbell wrote:
> > On Fri, 2015-03-20 at 11:03 +, Ian Campbell wrote:
> >> Do the new callers actually need the number of bytes read/written or was
> >> this just something which seemed like a good idea sinc
On Fri, 2015-03-20 at 09:14 -0600, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Tue, 2015-03-17 at 09:30 -0600, Jim Fehlig wrote:
> >
> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> >> index b6541d4..b43db1a 100644
> >> --- a/tools/libxl/libxl.c
> >> +++ b/tools/libxl/libxl.c
> >
6d896e1357ff ("tools/libxl: Extend datacopier to support reading into a
buffer") changed the semantics of the errnoval parameter for the datacopier
callback without updating all callers. Restore the original behavior for now.
Signed-off-by: Ross Lagerwall
---
tools/libxl/libxl_aoutils.c | 2 +-
On 03/20/2015 11:15 AM, Ian Campbell wrote:
On Fri, 2015-03-20 at 11:03 +, Ian Campbell wrote:
Do the new callers actually need the number of bytes read/written or was
this just something which seemed like a good idea since it was in hand?
If it isn't needed
In fact, irrespective of the n
Due to the (late) point in time when qemu requests the hypervisor to
set up MSI-X interrupts (which is where the MMIO intercept gets put
in place), the hypervisor doesn't see all guest writes, and hence
shouldn't make assumptions on the state the virtual MSI-X resources
are in.
1: honor all mask r
> > All of them are
> >
> > git://xenbits.xen.org/people/konradwilk/xen.git xc_cleanup.v4
..snip..
> Looks good, only one minor comment:
> [...]
>
> > -*gpfn = (xen_pfn_t)rc + 1;
>
> Perhaps the new parameter to xc_domain_maximum_gpfn should be a
> xen_pfn_t?
>
Here you go. They are at:
With ->startup unmasking the IRQ, setting the affinity afterwards
without masking the IRQ again is invalid namely for MSI (which can't
have their affinity updated atomically).
Signed-off-by: Jan Beulich
---
Changing the affinity of non-maskable MSI IRQs seems bogus too, but I
can't immediately se
At 15:22 + on 20 Mar (1426864937), Jan Beulich wrote:
> Xen L4 entries being uniformly installed into any L4 table and 64-bit
> PV kernels running in ring 3 means that user mode was able to see the
> read-only M2P presented by Xen to the guests. While apparently not
> really representing an exp
On 20/03/2015 13:56, Robert VanVossen wrote:
xen/drivers/passthrough/arm/smmu.c | 113
1 file changed, 88 insertions(+), 25 deletions(-)
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index a7a7da9..9b46054 100
Hi,
At 15:21 + on 20 Mar (1426864897), Jan Beulich wrote:
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -343,6 +343,15 @@ extern unsigned long xen_phys_start;
> #define ARG_XLAT_START(v)\
> (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT
On 18.02.2015 04:56, Jim Fehlig wrote:
> This series is a follow up to
>
> https://www.redhat.com/archives/libvir-list/2015-February/msg00024.html
>
> It goes a step further and changes the libxl driver to use one,
> driver-wide libxl_ctx. Currently the libxl driver has one driver-wide
> ctx for
1 - 100 of 206 matches
Mail list logo
