Re: [Xen-devel] [ovmf test] 59044: trouble: blocked/broken/fail/pass
On Fri, 2015-07-03 at 22:40 +, osstest service owner wrote:
flight 59044 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59044/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3864 capture-logs !broken
[st=!broken!]
Seems to be Osstest/JobDB/Executive.pm line 137:
die Dumper($ho). ? if $ho-{SharedOthers} !
$ho-{SharedReady};
So another sharing related glitch, like the linux-3.18 flight 59041 I
just pointedy ou at (which was on armhf though).
Any ideas?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Problems with merlot* AMD Opteron 6376 systems (Was Re: stable trees
On 29.06.15 at 15:13, boris.ostrov...@oracle.com wrote: On 06/29/2015 06:23 AM, Ian Campbell wrote: On Fri, 2015-06-26 at 21:07 +0100, Ian Campbell wrote: On Fri, 2015-06-26 at 15:36 -0400, Boris Ostrovsky wrote: Just to make sure, could you use explicit address, i.e. for i in $(seq 0 31) ;do rdmsr -p $i 0xc001001d; done It reported 43f00 on all processors on native (and only the first 8 on Xen due to limited dom0 vcpus). (and if they are still all zeroes, can you read 0xc0010010 (SYSCFG) as well?) It wasn't all zeroes, but anyway, it reported 74 on all processors on native (I forgot to run under Xen). Thanks, so this means that we do have WB memory above 4G. Good (because no fw problem) and bad (because still no reason for the observed behavior). (And I am not sure I understand why Jan said MTRRs show that memory above 4G is UC in http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg04397.html . The log also seems to suggest that it is WB, doesn't it?) How would it? The two MTRRs only cover the ranges 0-2G and 2G-3G afaics. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] libxl: Make local_initiate_attach more rational
On 07/03/2015 03:28 PM, Ian Campbell wrote: On Thu, 2015-07-02 at 19:55 +0200, Roger Pau Monné wrote: El 02/07/15 a les 19.42, George Dunlap ha escrit: There are a lot of paths through libxl__device_disk_local_initiate_attach(), but they all really boil down to one thing: Can we just access the file directly, or do we need to attach it? The requirements for direct access are fairly simple: * Is this local (as opposed to a driver domain)? * Is this a raw format (as opposed to cooked)? * Does this have no scripts associated with it? If it meets all those requirements, we can access it directly; otherwise we need to attach it. This fixes a bug where bootloader execution fails for disks with hotplug scripts. This should fix a theoretical bug when using a qdisk backend in a driver domain. (Not tested.) Based on a patch by Roger Pau Monne roger@citrix.com. Signed-off-by: George Dunlap george.dun...@eu.citrix.com LGTM Acked-by: Roger Pau Monné roger@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com Hmm, this one seems somehow not to build because now ctx isn't used anywhere. I'm going to re-send this in a bit as part of a longer series switching to blktap -- I'll take the liberty to retain both of your Acks. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Mapping Dom0 page in hypervisor from domctl
Hi, At 08:14 -0400 on 02 Jul (1435824854), Bread Cutter wrote: /* Translate the given virtual address to the guest frame number */ gfn = paging_gva_to_gfn(current, domctl-va, pfec); This function only works for domains that have paging assistance enabled (i.e. not typically dom0). You might try using guest_get_eff_l1e() to find the PTE that maps domctl-va; that works for PV guests. There's some code in ptwr_do_page_fault() that you could start with. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6
On 07/04/2015 02:01 AM, Julien Grall wrote: The commit efb6de9b4ba0092b2c55f6a52d16294a8a698edd netfilter: bridge: forward IPv6 fragmented packets introduced a new function br_validate_ipv6 which take a reference on the inet6 device. Although, the reference is not released at the end. This will result to the impossibility to destroy any netdevice using ipv6 and bridge. Spotted while trying to destroy a Xen guest on the upstream Linux: unregister_netdevice: waiting for vif1.0 to become free. Usage count = 1 Signed-off-by: Julien Grall julien.gr...@citrix.com Also hit the same issue, thank you for the fix. Tested-by: Bob Liu bob@oracle.com Cc: Bernhard Thaler bernhard.tha...@wvnet.at Cc: Pablo Neira Ayuso pa...@netfilter.org Cc: f...@strlen.de Cc: ian.campb...@citrix.com Cc: wei.l...@citrix.com --- Note that it's impossible to create new guest after this message. I'm not sure if it's normal. --- net/bridge/br_netfilter_ipv6.c | 5 + 1 file changed, 5 insertions(+) diff --git a/net/bridge/br_netfilter_ipv6.c b/net/bridge/br_netfilter_ipv6.c index 6d12d26..7046e19 100644 --- a/net/bridge/br_netfilter_ipv6.c +++ b/net/bridge/br_netfilter_ipv6.c @@ -140,11 +140,16 @@ int br_validate_ipv6(struct sk_buff *skb) /* No IP options in IPv6 header; however it should be * checked if some next headers need special treatment */ + + in6_dev_put(idev); + return 0; inhdr_error: IP6_INC_STATS_BH(dev_net(dev), idev, IPSTATS_MIB_INHDRERRORS); drop: + in6_dev_put(idev); + return -1; } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass
Ian Campbell writes (Re: [Xen-devel] [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass): On Fri, 2015-07-03 at 22:21 +, osstest service owner wrote: build-armhf-xsm 4 host-build-prep fail REGR. vs. 58581 A strange one I think. resource host arndale-metrocentre shared build-wheezy-armhf 3c464fbf8a05b24f4afb7e58bcf4ae77fbb7ad0c not build-wheezy-armhf 8600096139e58a283eb2c23c769673d451487e1c at Osstest/Executive.pm line 840. This is a safety catch - effectively, an assertion failure. It is trying to mark arndale-metrocentre suitable for other jobs to use, with a sharing key of build-wheezy-armhf 8600096139e58a283eb2c23c769673d451487e1c What it is asserting is that the host is currently in preparation, with the same sharing key. But the host's sharing key was build-wheezy-armhf 3c464fbf8a05b24f4afb7e58bcf4ae77fbb7ad0c The hash is the osstest revision. This is the result of me updating the osstest revision under its feet. Nice to see in http://logs.test-lab.xenproject.org/osstest/results/history/build-armhf-xsm/linux-3.18 that my display of multiple osstest revisions works :-). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 12/13] x86/altp2m: Add altp2mhvm HVM domain parameter.
On 01/07/15 19:09, Ed White wrote: --- a/xen/include/public/hvm/params.h +++ b/xen/include/public/hvm/params.h @@ -187,6 +187,9 @@ /* Location of the VM Generation ID in guest physical address space. */ #define HVM_PARAM_VM_GENERATION_ID_ADDR 34 -#define HVM_NR_PARAMS 35 +/* Boolean: Enable altp2m (hvm only) */ HVM_PARAMS are explicitly hvm only. No need to say so. Hypervisor bits Reviewed-by: Andrew Cooper andrew.coop...@citrix.com +#define HVM_PARAM_ALTP2MHVM35 + +#define HVM_NR_PARAMS 36 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Migration bug added by commit 2df1aa01bef7366798248ac6d03cfb42048b003d
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 06 July 2015 11:14
To: Paul Durrant
Cc: Don Slutz; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] Migration bug added by commit
2df1aa01bef7366798248ac6d03cfb42048b003d
On 06.07.15 at 12:08, paul.durr...@citrix.com wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 06 July 2015 11:03
To: Don Slutz
Cc: Paul Durrant; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Migration bug added by commit
2df1aa01bef7366798248ac6d03cfb42048b003d
On 29.06.15 at 17:14, don.sl...@gmail.com wrote:
On 06/29/15 10:03, Paul Durrant wrote:
I think this patch should do it for now:
diff --git a/xen/arch/x86/hvm/emulate.c
b/xen/arch/x86/hvm/emulate.c
index a4d7225..cc6130c 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -183,7 +183,7 @@ static int hvmemul_do_io(
else
{
rc = hvm_send_assist_req(s, p);
-if ( rc != X86EMUL_RETRY )
+if ( rc != X86EMUL_RETRY || curr-domain-is_shutting_down
)
I do not know enough about is_shutting_down to agree. What is clear
is that
this test is not the same as !vcpu_start_shutdown_deferral(curr).
Together with Paul's reply the main question appears to have
remained un-answered: Does the patch suggested by Paul address
the problem you observed?
I can at least say that the patch definitely resolved a regression seen in
automated testing of migration of Windows Server 2003 VMs on
XenServer.
Good. Not even having got close to the end of unread mails, I
suppose I'll find it somewhere as a formal submission...
Yes, it's 01/16 of v6 of the series. Andrew has already reviewed it.
Paul
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 2/3] xen/vm_event: Support for guest-requested events
On 30.06.15 at 16:48, tleng...@novetta.com wrote:
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -342,13 +342,15 @@ struct arch_domain
/* Monitor options */
struct {
-uint16_t write_ctrlreg_enabled : 4;
-uint16_t write_ctrlreg_sync : 4;
-uint16_t write_ctrlreg_onchangeonly : 4;
-uint16_t mov_to_msr_enabled : 1;
-uint16_t mov_to_msr_extended : 1;
-uint16_t singlestep_enabled : 1;
-uint16_t software_breakpoint_enabled : 1;
+uint32_t write_ctrlreg_enabled : 4;
+uint32_t write_ctrlreg_sync : 4;
+uint32_t write_ctrlreg_onchangeonly : 4;
+uint32_t mov_to_msr_enabled : 1;
+uint32_t mov_to_msr_extended : 1;
+uint32_t singlestep_enabled : 1;
+uint32_t software_breakpoint_enabled : 1;
+uint32_t request_enabled : 1;
+uint32_t request_sync: 1;
Can you please switch to plain unsigned int if you already have to
touch this? There's no reason I can see to use a fixed width integer
type here.
Ack, will make it plain int.
IMHO having it fix-width is easier to read when adding new elements to see
how many bits we have left free. I would not want this changed unless there
is a clear benefit to doing so.
I can't see what benefit using fixed widht types here is: Best
demonstrated with uint64_t, gcc doesn't honor the type of the
field anyway. And hence counting the number of left bits (with
some unknown definition of left) is quite pointless too - it's an
internal structure, and when a new bit field needs to be added,
it doesn't really matter whether it grows the structure (at least
no more than any other field addition).
Bottom line - no fixed width types when not really warranted,
please.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass
On Mon, 2015-07-06 at 11:16 +0100, Ian Jackson wrote: Ian Campbell writes (Re: [Xen-devel] [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass): On Fri, 2015-07-03 at 22:21 +, osstest service owner wrote: build-armhf-xsm 4 host-build-prep fail REGR. vs. 58581 A strange one I think. resource host arndale-metrocentre shared build-wheezy-armhf 3c464fbf8a05b24f4afb7e58bcf4ae77fbb7ad0c not build-wheezy-armhf 8600096139e58a283eb2c23c769673d451487e1c at Osstest/Executive.pm line 840. This is a safety catch - effectively, an assertion failure. It is trying to mark arndale-metrocentre suitable for other jobs to use, with a sharing key of build-wheezy-armhf 8600096139e58a283eb2c23c769673d451487e1c What it is asserting is that the host is currently in preparation, with the same sharing key. But the host's sharing key was build-wheezy-armhf 3c464fbf8a05b24f4afb7e58bcf4ae77fbb7ad0c The hash is the osstest revision. This is the result of me updating the osstest revision under its feet. I somehow managed to miss that those massive numbers making up 2/3 of the log message were different... Nice to see in http://logs.test-lab.xenproject.org/osstest/results/history/build-armhf-xsm/linux-3.18 that my display of multiple osstest revisions works :-). Yes indeed! Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 04/19] xen/passthrough: extend hypercall to support rdm reservation policy
On 01.07.15 at 12:47, tiejun.c...@intel.com wrote:
On 2015/7/1 18:02, George Dunlap wrote:
On 07/01/2015 02:11 AM, Chen, Tiejun wrote:
/* XEN_DOMCTL_createdomain */
struct xen_domctl_createdomain {
/* IN parameters */
uint32_t ssidref;
xen_domain_handle_t handle;
/* Is this an HVM guest (as opposed to a PVH or PV guest)? */
#define _XEN_DOMCTL_CDF_hvm_guest 0
#define XEN_DOMCTL_CDF_hvm_guest (1U_XEN_DOMCTL_CDF_hvm_guest)
/* Use hardware-assisted paging if available? */
#define _XEN_DOMCTL_CDF_hap 1
#define XEN_DOMCTL_CDF_hap(1U_XEN_DOMCTL_CDF_hap)
/* Should domain memory integrity be verifed by tboot during Sx? */
#define _XEN_DOMCTL_CDF_s3_integrity 2
#define XEN_DOMCTL_CDF_s3_integrity (1U_XEN_DOMCTL_CDF_s3_integrity)
/* Disable out-of-sync shadow page tables? */
#define _XEN_DOMCTL_CDF_oos_off 3
#define XEN_DOMCTL_CDF_oos_off(1U_XEN_DOMCTL_CDF_oos_off)
/* Is this a PVH guest (as opposed to an HVM or PV guest)? */
#define _XEN_DOMCTL_CDF_pvh_guest 4
#define XEN_DOMCTL_CDF_pvh_guest (1U_XEN_DOMCTL_CDF_pvh_guest)
uint32_t flags;
Yes, this demonstrates my point. Each of these is a single-bit boolean
value that takes up a single bit -- either on or off. But here you have
three values -- NO_DRM, RELAXED, and STRICT, that take up two bits. If
Is this fine to you?
#define _XEN_DOMCTL_DEV_NO_RDM 0
#define XEN_DOMCTL_DEV_NO_RDM (1U_XEN_DOMCTL_DEV_NO_RDM)
#define _XEN_DOMCTL_DEV_RDM_RELAXED 1
#define XEN_DOMCTL_DEV_RDM_RELAXED (1U_XEN_DOMCTL_DEV_RDM_RELAXED)
#define _XEN_DOMCTL_DEV_RDM_STRICT 2
#define XEN_DOMCTL_DEV_RDM_STRICT (1U_XEN_DOMCTL_DEV_RDM_STRICT)
AIUI these aren't individual flags, but kind of an enumeration. I.e.
you should keep the original definitions and add - as suggested by
George - a mask (two bits wide right now).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On 05/07/15 06:55, Manish Jaggi wrote:
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
u32 s;
u8 b;
u8 df;
u16 res;
} sbdf_t;
struct physdev_map_sbdf {
int domain_id;
sbdf_tsbdf;
sbdf_tgsbdf;
};
Each domain has a pdev list, which contains the list of all pci devices.
The
pdev structure already has a sbdf information. The arch_pci_dev is
updated to
contain the gsbdf information. (gs- guest segment id)
Whenever there is trap from guest or an interrupt has to be injected,
the pdev
list is iterated to find the gsbdf.
Can you give more background for this section? i.e:
- Why do you need this?
- How xen will translate the gbdf to a vDeviceID?
In the context of the hypercall processing.
That wasn't my question. I asked, how Xen will find the mapping between
the gdbf and vDeviceID? He doesn't have access to the firmware table and
therefore not able to find the right one.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/41] arm/acpi: Build numa for x86 only
On 05.07.15 at 19:39, julien.gr...@citrix.com wrote: On 05/07/2015 13:59, Parth Dixit wrote: +shannon I've just received ~50 mails +shannon. Couldn't you have forward all the email privately rather replying to every single mail and cc shannon? Seconded. Considering this I simply deleted all the mails by you on that thread and on that day. Should there have been anything that I indeed needed to look at, please point this out specifically. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/6] libxl: Use the block-tap script for LIBXL_DISK_BACKEND_TAP
On 06/07/15 11:51, George Dunlap wrote: The block-tap script can now do everything needed for libxl; no need to link against the blktap library. To do this: * Set disk-script to block-tap and dev to format:pdev_path in device_disk_add for LIBXL_DISK_BACKEND_TAP * Remove libxl_blktap2.o and libxl_noblktap2.o and all code depending on them Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Dave Scott dave.sc...@eu.citrix.com CC: Jonathan Ludlam jonathan.lud...@eu.citrix.com CC: Wen Congyang we...@cn.fujitsu.com CC: Yang Hongyang yan...@cn.fujitsu.com CC: Felipe Franciosi felipe.franci...@citrix.com Note: This is broken for HVM domains at the moment because all block scripts are broken for HVM domains. That is a bug which should be a blocker for the 4.6 release. As such, I think there is justification for checking in this feature (enabling use of a 'system' blktap) with the assumption that the FIXME will go away before the release. That will technically break bisectability; but only for users of blktap (which does not include osstest). --- tools/libxl/Makefile | 5 --- tools/libxl/libxl.c | 28 - tools/libxl/libxl_blktap2.c | 93 --- tools/libxl/libxl_device.c| 14 --- tools/libxl/libxl_dm.c| 5 ++- tools/libxl/libxl_internal.h | 26 tools/libxl/libxl_noblktap2.c | 42 --- 7 files changed, 11 insertions(+), 202 deletions(-) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index cc9c152..43ab243 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -44,11 +44,6 @@ LIBXL_LIBS += $(LIBXL_LIBS-y) LIBXLU_LIBS = libxenlight.so LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o -ifeq ($(LIBXL_BLKTAP),y) You will also want to remove reference to LIBXL_BLKTAP from Rules.mk ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 6/6] xen: arm: consolidate mmio and irq mapping to dom0
Hi Ian, On 03/07/15 16:56, Ian Campbell wrote: The code in the callbacks for dt_for_each_irq_map and dt_for_each_range is very similar to the code in handle_device for each non-pci device. In fact the only major difference is that the irq callback needs to call irq_set_spi_type in the PCI case. Refactor into a map_dt_irq_to_domain callback which does the irq_set_spi_type and then calls map_irq_to_domain which is also used from handle_device. For mmio map_range_to_domain can already be used directly from handle_device too. Signed-off-by: Ian Campbell ian.campb...@citrix.com Reviewed-by: Julien Grall julien.gr...@citrix.com Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Monday 06 July 2015 04:13 PM, Julien Grall wrote:
On 05/07/15 06:55, Manish Jaggi wrote:
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
u32 s;
u8 b;
u8 df;
u16 res;
} sbdf_t;
struct physdev_map_sbdf {
int domain_id;
sbdf_tsbdf;
sbdf_tgsbdf;
};
Each domain has a pdev list, which contains the list of all pci devices.
The
pdev structure already has a sbdf information. The arch_pci_dev is
updated to
contain the gsbdf information. (gs- guest segment id)
Whenever there is trap from guest or an interrupt has to be injected,
the pdev
list is iterated to find the gsbdf.
Can you give more background for this section? i.e:
- Why do you need this?
- How xen will translate the gbdf to a vDeviceID?
In the context of the hypercall processing.
That wasn't my question. I asked, how Xen will find the mapping between
the gdbf and vDeviceID? He doesn't have access to the firmware table and
therefore not able to find the right one.
I believe gsbdf and vDeviceID would be same. In the hypercall processing
its_assign_device would be called
with params its_assign_device(sbdf, gsbdf, domid)
Regards,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6
On Mon, 2015-07-06 at 11:35 +0100, Julien Grall wrote:
__in6_dev_get requires to hold rcu_read_lock or RTNL. My knowledge on
this code is very limited. Are we sure that one this lock is hold? At
first glance, I wasn't able to find one.
You could play it safe ;)
diff --git a/net/bridge/br_netfilter_ipv6.c b/net/bridge/br_netfilter_ipv6.c
index 6d12d2675c80..90e8ccc21cc5 100644
--- a/net/bridge/br_netfilter_ipv6.c
+++ b/net/bridge/br_netfilter_ipv6.c
@@ -104,10 +104,12 @@ int br_validate_ipv6(struct sk_buff *skb)
{
const struct ipv6hdr *hdr;
struct net_device *dev = skb-dev;
- struct inet6_dev *idev = in6_dev_get(skb-dev);
+ struct inet6_dev *idev;
u32 pkt_len;
u8 ip6h_len = sizeof(struct ipv6hdr);
+ rcu_read_lock();
+ idev = __in6_dev_get(dev);
if (!pskb_may_pull(skb, ip6h_len))
goto inhdr_error;
@@ -140,11 +142,13 @@ int br_validate_ipv6(struct sk_buff *skb)
/* No IP options in IPv6 header; however it should be
* checked if some next headers need special treatment
*/
+ rcu_read_unlock();
return 0;
inhdr_error:
IP6_INC_STATS_BH(dev_net(dev), idev, IPSTATS_MIB_INHDRERRORS);
drop:
+ rcu_read_unlock();
return -1;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m
On 01.07.15 at 20:09, edmund.h.wh...@intel.com wrote: Changes since v2: Addressed all v2 feedback *except*: In patch 5, the per-domain EPTP list page is still allocated from the Xen heap. If allocated from the domain heap Xen panics - IIRC on Haswell hardware when walking the EPTP list during exit processing in patch 6. With this little detail I can't take this as a valid reason not to make this change. Also - weren't we aiming at getting the page from the HAP pool of the domain anyway? HVM_ops are not merged. Tamas suggested merging the memory access ops, but in practice they are not as similar as they appear on the surface. Razvan suggested merging the implementation code in p2m.c, but that is also not as common as it appears on the surface. Andrew suggested merging all altp2m ops into one with a subop code in the input stucture. His point that only 255 ops can be defined is well taken, but altp2m uses only 2 more ops than the recently introduced ioreq ops, and 15% of the available ops have been defined. Since we don't know how to implement XSM hooks and policy with the subop model, we have not adopted this suggestion. Again, not very convincing an argument, but I'll need to take another look at the patches for a final opinion. The p2m set/get interface is not modified. The altp2m code needs to write suppress_ve in 2 places and read it in 1 place. The original patch series managed this by coupling the state of suppress_ve to the p2m memory type, which Tim disliked. In v2 of the series, special set/get interaces were added to access suppress_ve only when required. Jan has suggested changing the existing interfaces, but we feel this is inappropriate for this experimental patch series. Changing the existing interfaces would require a design agreement to be reached and would impact a large amount of existing code. I continue to think the adjustment should be made as suggested. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RESEND PATCH] xen/blkfront: convert to blk-mq APIs
From: Arianna Avanzini avanzini.aria...@gmail.com
This patch converts xen-blkfront driver to use the block multiqueue APIs.
Only one hardware queue is used now, so there is no performance change.
The legacy non-mq code was deleted completely which is the same as other drivers
like virtio, mtip, and nvme.
Also dropped unnecessary holding of info-io_lock when calling into blk-mq APIs.
Signed-off-by: Arianna Avanzini avanzini.aria...@gmail.com
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c | 173 ++
1 file changed, 73 insertions(+), 100 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 6d89ed3..831a577 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -37,6 +37,7 @@
#include linux/interrupt.h
#include linux/blkdev.h
+#include linux/blk-mq.h
#include linux/hdreg.h
#include linux/cdrom.h
#include linux/module.h
@@ -148,6 +149,7 @@ struct blkfront_info
unsigned int feature_persistent:1;
unsigned int max_indirect_segments;
int is_ready;
+ struct blk_mq_tag_set tag_set;
};
static unsigned int nr_minors;
@@ -616,54 +618,45 @@ static inline bool blkif_request_flush_invalid(struct
request *req,
!(info-feature_flush REQ_FUA)));
}
-/*
- * do_blkif_request
- * read a block; request is in a request queue
- */
-static void do_blkif_request(struct request_queue *rq)
+static int blk_mq_queue_rq(struct blk_mq_hw_ctx *hctx,
+ const struct blk_mq_queue_data *qd)
{
- struct blkfront_info *info = NULL;
- struct request *req;
- int queued;
-
- pr_debug(Entered do_blkif_request\n);
-
- queued = 0;
-
- while ((req = blk_peek_request(rq)) != NULL) {
- info = req-rq_disk-private_data;
-
- if (RING_FULL(info-ring))
- goto wait;
-
- blk_start_request(req);
+ struct blkfront_info *info = qd-rq-rq_disk-private_data;
+ int ret = BLK_MQ_RQ_QUEUE_OK;
- if (blkif_request_flush_invalid(req, info)) {
- __blk_end_request_all(req, -EOPNOTSUPP);
- continue;
- }
+ blk_mq_start_request(qd-rq);
+ spin_lock_irq(info-io_lock);
+ if (RING_FULL(info-ring)) {
+ spin_unlock_irq(info-io_lock);
+ blk_mq_stop_hw_queue(hctx);
+ ret = BLK_MQ_RQ_QUEUE_BUSY;
+ goto out;
+ }
- pr_debug(do_blk_req %p: cmd %p, sec %lx,
-(%u/%u) [%s]\n,
-req, req-cmd, (unsigned long)blk_rq_pos(req),
-blk_rq_cur_sectors(req), blk_rq_sectors(req),
-rq_data_dir(req) ? write : read);
-
- if (blkif_queue_request(req)) {
- blk_requeue_request(rq, req);
-wait:
- /* Avoid pointless unplugs. */
- blk_stop_queue(rq);
- break;
- }
+ if (blkif_request_flush_invalid(qd-rq, info)) {
+ spin_unlock_irq(info-io_lock);
+ ret = BLK_MQ_RQ_QUEUE_ERROR;
+ goto out;
+ }
- queued++;
+ if (blkif_queue_request(qd-rq)) {
+ spin_unlock_irq(info-io_lock);
+ blk_mq_stop_hw_queue(hctx);
+ ret = BLK_MQ_RQ_QUEUE_BUSY;
+ goto out;
}
- if (queued != 0)
- flush_requests(info);
+ flush_requests(info);
+ spin_unlock_irq(info-io_lock);
+out:
+ return ret;
}
+static struct blk_mq_ops blkfront_mq_ops = {
+ .queue_rq = blk_mq_queue_rq,
+ .map_queue = blk_mq_map_queue,
+};
+
static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
unsigned int physical_sector_size,
unsigned int segments)
@@ -671,9 +664,22 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16
sector_size,
struct request_queue *rq;
struct blkfront_info *info = gd-private_data;
- rq = blk_init_queue(do_blkif_request, info-io_lock);
- if (rq == NULL)
+ memset(info-tag_set, 0, sizeof(info-tag_set));
+ info-tag_set.ops = blkfront_mq_ops;
+ info-tag_set.nr_hw_queues = 1;
+ info-tag_set.queue_depth = BLK_RING_SIZE(info);
+ info-tag_set.numa_node = NUMA_NO_NODE;
+ info-tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_SG_MERGE;
+ info-tag_set.cmd_size = 0;
+ info-tag_set.driver_data = info;
+
+ if (blk_mq_alloc_tag_set(info-tag_set))
+ return -1;
+ rq = blk_mq_init_queue(info-tag_set);
+ if (IS_ERR(rq)) {
+ blk_mq_free_tag_set(info-tag_set);
return -1;
+ }
queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq);
@@ -901,19 +907,15 @@
Re: [Xen-devel] [PATCH v3 05/13] x86/altp2m: basic data structures and support routines.
On 03.07.15 at 18:22, andrew.coop...@citrix.com wrote: On 01/07/15 19:09, Ed White wrote: Add the basic data structures needed to support alternate p2m's and the functions to initialise them and tear them down. Although Intel hardware can handle 512 EPTP's per hardware thread concurrently, only 10 per domain are supported in this patch for performance reasons. The iterator in hap_enable() does need to handle 512, so that is now uint16_t. This change also splits the p2m lock into one lock type for altp2m's and another type for all other p2m's. The purpose of this is to place the altp2m list lock between the types, so the list lock can be acquired whilst holding the host p2m lock. Signed-off-by: Ed White edmund.h.wh...@intel.com Only some style issues. Otherwise, Reviewed-by: Andrew Cooper andrew.coop...@citrix.com To be honest, with coding style issues having been pointed out before, them left un-addressed in more just an occasional instance moves me towards ignoring such a submission altogether. Please help reviewers and maintainers by addressing _all_ of them even if only a few (or just one) got pointed out during review. This also helps you by avoiding to do another round just for addressing these. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Migration bug added by commit 2df1aa01bef7366798248ac6d03cfb42048b003d
On 29.06.15 at 17:14, don.sl...@gmail.com wrote:
On 06/29/15 10:03, Paul Durrant wrote:
I think this patch should do it for now:
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index a4d7225..cc6130c 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -183,7 +183,7 @@ static int hvmemul_do_io(
else
{
rc = hvm_send_assist_req(s, p);
-if ( rc != X86EMUL_RETRY )
+if ( rc != X86EMUL_RETRY || curr-domain-is_shutting_down )
I do not know enough about is_shutting_down to agree. What is clear
is that
this test is not the same as !vcpu_start_shutdown_deferral(curr).
Together with Paul's reply the main question appears to have
remained un-answered: Does the patch suggested by Paul address
the problem you observed?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Monday 06 July 2015 02:41 PM, Ian Campbell wrote:
On Sun, 2015-07-05 at 11:25 +0530, Manish Jaggi wrote:
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci device's BAR
regions.
These are defined in arch-arm.h
/* For 32bit */
GUEST_MMIO_HOLE0_BASE, GUEST_MMIO_HOLE0_SIZE
/* For 64bit */
GUEST_MMIO_HOLE1_BASE , GUEST_MMIO_HOLE1_SIZE
The memory layout for 32bit and 64bit are exactly the same. Why do you
need to differ here?
I think Ian has already replied. I will change the name of macro
4.2 New entries in xenstore for device BARs
toolkit also updates the xenstore information for the device
(virtualbar:physical bar).
This information is read by xenpciback and returned to the pcifront
driver configuration
space accesses.
Can you details what do you plan to put in xenstore and how?
It is implementation . But I plan to put under domU / device / heirarchy
Actually, xenstore is an API of sorts which needs to be maintained going
forward (since front and backend can evolve separately, so it does need
some level of design and documentation.
What about the expansion ROM?
Do you want to put some restriction on not using expansion ROM as a
passthrough device.
expansion ROM as a passthrough device doesn't make sense to me,
passthrough devices may _have_ an expansion ROM.
The expansion ROM is just another BAR. I don't know how pcifront/back
deal with those today on PV x86, but I see no reason for ARM to deviate.
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
u32 s;
u8 b;
u8 df;
u16 res;
} sbdf_t;
struct physdev_map_sbdf {
int domain_id;
sbdf_tsbdf;
sbdf_tgsbdf;
};
Each domain has a pdev list, which contains the list of all pci devices.
The
pdev structure already has a sbdf information. The arch_pci_dev is
updated to
contain the gsbdf information. (gs- guest segment id)
Whenever there is trap from guest or an interrupt has to be injected,
the pdev
list is iterated to find the gsbdf.
Can you give more background for this section? i.e:
- Why do you need this?
- How xen will translate the gbdf to a vDeviceID?
In the context of the hypercall processing.
- Who will call this hypercall?
- Why not setting the gsbdf when the device is assigned?
Can the maintainer of the pciback suggest an alternate.
That's not me, but I don't think this belongs here, I think it can be
done from the toolstack. If you think not then please explain what
information the toolstack doesn't have in its possession which prevents
this mapping from being done there.
The toolstack does not have the guest sbdf information. I could only
find it in xenpciback.
The answer to your question is that I have only found a place to issue
the hypercall where
all the information can be located is the function
__xen_pcibk_add_pci_dev
drivers/xen/xen-pciback/vpci.c
unlock:
...
kfree(dev_entry);
+ /*Issue Hypercall here */
+#ifdef CONFIG_ARM64
+ map_sbdf.domain_id = pdev-xdev-otherend_id;
+ map_sbdf.sbdf_s = dev-bus-domain_nr;
+ map_sbdf.sbdf_b = dev-bus-number;
+ map_sbdf.sbdf_d = dev-devfn3;
+ map_sbdf.sbdf_f = dev-devfn 0x7;
+ map_sbdf.gsbdf_s = 0;
+ map_sbdf.gsbdf_b = 0;
+ map_sbdf.gsbdf_d = slot;
+ map_sbdf.gsbdf_f = dev-devfn 0x7;
+ pr_info(## sbdf = %d:%d:%d.%d g_sbdf %d:%d:%d.%d \
+ domain_id=%d ##\r\n,
+ map_sbdf.sbdf_s,
+ map_sbdf.sbdf_b,
+ map_sbdf.sbdf_d,
+ map_sbdf.sbdf_f,
+ map_sbdf.gsbdf_s,
+ map_sbdf.gsbdf_b,
+ map_sbdf.gsbdf_d,
+ map_sbdf.gsbdf_f,
+ map_sbdf.domain_id);
+
+ err = HYPERVISOR_physdev_op(PHYSDEVOP_map_sbdf, map_sbdf);
+ if (err)
+ printk(KERN_ERR Xen Error PHYSDEVOP_map_sbdf);
+#endif
---
Regards,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Migration bug added by commit 2df1aa01bef7366798248ac6d03cfb42048b003d
On 06.07.15 at 12:08, paul.durr...@citrix.com wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 06 July 2015 11:03
To: Don Slutz
Cc: Paul Durrant; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Migration bug added by commit
2df1aa01bef7366798248ac6d03cfb42048b003d
On 29.06.15 at 17:14, don.sl...@gmail.com wrote:
On 06/29/15 10:03, Paul Durrant wrote:
I think this patch should do it for now:
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index a4d7225..cc6130c 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -183,7 +183,7 @@ static int hvmemul_do_io(
else
{
rc = hvm_send_assist_req(s, p);
-if ( rc != X86EMUL_RETRY )
+if ( rc != X86EMUL_RETRY || curr-domain-is_shutting_down )
I do not know enough about is_shutting_down to agree. What is clear
is that
this test is not the same as !vcpu_start_shutdown_deferral(curr).
Together with Paul's reply the main question appears to have
remained un-answered: Does the patch suggested by Paul address
the problem you observed?
I can at least say that the patch definitely resolved a regression seen in
automated testing of migration of Windows Server 2003 VMs on XenServer.
Good. Not even having got close to the end of unread mails, I
suppose I'll find it somewhere as a formal submission...
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 01/32] libxc: split x86 HVM setup_guest into smaller logical functions
On 03/07/15 12:34, Roger Pau Monne wrote:
This is just a preparatory change to clean up the code in setup_guest.
Should not introduce any functional changes.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com, with one note.
@@ -576,6 +584,44 @@ static int setup_guest(xc_interface *xch,
goto error_out;
}
+/* Insert JMP rel32 instruction at address 0x0 to reach entry point. */
+entry_eip = elf_uval(elf, elf.ehdr, e_entry);
+if ( entry_eip != 0 )
+{
+char *page0 = xc_map_foreign_range(
+xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
+if ( page0 == NULL )
+goto error_out;
+page0[0] = 0xe9;
+*(uint32_t *)page0[1] = entry_eip - 5;
+munmap(page0, PAGE_SIZE);
+}
With this series eventually enabling DOMCTL_setvcpucontext properly for
HVM vcpus, this above juggling can be replaced by setting the starting
eip appropriately, which is neater than stuffing a hand-coded
instruction in at 0.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 6/6] libxl: Add more logging to hotplug script path
This was useful in tracking down bugs.
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_device.c | 20 +---
tools/libxl/libxl_linux.c | 5 +
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c1ca07b..d2ae42f 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -920,11 +920,13 @@ static void device_backend_callback(libxl__egc *egc,
libxl__ev_devstate *ds,
libxl__ao_device *aodev = CONTAINER_OF(ds, *aodev, backend_ds);
STATE_AO_GC(aodev-ao);
+LOG(DEBUG, calling device_backend_cleanup);
device_backend_cleanup(gc, aodev);
if (rc == ERROR_TIMEDOUT
aodev-action == LIBXL__DEVICE_ACTION_REMOVE
!aodev-force) {
+LOG(DEBUG, Timeout reached, initiating forced remove);
aodev-force = 1;
libxl__initiate_device_remove(egc, aodev);
return;
@@ -967,10 +969,18 @@ static void device_hotplug(libxl__egc *egc,
libxl__ao_device *aodev)
* hotplug scripts
*/
rc = libxl__get_domid(gc, domid);
-if (rc) goto out;
+if (rc) {
+LOG(ERROR, Failed to get domid);
+goto out;
+}
if (aodev-dev-backend_domid != domid) {
-if (aodev-action != LIBXL__DEVICE_ACTION_REMOVE)
+LOG(DEBUG, Backend domid %d, domid %d, assuming driver domains,
+aodev-dev-backend_domid, domid);
+
+if (aodev-action != LIBXL__DEVICE_ACTION_REMOVE) {
+LOG(DEBUG, Not a remove, not executing hotplug scripts);
goto out;
+}
aodev-xswait.ao = ao;
aodev-xswait.what = removal of backend path;
@@ -978,8 +988,11 @@ static void device_hotplug(libxl__egc *egc,
libxl__ao_device *aodev)
aodev-xswait.timeout_ms = LIBXL_DESTROY_TIMEOUT * 1000;
aodev-xswait.callback = device_destroy_be_watch_cb;
rc = libxl__xswait_start(gc, aodev-xswait);
-if (rc)
+if (rc) {
+LOG(ERROR, Setup of backend removal watch failed (path %s),
be_path);
goto out;
+}
+
return;
}
@@ -991,6 +1004,7 @@ static void device_hotplug(libxl__egc *egc,
libxl__ao_device *aodev)
switch (hotplug) {
case 0:
/* no hotplug script to execute */
+LOG(DEBUG, No hotplug script to execute);
goto out;
case 1:
/* execute hotplug script */
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 512d2c9..4fbcba1 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -214,6 +214,7 @@ static int libxl__hotplug_disk(libxl__gc *gc, libxl__device
*dev,
*env = get_hotplug_env(gc, script, dev);
if (!*env) {
+LOG(ERROR, Failed to get hotplug environment);
rc = ERROR_FAIL;
goto error;
}
@@ -225,6 +226,7 @@ static int libxl__hotplug_disk(libxl__gc *gc, libxl__device
*dev,
(*args)[nr++] = NULL;
assert(nr == arraysize);
+LOG(DEBUG, Args and environment ready);
rc = 1;
error:
@@ -241,6 +243,7 @@ int libxl__get_hotplug_script_info(libxl__gc *gc,
libxl__device *dev,
switch (dev-backend_kind) {
case LIBXL__DEVICE_KIND_VBD:
if (num_exec != 0) {
+LOG(DEBUG, num_exec %d, not running hotplug scripts\n, num_exec);
rc = 0;
goto out;
}
@@ -253,6 +256,7 @@ int libxl__get_hotplug_script_info(libxl__gc *gc,
libxl__device *dev,
*/
if ((num_exec 1) ||
(libxl_get_stubdom_id(CTX, dev-domid) num_exec)) {
+LOG(DEBUG, num_exec %d, not running hotplug scripts\n, num_exec);
rc = 0;
goto out;
}
@@ -260,6 +264,7 @@ int libxl__get_hotplug_script_info(libxl__gc *gc,
libxl__device *dev,
break;
default:
/* No need to execute any hotplug scripts */
+LOG(DEBUG, backend_kind %d, no need to execute scripts,
dev-backend_kind);
rc = 0;
break;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/6] libxl: Use the block-tap script for LIBXL_DISK_BACKEND_TAP
The block-tap script can now do everything needed for libxl; no need
to link against the blktap library.
To do this:
* Set disk-script to block-tap and dev to format:pdev_path in
device_disk_add for LIBXL_DISK_BACKEND_TAP
* Remove libxl_blktap2.o and libxl_noblktap2.o and all code depending
on them
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Dave Scott dave.sc...@eu.citrix.com
CC: Jonathan Ludlam jonathan.lud...@eu.citrix.com
CC: Wen Congyang we...@cn.fujitsu.com
CC: Yang Hongyang yan...@cn.fujitsu.com
CC: Felipe Franciosi felipe.franci...@citrix.com
Note: This is broken for HVM domains at the moment because all block
scripts are broken for HVM domains. That is a bug which should be a
blocker for the 4.6 release. As such, I think there is justification
for checking in this feature (enabling use of a 'system' blktap)
with the assumption that the FIXME will go away before the release.
That will technically break bisectability; but only for users of
blktap (which does not include osstest).
---
tools/libxl/Makefile | 5 ---
tools/libxl/libxl.c | 28 -
tools/libxl/libxl_blktap2.c | 93 ---
tools/libxl/libxl_device.c| 14 ---
tools/libxl/libxl_dm.c| 5 ++-
tools/libxl/libxl_internal.h | 26
tools/libxl/libxl_noblktap2.c | 42 ---
7 files changed, 11 insertions(+), 202 deletions(-)
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index cc9c152..43ab243 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -44,11 +44,6 @@ LIBXL_LIBS += $(LIBXL_LIBS-y)
LIBXLU_LIBS = libxenlight.so
LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
-ifeq ($(LIBXL_BLKTAP),y)
-LIBXL_OBJS-y += libxl_blktap2.o
-else
-LIBXL_OBJS-y += libxl_noblktap2.o
-endif
ifeq ($(CONFIG_REMUS_NETBUF),y)
LIBXL_OBJS-y += libxl_netbuffer.o
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3a83903..2aab0c2 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2469,13 +2469,10 @@ static void device_disk_add(libxl__egc *egc, uint32_t
domid,
switch (disk-backend) {
case LIBXL_DISK_BACKEND_PHY:
dev = disk-pdev_path;
-
-do_backend_phy:
-flexarray_append(back, params);
-flexarray_append(back, dev);
-
script = libxl__abs_path(gc, disk-script?: block,
libxl__xen_script_dir_path());
+do_backend_phy:
+flexarray_append_pair(back, params, dev);
flexarray_append_pair(back, script, script);
/* If the user did not supply a block script then we
@@ -2497,25 +2494,16 @@ static void device_disk_add(libxl__egc *egc, uint32_t
domid,
break;
case LIBXL_DISK_BACKEND_TAP:
-if (dev == NULL) {
-dev = libxl__blktap_devpath(gc, disk-pdev_path,
-disk-format);
-if (!dev) {
-LOG(ERROR, failed to get blktap devpath for %p\n,
-disk-pdev_path);
-rc = ERROR_FAIL;
-goto out;
-}
-}
-flexarray_append(back, tapdisk-params);
-flexarray_append(back, libxl__sprintf(gc, %s:%s,
-libxl__device_disk_string_of_format(disk-format),
-disk-pdev_path));
-
/* tap backends with scripts are rejected by
* libxl__device_disk_set_backend */
assert(!disk-script);
+script = libxl__abs_path(gc, block-tap,
+ libxl__xen_script_dir_path());
+dev = libxl__sprintf(gc, %s:%s,
+ libxl__device_disk_string_of_format(disk-format),
+ disk-pdev_path);
+
/* now create a phy device to export the device to the guest */
goto do_backend_phy;
case LIBXL_DISK_BACKEND_QDISK:
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
deleted file mode 100644
index 2053403..000
--- a/tools/libxl/libxl_blktap2.c
+++ /dev/null
@@ -1,93 +0,0 @@
-/*
- * Copyright (C) 2010 Advanced Micro Devices
- * Author Christoph Egger christoph.eg...@amd.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU Lesser General Public License as published
- * by the Free Software Foundation; version 2.1 only.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR
[Xen-devel] [PATCH 2/6] libxl: Remove linux udev rules
They are no longer needed, having been replaced by a daemon for driverdomains which will run scripts as necessary. Worse yet, they seem to be broken for script-based block devices, such as block-iscsi. This wouldn't matter so much if they were never run by default; but if you run block-attach without having created a domain, then the appropriate node to disable running udev scripts will not have been written yet, and the attach will silently fail. Rather than try to sort out that issue, just remove them entirely. Note: This changes tools/configure.ac, so autogen.sh may need to be re-run. Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Roger Pau Monne roger@citrix.com There was some concern that old udev scripts may end up lying around in /etc which will still trigger and run unless libxl/disable_udev exists. If that's a concern, then for one release we might consider writing libxl/disable_udev manually in xencommons or something to make sure that they don't trigger. --- tools/configure | 13 ++--- tools/configure.ac | 1 - tools/examples/README| 1 - tools/hotplug/Linux/Makefile | 14 +- tools/hotplug/Linux/xen-backend.rules.in | 13 - tools/hotplug/Linux/xen-hotplug-common.sh.in | 7 --- tools/libxl/libxl.c | 13 - tools/libxl/libxl_create.c | 27 --- tools/libxl/libxl_internal.c | 19 --- tools/libxl/libxl_internal.h | 1 - tools/libxl/libxl_linux.c| 7 --- tools/libxl/libxl_netbsd.c | 7 --- 12 files changed, 7 insertions(+), 116 deletions(-) diff --git a/tools/configure b/tools/configure index c940dd1..5138f3d 100755 --- a/tools/configure +++ b/tools/configure @@ -2403,7 +2403,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu -ac_config_files=$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons libxl/xenlight.pc.in libxl/xlutil.pc.in +ac_config_files=$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons libxl/xenlight.pc.in libxl/xlutil.pc.in ac_config_headers=$ac_config_headers config.h @@ -3343,7 +3343,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 62) - 1 + ((off_t) 1 62)) +#define LARGE_OFF_T off_t) 1 31) 31) - 1 + (((off_t) 1 31) 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -3389,7 +3389,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 62) - 1 + ((off_t) 1 62)) +#define LARGE_OFF_T off_t) 1 31) 31) - 1 + (((off_t) 1 31) 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -3413,7 +3413,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 62) - 1 + ((off_t) 1 62)) +#define LARGE_OFF_T off_t) 1 31) 31) - 1 + (((off_t) 1 31) 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -3458,7 +3458,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 62) - 1 + ((off_t) 1 62)) +#define LARGE_OFF_T off_t) 1 31) 31) - 1 + (((off_t) 1 31) 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -3482,7 +3482,7 @@ rm -f core conftest.err
[Xen-devel] [PATCH 3/6] tools: Add a block-tap script for setting up tapdisks via tap-ctl
The blocktap library isn't really necessary; all the necessary functionality
is available via the tap-ctl binary.
To use:
script=block-tap,vdev=[whatever],target=vhd:/path/to/file.vhd
script=block-tap,vdev=[whatever],target=aio:/path/to/file.raw
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Roger Pau Monne roger@citrix.com
CC: Felipe Franciosi felipe.franci...@citrix.com
CC: Dave Scott dave.sc...@eu.citrix.com
CC: Jonathan Ludlam jonathan.lud...@eu.citrix.com
---
tools/hotplug/Linux/Makefile | 1 +
tools/hotplug/Linux/block-tap | 123 ++
2 files changed, 124 insertions(+)
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 8bb2316..bc8ee5e 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -23,6 +23,7 @@ XEN_SCRIPTS += xen-hotplug-cleanup
XEN_SCRIPTS += external-device-migrate
XEN_SCRIPTS += vscsi
XEN_SCRIPTS += block-iscsi
+XEN_SCRIPTS += block-tap
XEN_SCRIPTS += block-drbd-probe
XEN_SCRIPTS += $(XEN_SCRIPTS-y)
diff --git a/tools/hotplug/Linux/block-tap b/tools/hotplug/Linux/block-tap
new file mode 100755
index 000..8924792
--- /dev/null
+++ b/tools/hotplug/Linux/block-tap
@@ -0,0 +1,123 @@
+#!/bin/bash -e
+#
+# tapdisk Xen block device hotplug script
+#
+# Author George Dunlap george.dun...@eu.citrix.com
+#
+# Based on block-iscsi by Roger Pau Monné roger@citrix.com
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License as published
+# by the Free Software Foundation; version 2.1 only. with the special
+# exception on linking described in file LICENSE.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Lesser General Public License for more details.
+#
+# Usage:
+#
+# Target should be specified using the following syntax:
+#
+# script=block-tap,vdev=xvda,target=type:file
+#
+# Type is either aio (for raw files), or vhd
+
+dir=$(dirname $0)
+. $dir/block-common.sh
+
+remove_label()
+{
+echo $1 | sed s/^\($2\)//
+}
+
+check_tools()
+{
+if ! command -v tap-ctl /dev/null 21; then
+fatal Unable to find tap-ctl tool
+fi
+modprobe blktap
+if ! tap-ctl check /dev/null ; then
+ fatal Blocktap kernel module not available
+fi
+}
+
+# Sets the following global variables based on the params field passed in as
+# a parameter: type file
+parse_target()
+{
+params=($(echo $1 | tr : \n))
+
+type=${params[0]}
+file=${params[1]}
+if [ -z $type ] || [ -z $file ]; then
+fatal Cannot parse required parameters
+fi
+}
+
+# Sets $pid and $minor to point to the device associated with the target
+find_device()
+{
+local info
+local param
+
+if [ -z $type ] || [ -z $file ]; then
+fatal required parameters not set
+fi
+
+info=$(tap-ctl list -t $type -f $file)
+
+for param in $(echo $info | tr , \n)
+do
+case $param in
+pid=*)
+pid=$(remove_label $param pid=)
+;;
+minor=*)
+minor=$(remove_label $param minor=)
+;;
+esac
+done
+
+if [ -z $pid ] || [ -z $minor ]; then
+fatal cannot find required parameters
+fi
+}
+
+# Attaches the device and writes xenstore backend entries to connect
+# the device
+add()
+{
+dev=$(tap-ctl create -a $target)
+write_dev $dev
+}
+
+# Disconnects the device
+remove()
+{
+find_device
+do_or_die tap-ctl destroy -p ${pid} -m ${minor} /dev/null
+}
+
+command=$1
+target=$(xenstore-read $XENBUS_PATH/params || true)
+if [ -z $target ]; then
+fatal No information about the target
+fi
+
+parse_target $target
+
+check_tools || exit 1
+
+case $command in
+add)
+add
+;;
+remove)
+remove
+;;
+*)
+exit 1
+;;
+esac
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 02/32] libxc: unify xc_dom_p2m_{host/guest}
On 03/07/15 12:34, Roger Pau Monne wrote: Unify both functions into xc_dom_p2m. Should not introduce any functional change. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Samuel Thibault samuel.thiba...@ens-lyon.org Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/6] Use system blktap
Switch to using a blktap provided by the system, rather than building it in-tree. Do this by adding a block-tap script which calls the tap-ctl binary, rather than linking against a library. This requires the use of an externally-built tap-ctl binary, which an be built from the master branch of the XenServer blktap tree at https://github.com/xapi-project/blktap.git The first two patches and the final patch are general libxl disk handling improvements which can be applied independently of the core. The third patch (tools: Add a block-tap script for setting up tapdisks via tap-ctl) can also be checked in independently from the fourth and fifth, as it allows someone to disable blktap support in configure but still use externally-built tap-ctl binaries (albeit with a different disk string). The fifth patch is a straight rm -rf of toosl/blktap2. Rather than spam everyone's mailboxes I've clipped the message here, and provided a tree which can be pulled from: git://xenbits.xen.org/people/gdunlap/xen.git out/blktap-system/v1 This series also exposes blktap to a bug that prevents HVM guests from using disks created with block scripts. This should be a blocker for the 4.6 release, so I think we should consider checking this series in as is, assuming that bug will be addressed before the release. George Dunlap (6): libxl: Make local_initiate_attach more rational libxl: Remove linux udev rules tools: Add a block-tap script for setting up tapdisks via tap-ctl libxl: Use the block-tap script for LIBXL_DISK_BACKEND_TAP tools: Remove in-tree blktap2 libxl: Add more logging to hotplug script path tools/Makefile |1 - [tools/blktap2/* removal trimmed] tools/config.h.in|3 - tools/configure | 29 +- tools/configure.ac | 13 +- tools/examples/README|1 - tools/hotplug/Linux/Makefile | 15 +- tools/hotplug/Linux/block-tap| 123 + tools/hotplug/Linux/xen-backend.rules.in | 13 - tools/hotplug/Linux/xen-hotplug-common.sh.in |7 - tools/libxl/Makefile |5 - tools/libxl/libxl.c | 139 +- tools/libxl/libxl_blktap2.c | 93 - tools/libxl/libxl_create.c | 27 - tools/libxl/libxl_device.c | 34 +- tools/libxl/libxl_dm.c |5 +- tools/libxl/libxl_internal.c | 19 - tools/libxl/libxl_internal.h | 27 - tools/libxl/libxl_linux.c| 12 +- tools/libxl/libxl_netbsd.c |7 - tools/libxl/libxl_noblktap2.c| 42 - 146 files changed, 194 insertions(+), 40550 deletions(-) [delete mode 100644 tools/blktap2/* trimmed] -- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Roger Pau Monne roger@citrix.com CC: Felipe Franciosi felipe.franci...@citrix.com CC: Dave Scott dave.sc...@eu.citrix.com CC: Jonathan Ludlam jonathan.lud...@eu.citrix.com 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/6] libxl: Make local_initiate_attach more rational
There are a lot of paths through
libxl__device_disk_local_initiate_attach(), but they all really boil
down to one thing: Can we just access the file directly, or do we need
to attach it?
The requirements for direct access are fairly simple:
* Is this local (as opposed to a driver domain)?
* Is this a raw format (as opposed to cooked)?
* Does this have no scripts associated with it?
If it meets all those requirements, we can access it directly;
otherwise we need to attach it.
This fixes a bug where bootloader execution fails for disks with
hotplug scripts.
This should fix a theoretical bug when using a qdisk backend in a
driver domain. (Not tested.)
Based on a patch by Roger Pau Monne roger@citrix.com.
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
Acked-by: Roger Pau Monné roger@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Roger Pau Monne roger@citrix.com
This is identical to the patch I sent earlier, with the exception that
I have fixed a build by removing the (now) unused ctx variable. Given
the circumstances I have taken the liberty to retain the Acks above.
---
tools/libxl/libxl.c | 98 ++---
1 file changed, 26 insertions(+), 72 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e9a2d26..92563db 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3058,7 +3058,6 @@ void libxl__device_disk_local_initiate_attach(libxl__egc
*egc,
libxl__disk_local_state *dls)
{
STATE_AO_GC(dls-ao);
-libxl_ctx *ctx = CTX;
char *dev = NULL;
int rc;
const libxl_device_disk *in_disk = dls-in_disk;
@@ -3076,55 +3075,21 @@ void
libxl__device_disk_local_initiate_attach(libxl__egc *egc,
rc = libxl__device_disk_setdefault(gc, disk);
if (rc) goto out;
-switch (disk-backend) {
-case LIBXL_DISK_BACKEND_PHY:
-LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, locally attaching PHY disk %s,
- disk-pdev_path);
-dev = disk-pdev_path;
-break;
-case LIBXL_DISK_BACKEND_TAP:
-switch (disk-format) {
-case LIBXL_DISK_FORMAT_RAW:
-/* optimise away the early tapdisk attach in this case */
-LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, locally attaching
-tap disk %s directly (ie without using blktap),
- disk-pdev_path);
-dev = disk-pdev_path;
-break;
-case LIBXL_DISK_FORMAT_VHD:
-dev = libxl__blktap_devpath(gc, disk-pdev_path,
-disk-format);
-break;
-case LIBXL_DISK_FORMAT_QCOW:
-case LIBXL_DISK_FORMAT_QCOW2:
-abort(); /* prevented by libxl__device_disk_set_backend */
-default:
-LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
- unrecognized disk format: %d, disk-format);
-rc = ERROR_FAIL;
-goto out;
-}
-break;
-case LIBXL_DISK_BACKEND_QDISK:
-if (disk-format != LIBXL_DISK_FORMAT_RAW) {
-libxl__prepare_ao_device(ao, dls-aodev);
-dls-aodev.callback = local_device_attach_cb;
-device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk,
-dls-aodev, libxl__alloc_vdev,
-(void *) blkdev_start);
-return;
-} else {
-dev = disk-pdev_path;
-}
-LOG(DEBUG, locally attaching qdisk %s, dev);
-break;
-default:
-LIBXL__LOG(ctx, LIBXL__LOG_ERROR, unrecognized disk backend
-type: %d, disk-backend);
-rc = ERROR_FAIL;
-goto out;
+/* If this is in a driver domain, or it's not a raw format, or it involves
+ * running a script, we have to do a local attach. */
+if (disk-backend_domname != NULL
+|| disk-format != LIBXL_DISK_FORMAT_RAW
+|| disk-script != NULL) {
+libxl__prepare_ao_device(ao, dls-aodev);
+dls-aodev.callback = local_device_attach_cb;
+device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk, dls-aodev,
+libxl__alloc_vdev, (void *) blkdev_start);
+return;
}
+LOG(DEBUG, locally attaching RAW disk %s, disk-pdev_path);
+dev = disk-pdev_path;
+
if (dev != NULL)
dls-diskpath = libxl__strdup(gc, dev);
@@ -3157,7 +3122,7 @@ static void local_device_attach_cb(libxl__egc *egc,
libxl__ao_device *aodev)
}
dev = GCSPRINTF(/dev/%s, disk-vdev);
-LOG(DEBUG, locally attaching qdisk %s, dev);
+LOG(DEBUG, locally attaching disk %s, dev);
rc =
[Xen-devel] [PATCH 5/6] tools: Remove in-tree blktap2
Now that libxl has been configured to use a block script for tapdisk, we can remove the in-tree blktap and let the user build an out-of-tree blktap. Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Dave Scott dave.sc...@eu.citrix.com CC: Jonathan Ludlam jonathan.lud...@eu.citrix.com CC: Wen Congyang we...@cn.fujitsu.com CC: Yang Hongyang yan...@cn.fujitsu.com --- [Patch trimmed] ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 04/19] xen/passthrough: extend hypercall to support rdm reservation policy
Yes, this demonstrates my point. Each of these is a single-bit boolean value that takes up a single bit -- either on or off. But here you have three values -- NO_DRM, RELAXED, and STRICT, that take up two bits. If Is this fine to you? #define _XEN_DOMCTL_DEV_NO_RDM 0 #define XEN_DOMCTL_DEV_NO_RDM (1U_XEN_DOMCTL_DEV_NO_RDM) #define _XEN_DOMCTL_DEV_RDM_RELAXED 1 #define XEN_DOMCTL_DEV_RDM_RELAXED (1U_XEN_DOMCTL_DEV_RDM_RELAXED) #define _XEN_DOMCTL_DEV_RDM_STRICT 2 #define XEN_DOMCTL_DEV_RDM_STRICT (1U_XEN_DOMCTL_DEV_RDM_STRICT) AIUI these aren't individual flags, but kind of an enumeration. I.e. you should keep the original definitions and add - as suggested by George - a mask (two bits wide right now). Okay but George also thought NO_RDM may be pointless since we can just ignore this flag field simply for DT device, and he also thought one bit may be fine enough to cover two cases, strict and relaxed. So maybe finally, here is, #define XEN_DOMCTL_DEV_RDM_RELAXED 1 #define XEN_DOMCTL_DEV_RDM_FLAGS_MASK (0x1) Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 5/6] xen: arm: Import of_bus PCI entry from Linux (as a dt_bus entry)
Hi Ian, On 03/07/15 16:56, Ian Campbell wrote: This provides specific handlers for the PCI bus relating to matching and translating. It's mostly similar to the defaults but includes some additional error checks and other PCI specific bits. There are some subtle differences in how the generic code vs. the pci specific code here will handle buggy DTs (i.e. #*-cells which are not as required by the pci bindings). This will mean we tolerate such device trees better. I say buggy, but actually it's not clear to me from reading PCI Bus Binding to Open Firmware that when the device_type is pci that e.g. the text says The value of #address-cells for PCI Bus Nodes is 3. and not A PCI Bus Node must contain a #address-cells property containing 3, iow the #address-cells might validly be implicit rather than an actual property. Maybe that interpretation is bogus, but with this patch we are are able to cope with DTs written by people who do read it like that. It also gets us the ability to parse the flags (cacheability), although at the moment we only check them for validity rather than use them. Functions/types renamed and reindented (because apparently we do that for these). Needs a selection of IORESOURCE_* defines, which I've taken from Linux and have included locally for now until we figure out where else they might be needed. Signed-off-by: Ian Campbell ian.campb...@citrix.com Reviewed-by: Julien Grall julien.gr...@citrix.com Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 0/6] xen: arm: Parse PCI DT nodes' ranges and interrupt-map
Hi Ian, On 03/07/15 16:55, Ian Campbell wrote: This series adds parsing of the DT ranges and interrupt-map properties for PCI devices, these contain the MMIOs and IRQs used by children on the bus. This replaces the specific mapping stuff on xgene. This is a quick respin based on Julien's comments on v4 which were missed in v5. I added my reviewed-by on all the patch and had 3 minors comments on #4. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] BUG: unable to handle kernel NULL pointer in __netdev_pick_tx()
On 07/06/2015 06:41 PM, Eric Dumazet wrote: On Mon, 2015-07-06 at 16:26 +0800, Bob Liu wrote: Hi, I tried to run the latest kernel v4.2-rc1, but often got below panic during system boot. [ 42.118983] BUG: unable to handle kernel paging request at 003f [ 42.119008] IP: [8161cfd0] __netdev_pick_tx+0x70/0x120 [ 42.119023] PGD 0 [ 42.119026] Oops: [#1] PREEMPT SMP [ 42.119031] Modules linked in: bridge stp llc iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp pcspkr crc32_pclmul crc32c_intel ghash_clmulni_intel ixgbe ptp pps_core cdc_ether usbnet mii mdio sb_edac dca edac_core wmi i2c_i801 tpm_tis tpm lpc_ich mfd_core ipmi_si ipmi_msghandler shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput usb_storage mgag200 i2c_algo_bit drm_kms_helper ttm drm i2c_core nvme mpt2sas raid_class scsi_transport_sas [ 42.119073] CPU: 12 PID: 0 Comm: swapper/12 Not tainted 4.2.0-rc1 #80 [ 42.119077] Hardware name: Oracle Corporation SUN SERVER X4-4/ASSY,MB WITH TRAY, BIOS 24030400 08/22/2014 [ 42.119081] task: 880300b84000 ti: 880300b9 task.ti: 880300b9 [ 42.119085] RIP: e030:[8161cfd0] [8161cfd0] __netdev_pick_tx+0x70/0x120 [ 42.119091] RSP: e02b:880306d03868 EFLAGS: 00010206 [ 42.119093] RAX: 8802f676b6b0 RBX: 003f RCX: 8161cf60 [ 42.119097] RDX: 001c RSI: 8802fe24c900 RDI: 8802f96c [ 42.119100] RBP: 880306d038a8 R08: 00023240 R09: 8160fb1c [ 42.119104] R10: R11: R12: 8802fe24c900 [ 42.119107] R13: R14: R15: 8802f96c [ 42.119121] FS: () GS:880306d0() knlGS: [ 42.119124] CS: e033 DS: 002b ES: 002b CR0: 80050033 [ 42.119127] CR2: 003f CR3: 01c1c000 CR4: 00042660 [ 42.119130] Stack: [ 42.119132] 81d63850 8802f63040a0 880306d03888 8802fe24c900 [ 42.119137] 000e 8802f96c 8802fe24c400 [ 42.119141] 880306d038e8 a028bea4 8189cfe0 81d1b900 [ 42.119146] Call Trace: [ 42.119149] IRQ [ 42.119160] [a028bea4] ixgbe_select_queue+0xc4/0x150 [ixgbe] [ 42.119167] [816240ee] netdev_pick_tx+0x5e/0xf0 [ 42.119170] [81624210] __dev_queue_xmit+0x90/0x560 [ 42.119174] [816246f3] dev_queue_xmit_sk+0x13/0x20 [ 42.119181] [a02d2b3a] br_dev_queue_push_xmit+0x4a/0x80 [bridge] [ 42.119186] [a02d2cca] br_forward_finish+0x2a/0x80 [bridge] [ 42.119191] [a02d2da8] __br_forward+0x88/0x110 [bridge] [ 42.119198] [8160e18e] ? __skb_clone+0x2e/0x140 [ 42.119202] [8160fb33] ? skb_clone+0x63/0xa0 [ 42.119206] [a02d2d20] ? br_forward_finish+0x80/0x80 [bridge] [ 42.119211] [a02d2ac7] deliver_clone+0x37/0x60 [bridge] [ 42.119215] [a02d2c38] br_flood+0xc8/0x130 [bridge] [ 42.119220] [a02d2d20] ? br_forward_finish+0x80/0x80 [bridge] [ 42.119255] [a02d3229] br_flood_forward+0x19/0x20 [bridge] [ 42.119260] [a02d4188] br_handle_frame_finish+0x258/0x590 [bridge] [ 42.119266] [8172b5d0] ? get_partial_node.isra.63+0x1b7/0x1d4 [ 42.119272] [a02d4606] br_handle_frame+0x146/0x270 [bridge] [ 42.119277] [8168ed39] ? udp_gro_receive+0x129/0x150 [ 42.119281] [81621836] __netif_receive_skb_core+0x1d6/0xa20 [ 42.119286] [81697a1d] ? inet_gro_receive+0x9d/0x230 [ 42.119290] [81622098] __netif_receive_skb+0x18/0x60 [ 42.119294] [81622113] netif_receive_skb_internal+0x33/0xb0 [ 42.119297] [81622d3f] napi_gro_receive+0xbf/0x110 [ 42.119303] [a028def0] ixgbe_clean_rx_irq+0x490/0x9e0 [ixgbe] [ 42.119308] [a028f0c0] ixgbe_poll+0x420/0x790 [ixgbe] [ 42.119312] [8162255d] net_rx_action+0x15d/0x340 [ 42.119321] [81095426] __do_softirq+0xe6/0x2f0 [ 42.119324] [81095904] irq_exit+0xf4/0x100 [ 42.119333] [814275c9] xen_evtchn_do_upcall+0x39/0x50 [ 42.119340] [817367de] xen_do_hypervisor_callback+0x1e/0x30 [ 42.119343] EOI [ 42.119348] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 42.119351] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 42.119356] [8100bbf0] ? xen_safe_halt+0x10/0x20 [ 42.119362] [8101feab] ? default_idle+0x1b/0xf0 [ 42.119365] [8102062f] ? arch_cpu_idle+0xf/0x20 [ 42.119370] [810d273b] ? default_idle_call+0x3b/0x50 [ 42.119374] [810d2a7f] ? cpu_startup_entry+0x2bf/0x350 [ 42.119379] [8101290a] ? cpu_bringup_and_idle+0x2a/0x40 [ 42.119382] Code: 8b 87 e8 03 00 00 48 85 c0 0f 84 af 00 00 00 41 8b 94
Re: [Xen-devel] [PATCH v3 11/13] x86/altp2m: define and implement alternate p2m HVMOP types.
On 01/07/15 19:09, Ed White wrote:
Signed-off-by: Ed White edmund.h.wh...@intel.com
I am still very much unconvinced by the argument against having a single
HVMOP_altp2m and a set of subops. do_domctl() and do_sysctl() are
examples of a subop style hypercall with different XSM settings for
different subops.
Furthermore, factoring out a do_altp2m_op() handler would allow things
like the hvm_altp2m_supported() check to be made common. Factoring
further to having a named common header of a subop and a domid at the
head of every subop structure would allow all the domain rcu locking to
become common outside of the subop switch.
In addition,
+case HVMOP_altp2m_vcpu_enable_notify:
+{
+struct domain *curr_d = current-domain;
+struct vcpu *curr = current;
+struct xen_hvm_altp2m_vcpu_enable_notify a;
+p2m_type_t p2mt;
+
+if ( copy_from_guest(a, arg, 1) )
+return -EFAULT;
+
+if ( !is_hvm_domain(curr_d) || !hvm_altp2m_supported() ||
+ !curr_d-arch.altp2m_active ||
+ gfn_x(vcpu_altp2m(curr).veinfo_gfn) != INVALID_GFN)
Brackets around the boolean operation on this line, and a space inside
the final bracket.
+/* Notify that a page of memory is to have specific access types */
+#define HVMOP_altp2m_set_mem_access 30
+struct xen_hvm_altp2m_set_mem_access {
+/* Domain to be updated. */
+domid_t domid;
+/* view */
+uint16_t view;
+/* Memory type */
+uint16_t hvmmem_access; /* xenmem_access_t */
Explicit padding bytes here please.
+/* gfn */
+uint64_t gfn;
+};
+typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
+
+/* Change a p2m entry to have a different gfn-mfn mapping */
+#define HVMOP_altp2m_change_gfn 31
+struct xen_hvm_altp2m_change_gfn {
+/* Domain to be updated. */
+domid_t domid;
+/* view */
+uint16_t view;
And here.
~Andrew
+/* old gfn */
+uint64_t old_gfn;
+/* new gfn, INVALID_GFN (~0UL) means revert */
+uint64_t new_gfn;
+};
+typedef struct xen_hvm_altp2m_change_gfn xen_hvm_altp2m_change_gfn_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_change_gfn_t);
+
#endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
/*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 2/3] xen/vm_event: Support for guest-requested events
On 30.06.15 at 16:23, rcojoc...@bitdefender.com wrote: On 06/26/2015 10:02 AM, Jan Beulich wrote: On 15.06.15 at 11:03, rcojoc...@bitdefender.com wrote: Added support for a new class of vm_events: VM_EVENT_REASON_REQUEST, sent via HVMOP_request_vm_event. The guest can request that a generic vm_event (containing only the vm_event-filled guest registers as information) be sent to userspace by setting up the correct registers and doing a VMCALL. For example, for a 64-bit guest, this means: EAX = 34 (hvmop), EBX = 24 (HVMOP_request_vm_event). I suppose you mean a 32-bit guest here? Also I'm not sure it's a good idea to explicitly define a guest exposed hypercall to omit one of the arguments normally required for it (the interface structure pointer): Should there ever be a reason to allow the guest to control further aspects of the operation by passing a structure, you'd then have to define a new sub-op instead of being able to re-use the current one. I.e. I'd strongly recommend requiring NULL to be passed here, and checking this in the implementation of the handler. Would something like this do? 6391 case HVMOP_guest_request_vm_event: 6392 if ( !guest_handle_is_null(arg) ) 6393 rc = -EINVAL; 6394 else 6395 hvm_event_guest_request(); 6396 break; Yes, except that I'd recommend inverting the condition and swapping the branches. --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -6373,6 +6373,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) break; } +case HVMOP_request_vm_event: +hvm_event_requested(); +break; No XSM check here or in the handler? Shouldn't the admin controlling guest properties from the host perspective be permitted control here? Cc-ing Daniel for his input ... Thinking more about this, the goal here is to be able to monitor non-privileged guests from a privileged domain. Being able to subscribe to these events is subject to XSM checks (so an application in dom0 would be able to receive them), but if XSM checks are needed for the guest as well, then, at least for the purpose the code is intended for now, the default would need to be to allow this to happen. Daniel? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [ovmf test] 59044: trouble: blocked/broken/fail/pass
On Mon, 2015-07-06 at 11:30 +0100, Ian Jackson wrote:
Ian Campbell writes (Re: [Xen-devel] [ovmf test] 59044: trouble:
blocked/broken/fail/pass):
Seems to be Osstest/JobDB/Executive.pm line 137:
die Dumper($ho). ? if $ho-{SharedOthers} !
$ho-{SharedReady};
So another sharing related glitch, like the linux-3.18 flight 59041 I
just pointedy ou at (which was on armhf though).
Any ideas?
This has the same root cause as the other mystery failure.
I hadn't appreciated that the checks in the host sharing machinery
would mean that if a job allocates a share in a host, later steps in
that job will fail if (in a subroutine of `selecthost') if they are
run using a different version of osstest. Having had the chance to
think about it, I think this is probably for the best.
I agree.
It does mean that in-place updates like I did will have a tendency to
break ongoing builds.
They are a pretty rare event, and I suppose having realised this aspect
they might become rarer still..
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6
Hi, On 03/07/15 21:42, Florian Westphal wrote: Julien Grall julien.gr...@citrix.com wrote: The commit efb6de9b4ba0092b2c55f6a52d16294a8a698edd netfilter: bridge: forward IPv6 fragmented packets introduced a new function br_validate_ipv6 which take a reference on the inet6 device. Although, the reference is not released at the end. This will result to the impossibility to destroy any netdevice using ipv6 and bridge. Spotted while trying to destroy a Xen guest on the upstream Linux: unregister_netdevice: waiting for vif1.0 to become free. Usage count = 1 Ugh :-/ I think it makes more sense to use __in6_dev_get() instead which doesn't take a reference. __in6_dev_get requires to hold rcu_read_lock or RTNL. My knowledge on this code is very limited. Are we sure that one this lock is hold? At first glance, I wasn't able to find one. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] BUG: unable to handle kernel NULL pointer in __netdev_pick_tx()
On Mon, 2015-07-06 at 16:26 +0800, Bob Liu wrote: Hi, I tried to run the latest kernel v4.2-rc1, but often got below panic during system boot. [ 42.118983] BUG: unable to handle kernel paging request at 003f [ 42.119008] IP: [8161cfd0] __netdev_pick_tx+0x70/0x120 [ 42.119023] PGD 0 [ 42.119026] Oops: [#1] PREEMPT SMP [ 42.119031] Modules linked in: bridge stp llc iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp pcspkr crc32_pclmul crc32c_intel ghash_clmulni_intel ixgbe ptp pps_core cdc_ether usbnet mii mdio sb_edac dca edac_core wmi i2c_i801 tpm_tis tpm lpc_ich mfd_core ipmi_si ipmi_msghandler shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput usb_storage mgag200 i2c_algo_bit drm_kms_helper ttm drm i2c_core nvme mpt2sas raid_class scsi_transport_sas [ 42.119073] CPU: 12 PID: 0 Comm: swapper/12 Not tainted 4.2.0-rc1 #80 [ 42.119077] Hardware name: Oracle Corporation SUN SERVER X4-4/ASSY,MB WITH TRAY, BIOS 24030400 08/22/2014 [ 42.119081] task: 880300b84000 ti: 880300b9 task.ti: 880300b9 [ 42.119085] RIP: e030:[8161cfd0] [8161cfd0] __netdev_pick_tx+0x70/0x120 [ 42.119091] RSP: e02b:880306d03868 EFLAGS: 00010206 [ 42.119093] RAX: 8802f676b6b0 RBX: 003f RCX: 8161cf60 [ 42.119097] RDX: 001c RSI: 8802fe24c900 RDI: 8802f96c [ 42.119100] RBP: 880306d038a8 R08: 00023240 R09: 8160fb1c [ 42.119104] R10: R11: R12: 8802fe24c900 [ 42.119107] R13: R14: R15: 8802f96c [ 42.119121] FS: () GS:880306d0() knlGS: [ 42.119124] CS: e033 DS: 002b ES: 002b CR0: 80050033 [ 42.119127] CR2: 003f CR3: 01c1c000 CR4: 00042660 [ 42.119130] Stack: [ 42.119132] 81d63850 8802f63040a0 880306d03888 8802fe24c900 [ 42.119137] 000e 8802f96c 8802fe24c400 [ 42.119141] 880306d038e8 a028bea4 8189cfe0 81d1b900 [ 42.119146] Call Trace: [ 42.119149] IRQ [ 42.119160] [a028bea4] ixgbe_select_queue+0xc4/0x150 [ixgbe] [ 42.119167] [816240ee] netdev_pick_tx+0x5e/0xf0 [ 42.119170] [81624210] __dev_queue_xmit+0x90/0x560 [ 42.119174] [816246f3] dev_queue_xmit_sk+0x13/0x20 [ 42.119181] [a02d2b3a] br_dev_queue_push_xmit+0x4a/0x80 [bridge] [ 42.119186] [a02d2cca] br_forward_finish+0x2a/0x80 [bridge] [ 42.119191] [a02d2da8] __br_forward+0x88/0x110 [bridge] [ 42.119198] [8160e18e] ? __skb_clone+0x2e/0x140 [ 42.119202] [8160fb33] ? skb_clone+0x63/0xa0 [ 42.119206] [a02d2d20] ? br_forward_finish+0x80/0x80 [bridge] [ 42.119211] [a02d2ac7] deliver_clone+0x37/0x60 [bridge] [ 42.119215] [a02d2c38] br_flood+0xc8/0x130 [bridge] [ 42.119220] [a02d2d20] ? br_forward_finish+0x80/0x80 [bridge] [ 42.119255] [a02d3229] br_flood_forward+0x19/0x20 [bridge] [ 42.119260] [a02d4188] br_handle_frame_finish+0x258/0x590 [bridge] [ 42.119266] [8172b5d0] ? get_partial_node.isra.63+0x1b7/0x1d4 [ 42.119272] [a02d4606] br_handle_frame+0x146/0x270 [bridge] [ 42.119277] [8168ed39] ? udp_gro_receive+0x129/0x150 [ 42.119281] [81621836] __netif_receive_skb_core+0x1d6/0xa20 [ 42.119286] [81697a1d] ? inet_gro_receive+0x9d/0x230 [ 42.119290] [81622098] __netif_receive_skb+0x18/0x60 [ 42.119294] [81622113] netif_receive_skb_internal+0x33/0xb0 [ 42.119297] [81622d3f] napi_gro_receive+0xbf/0x110 [ 42.119303] [a028def0] ixgbe_clean_rx_irq+0x490/0x9e0 [ixgbe] [ 42.119308] [a028f0c0] ixgbe_poll+0x420/0x790 [ixgbe] [ 42.119312] [8162255d] net_rx_action+0x15d/0x340 [ 42.119321] [81095426] __do_softirq+0xe6/0x2f0 [ 42.119324] [81095904] irq_exit+0xf4/0x100 [ 42.119333] [814275c9] xen_evtchn_do_upcall+0x39/0x50 [ 42.119340] [817367de] xen_do_hypervisor_callback+0x1e/0x30 [ 42.119343] EOI [ 42.119348] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 42.119351] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 42.119356] [8100bbf0] ? xen_safe_halt+0x10/0x20 [ 42.119362] [8101feab] ? default_idle+0x1b/0xf0 [ 42.119365] [8102062f] ? arch_cpu_idle+0xf/0x20 [ 42.119370] [810d273b] ? default_idle_call+0x3b/0x50 [ 42.119374] [810d2a7f] ? cpu_startup_entry+0x2bf/0x350 [ 42.119379] [8101290a] ? cpu_bringup_and_idle+0x2a/0x40 [ 42.119382] Code: 8b 87 e8 03 00 00 48 85 c0 0f 84 af 00 00 00 41 8b 94 24 ac 00 00 00 83 ea 01 48 8d 44 d0 10 48 8b 18
Re: [Xen-devel] [PATCH v6 4/6] xen: arm: map child MMIO and IRQs to dom0 for PCI bus DT nodes.
Hi Ian,
Some minor comments:
On 03/07/15 16:56, Ian Campbell wrote:
+static int map_range_to_domain(const struct dt_device_node *dev,
+ u64 addr, u64 len,
+ void *data)
+{
+struct domain *d = data;
+bool_t need_mapping = !dt_device_for_passthrough(dev);
+int res;
+
+res = iomem_permit_access(d, paddr_to_pfn(addr PAGE_MASK),
the PAGE_MASK is not useful here.
+ paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
+if ( res )
+{
+printk(XENLOG_ERR Unable to permit to dom%d access to
+0x%PRIx64 - 0x%PRIx64\n,
+ d-domain_id,
+ addr PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
+return res;
+}
+
+if ( need_mapping )
+{
+res = map_mmio_regions(d,
+ paddr_to_pfn(addr PAGE_MASK),
ditto
+ DIV_ROUND_UP(len, PAGE_SIZE),
+ paddr_to_pfn(addr PAGE_MASK));
ditto
Other than that:
Reviewed-by: Julien Grall julien.gr...@citrix.com
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Performance problem about address translation
Hi, nbsp;nbsp;nbsp; For I want to translate the virtual address in HVM DomU to virtual address in Xen. But when I use the function paging_gva_to_gfn and get_gfn, I can feel the performance down quickly, the machine become very hot and then I have to force the machine shutting down. The codes I used as below: nbsp;nbsp;nbsp; uint32_t pfec = PFEC_page_present; nbsp;nbsp;nbsp; unsigned long gfn; nbsp;nbsp;nbsp; unsigned long mfn; nbsp;nbsp;nbsp; unsigned long virtaddr; nbsp;nbsp;nbsp; struct vcpu *vcpu = current; nbsp;nbsp;nbsp; struct domain *d = vcpu-gt;domain; nbsp;nbsp;nbsp; gfn = paging_gva_to_gfn(current, 0xc029, amp;pfec); nbsp;nbsp;nbsp; mfn = get_gfn(d, gfn, amp;t); nbsp;nbsp;nbsp; virtaddr = map_domain_page(mfn_x(mfn)); I also use the dbg_hvm_va2mfn function in debug.c, performance problem still present. I don#39;t know why, could someone give me some advices. Thanks for any advice and best regards! xinyue ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass
oops, that's not the button I wanted On Mon, 2015-07-06 at 09:27 +0100, Ian Campbell wrote: On Fri, 2015-07-03 at 22:21 +, osstest service owner wrote: build-armhf-xsm 4 host-build-prep fail REGR. vs. 58581 A strange one I think. As I was going to say... http://logs.test-lab.xenproject.org/osstest/logs/59041/build-armhf-xsm/4.ts-xen-build-prep.log ends with: resource host arndale-metrocentre shared build-wheezy-armhf 3c464fbf8a05b24f4afb7e58bcf4ae77fbb7ad0c not build-wheezy-armhf 8600096139e58a283eb2c23c769673d451487e1c at Osstest/Executive.pm line 840. I'm not sure how to interpret that... Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass
On Fri, 2015-07-03 at 22:21 +, osstest service owner wrote: build-armhf-xsm 4 host-build-prep fail REGR. vs. 58581 A strange one I think. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass
On Fri, 2015-07-03 at 22:21 +, osstest service owner wrote: flight 59041 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/59041/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 58581 Not really sure who is on the hook for pvh fails these days, copying some likely suspects + x86 maintainers. Looks like the guest is triple faulting. http://logs.test-lab.xenproject.org/osstest/logs/59041/test-amd64-amd64-xl-pvh-intel/info.html http://logs.test-lab.xenproject.org/osstest/logs/59041/test-amd64-amd64-xl-pvh-intel/11.ts-guest-start.log 2015-07-03 19:50:21 Z executing ssh ... root@172.16.144.38 xl list 2015-07-03 19:50:21 Z guest debian.guest.osstest not present on this host debian.guest.osstest not running at ./ts-guest-start line 33. http://logs.test-lab.xenproject.org/osstest/logs/59041/test-amd64-amd64-xl-pvh-intel/serial-huxelrebe0.log Jul 3 19:50:21.557035 (d1) mapping kernel into physical memory Jul 3 19:50:21.661049 (d1) about to get started... Jul 3 19:50:21.661065 (d1) [0.00] Initializing cgroup subsys cpuset Jul 3 19:50:21.669059 (d1) [0.00] Initializing cgroup subsys cpu Jul 3 19:50:21.669078 (d1) [0.00] Initializing cgroup subsys cpuacct Jul 3 19:50:21.677045 (d1) [0.00] Linux version 3.18.17 (osstest@nocera0) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Fri Jul 3 08:12:11 UTC 2015 Jul 3 19:50:21.685259 (d1) Jul 3 19:50:21.685271 (d1) [0.00] Command line: root=/dev/xvda2 ro console=hvc0 earlyprintk=xen Jul 3 19:50:21.693061 (d1) [0.00] ACPI in unprivileged domain disabled Jul 3 19:50:21.701043 (d1) [0.00] e820: BIOS-provided physical RAM map: Jul 3 19:50:21.709048 (d1) [0.00] Xen: [mem 0x-0x1fff] usable Jul 3 19:50:21.709072 (d1) [0.00] bootconsole [xenboot0] enabled Jul 3 19:50:21.717050 (d1) [0.00] NX (Execute Disable) protection: active Jul 3 19:50:21.725042 (d1) [0.00] DMI not present or invalid. Jul 3 19:50:21.725062 (d1) [0.00] e820: last_pfn = 0x2 max_arch_pfn = 0x4 Jul 3 19:50:21.733047 (d1) [0.00] Scanning 1 areas for low memory corruption Jul 3 19:50:21.741040 (d1) [0.00] Using GB pages for direct mapping Jul 3 19:50:21.741060 (d1) [0.00] init_memory_mapping: [mem 0x-0x000f] Jul 3 19:50:21.749053 (XEN) d1v0 Triple fault - invoking HVM shutdown action 0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Performance problem about address translation
On 06/07/2015 08:22, xinyue wrote: Hi, For I want to translate the virtual address in HVM DomU to virtual address in Xen. But when I use the function paging_gva_to_gfn and get_gfn, I can feel the performance down quickly, the machine become very hot and then I have to force the machine shutting down. Your machine clearly isn't cooled sufficiently, which is the first problem. The codes I used as below: uint32_t pfec = PFEC_page_present; unsigned long gfn; unsigned long mfn; unsigned long virtaddr; struct vcpu *vcpu = current; struct domain *d = vcpu-domain; gfn = paging_gva_to_gfn(current, 0xc029, pfec); mfn = get_gfn(d, gfn, t); virtaddr = map_domain_page(mfn_x(mfn)); I also use the dbg_hvm_va2mfn function in debug.c, performance problem still present. Walking pagetables in software is slow. There is no getting around this. Your performance problems will be caused by performing the operation far too often. You should find a way to reduce this. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Performance problem about address translation
On 06/07/2015 08:58, xinyue wrote: 在 2015-07-06, Mon, 15:44:53 ,Andrew Cooper 写到： On 06/07/2015 08:22, xinyue wrote: Hi, For I want to translate the virtual address in HVM DomU to virtual address in Xen. But when I use the function paging_gva_to_gfn and get_gfn, I can feel the performance down quickly, the machine become very hot and then I have to force the machine shutting down. Your machine clearly isn't cooled sufficiently, which is the first problem. The codes I used as below: uint32_t pfec = PFEC_page_present; unsigned long gfn; unsigned long mfn; unsigned long virtaddr; struct vcpu *vcpu = current; struct domain *d = vcpu-domain; gfn = paging_gva_to_gfn(current, 0xc029, pfec); mfn = get_gfn(d, gfn, t); virtaddr = map_domain_page(mfn_x(mfn)); I also use the dbg_hvm_va2mfn function in debug.c, performance problem still present. Walking pagetables in software is slow. There is no getting around this. Your performance problems will be caused by performing the operation far too often. You should find a way to reduce this. Thanks very much, I think I only do this for just once. And after the thanslation is done, the performance is not turn to normal. Does that mean that if I wait long enough it will recovery? It almost certainly means you are not doing it just once like you suppose. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Mapping Dom0 page in hypervisor from domctl
On Thu, 2015-07-02 at 08:14 -0400, Bread Cutter wrote: Any insight into what I'm doing wrong would be appreciated! I'm afraid I don't have any, but perhaps you want to be looking into either share_xen_page_with_guest or share_xen_page_with_privileged_guests and either using them directly or comparing with what you are doing? Or perhaps hvm_map_ioreq_page is more similar to what you are trying? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] BUG: unable to handle kernel NULL pointer in __netdev_pick_tx()
Hi, I tried to run the latest kernel v4.2-rc1, but often got below panic during system boot. [ 42.118983] BUG: unable to handle kernel paging request at 003f [ 42.119008] IP: [8161cfd0] __netdev_pick_tx+0x70/0x120 [ 42.119023] PGD 0 [ 42.119026] Oops: [#1] PREEMPT SMP [ 42.119031] Modules linked in: bridge stp llc iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp pcspkr crc32_pclmul crc32c_intel ghash_clmulni_intel ixgbe ptp pps_core cdc_ether usbnet mii mdio sb_edac dca edac_core wmi i2c_i801 tpm_tis tpm lpc_ich mfd_core ipmi_si ipmi_msghandler shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput usb_storage mgag200 i2c_algo_bit drm_kms_helper ttm drm i2c_core nvme mpt2sas raid_class scsi_transport_sas [ 42.119073] CPU: 12 PID: 0 Comm: swapper/12 Not tainted 4.2.0-rc1 #80 [ 42.119077] Hardware name: Oracle Corporation SUN SERVER X4-4/ASSY,MB WITH TRAY, BIOS 24030400 08/22/2014 [ 42.119081] task: 880300b84000 ti: 880300b9 task.ti: 880300b9 [ 42.119085] RIP: e030:[8161cfd0] [8161cfd0] __netdev_pick_tx+0x70/0x120 [ 42.119091] RSP: e02b:880306d03868 EFLAGS: 00010206 [ 42.119093] RAX: 8802f676b6b0 RBX: 003f RCX: 8161cf60 [ 42.119097] RDX: 001c RSI: 8802fe24c900 RDI: 8802f96c [ 42.119100] RBP: 880306d038a8 R08: 00023240 R09: 8160fb1c [ 42.119104] R10: R11: R12: 8802fe24c900 [ 42.119107] R13: R14: R15: 8802f96c [ 42.119121] FS: () GS:880306d0() knlGS: [ 42.119124] CS: e033 DS: 002b ES: 002b CR0: 80050033 [ 42.119127] CR2: 003f CR3: 01c1c000 CR4: 00042660 [ 42.119130] Stack: [ 42.119132] 81d63850 8802f63040a0 880306d03888 8802fe24c900 [ 42.119137] 000e 8802f96c 8802fe24c400 [ 42.119141] 880306d038e8 a028bea4 8189cfe0 81d1b900 [ 42.119146] Call Trace: [ 42.119149] IRQ [ 42.119160] [a028bea4] ixgbe_select_queue+0xc4/0x150 [ixgbe] [ 42.119167] [816240ee] netdev_pick_tx+0x5e/0xf0 [ 42.119170] [81624210] __dev_queue_xmit+0x90/0x560 [ 42.119174] [816246f3] dev_queue_xmit_sk+0x13/0x20 [ 42.119181] [a02d2b3a] br_dev_queue_push_xmit+0x4a/0x80 [bridge] [ 42.119186] [a02d2cca] br_forward_finish+0x2a/0x80 [bridge] [ 42.119191] [a02d2da8] __br_forward+0x88/0x110 [bridge] [ 42.119198] [8160e18e] ? __skb_clone+0x2e/0x140 [ 42.119202] [8160fb33] ? skb_clone+0x63/0xa0 [ 42.119206] [a02d2d20] ? br_forward_finish+0x80/0x80 [bridge] [ 42.119211] [a02d2ac7] deliver_clone+0x37/0x60 [bridge] [ 42.119215] [a02d2c38] br_flood+0xc8/0x130 [bridge] [ 42.119220] [a02d2d20] ? br_forward_finish+0x80/0x80 [bridge] [ 42.119255] [a02d3229] br_flood_forward+0x19/0x20 [bridge] [ 42.119260] [a02d4188] br_handle_frame_finish+0x258/0x590 [bridge] [ 42.119266] [8172b5d0] ? get_partial_node.isra.63+0x1b7/0x1d4 [ 42.119272] [a02d4606] br_handle_frame+0x146/0x270 [bridge] [ 42.119277] [8168ed39] ? udp_gro_receive+0x129/0x150 [ 42.119281] [81621836] __netif_receive_skb_core+0x1d6/0xa20 [ 42.119286] [81697a1d] ? inet_gro_receive+0x9d/0x230 [ 42.119290] [81622098] __netif_receive_skb+0x18/0x60 [ 42.119294] [81622113] netif_receive_skb_internal+0x33/0xb0 [ 42.119297] [81622d3f] napi_gro_receive+0xbf/0x110 [ 42.119303] [a028def0] ixgbe_clean_rx_irq+0x490/0x9e0 [ixgbe] [ 42.119308] [a028f0c0] ixgbe_poll+0x420/0x790 [ixgbe] [ 42.119312] [8162255d] net_rx_action+0x15d/0x340 [ 42.119321] [81095426] __do_softirq+0xe6/0x2f0 [ 42.119324] [81095904] irq_exit+0xf4/0x100 [ 42.119333] [814275c9] xen_evtchn_do_upcall+0x39/0x50 [ 42.119340] [817367de] xen_do_hypervisor_callback+0x1e/0x30 [ 42.119343] EOI [ 42.119348] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 42.119351] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 42.119356] [8100bbf0] ? xen_safe_halt+0x10/0x20 [ 42.119362] [8101feab] ? default_idle+0x1b/0xf0 [ 42.119365] [8102062f] ? arch_cpu_idle+0xf/0x20 [ 42.119370] [810d273b] ? default_idle_call+0x3b/0x50 [ 42.119374] [810d2a7f] ? cpu_startup_entry+0x2bf/0x350 [ 42.119379] [8101290a] ? cpu_bringup_and_idle+0x2a/0x40 [ 42.119382] Code: 8b 87 e8 03 00 00 48 85 c0 0f 84 af 00 00 00 41 8b 94 24 ac 00 00 00 83 ea 01 48 8d 44 d0 10 48 8b 18 48 85 db 0f 84 93 00 00 00 8b 03 83 f8 01 74 6b 41 f6 84 24 91 00 00 00 30 74 66 41 8b 94 [ 42.119414] RIP [8161cfd0]
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Sun, 2015-07-05 at 11:25 +0530, Manish Jaggi wrote:
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci device's BAR
regions.
These are defined in arch-arm.h
/* For 32bit */
GUEST_MMIO_HOLE0_BASE, GUEST_MMIO_HOLE0_SIZE
/* For 64bit */
GUEST_MMIO_HOLE1_BASE , GUEST_MMIO_HOLE1_SIZE
The memory layout for 32bit and 64bit are exactly the same. Why do you
need to differ here?
I think Ian has already replied. I will change the name of macro
4.2 New entries in xenstore for device BARs
toolkit also updates the xenstore information for the device
(virtualbar:physical bar).
This information is read by xenpciback and returned to the pcifront
driver configuration
space accesses.
Can you details what do you plan to put in xenstore and how?
It is implementation . But I plan to put under domU / device / heirarchy
Actually, xenstore is an API of sorts which needs to be maintained going
forward (since front and backend can evolve separately, so it does need
some level of design and documentation.
What about the expansion ROM?
Do you want to put some restriction on not using expansion ROM as a
passthrough device.
expansion ROM as a passthrough device doesn't make sense to me,
passthrough devices may _have_ an expansion ROM.
The expansion ROM is just another BAR. I don't know how pcifront/back
deal with those today on PV x86, but I see no reason for ARM to deviate.
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
u32 s;
u8 b;
u8 df;
u16 res;
} sbdf_t;
struct physdev_map_sbdf {
int domain_id;
sbdf_tsbdf;
sbdf_tgsbdf;
};
Each domain has a pdev list, which contains the list of all pci devices.
The
pdev structure already has a sbdf information. The arch_pci_dev is
updated to
contain the gsbdf information. (gs- guest segment id)
Whenever there is trap from guest or an interrupt has to be injected,
the pdev
list is iterated to find the gsbdf.
Can you give more background for this section? i.e:
- Why do you need this?
- How xen will translate the gbdf to a vDeviceID?
In the context of the hypercall processing.
- Who will call this hypercall?
- Why not setting the gsbdf when the device is assigned?
Can the maintainer of the pciback suggest an alternate.
That's not me, but I don't think this belongs here, I think it can be
done from the toolstack. If you think not then please explain what
information the toolstack doesn't have in its possession which prevents
this mapping from being done there.
The answer to your question is that I have only found a place to issue
the hypercall where
all the information can be located is the function
__xen_pcibk_add_pci_dev
drivers/xen/xen-pciback/vpci.c
unlock:
...
kfree(dev_entry);
+ /*Issue Hypercall here */
+#ifdef CONFIG_ARM64
+ map_sbdf.domain_id = pdev-xdev-otherend_id;
+ map_sbdf.sbdf_s = dev-bus-domain_nr;
+ map_sbdf.sbdf_b = dev-bus-number;
+ map_sbdf.sbdf_d = dev-devfn3;
+ map_sbdf.sbdf_f = dev-devfn 0x7;
+ map_sbdf.gsbdf_s = 0;
+ map_sbdf.gsbdf_b = 0;
+ map_sbdf.gsbdf_d = slot;
+ map_sbdf.gsbdf_f = dev-devfn 0x7;
+ pr_info(## sbdf = %d:%d:%d.%d g_sbdf %d:%d:%d.%d \
+ domain_id=%d ##\r\n,
+ map_sbdf.sbdf_s,
+ map_sbdf.sbdf_b,
+ map_sbdf.sbdf_d,
+ map_sbdf.sbdf_f,
+ map_sbdf.gsbdf_s,
+ map_sbdf.gsbdf_b,
+ map_sbdf.gsbdf_d,
+ map_sbdf.gsbdf_f,
+ map_sbdf.domain_id);
+
+ err = HYPERVISOR_physdev_op(PHYSDEVOP_map_sbdf, map_sbdf);
+ if (err)
+ printk(KERN_ERR Xen Error PHYSDEVOP_map_sbdf);
+#endif
---
Regards,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6
Julien Grall julien.gr...@citrix.com wrote: On 03/07/15 21:42, Florian Westphal wrote: I think it makes more sense to use __in6_dev_get() instead which doesn't take a reference. __in6_dev_get requires to hold rcu_read_lock or RTNL. My knowledge on this code is very limited. Are we sure that one this lock is hold? At first glance, I wasn't able to find one. All netfilter hooks are rcu_read_locked via nf_hook_slow(). BTW, netfilter patches should be sent to netfilter-de...@vger.kernel.org. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m
At 10:50 +0100 on 06 Jul (1436179849), Jan Beulich wrote: On 01.07.15 at 20:09, edmund.h.wh...@intel.com wrote: Changes since v2: Addressed all v2 feedback *except*: In patch 5, the per-domain EPTP list page is still allocated from the Xen heap. If allocated from the domain heap Xen panics - IIRC on Haswell hardware when walking the EPTP list during exit processing in patch 6. With this little detail I can't take this as a valid reason not to make this change. Also - weren't we aiming at getting the page from the HAP pool of the domain anyway? This one keeps coming up again, and I think has not been explained very clearly. For me, the important detail is that this is basically an extension of the VMCx structures, and not part of any per-vcpu/per-p2m state: http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg03272.html ISTR map_domain_page_global() slots being about as rare as xenheap pages, but I guess both of those have changed a fair amount. Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 04/19] xen/passthrough: extend hypercall to support rdm reservation policy
On 06.07.15 at 12:56, tiejun.c...@intel.com wrote: Yes, this demonstrates my point. Each of these is a single-bit boolean value that takes up a single bit -- either on or off. But here you have three values -- NO_DRM, RELAXED, and STRICT, that take up two bits. If Is this fine to you? #define _XEN_DOMCTL_DEV_NO_RDM 0 #define XEN_DOMCTL_DEV_NO_RDM (1U_XEN_DOMCTL_DEV_NO_RDM) #define _XEN_DOMCTL_DEV_RDM_RELAXED 1 #define XEN_DOMCTL_DEV_RDM_RELAXED (1U_XEN_DOMCTL_DEV_RDM_RELAXED) #define _XEN_DOMCTL_DEV_RDM_STRICT 2 #define XEN_DOMCTL_DEV_RDM_STRICT (1U_XEN_DOMCTL_DEV_RDM_STRICT) AIUI these aren't individual flags, but kind of an enumeration. I.e. you should keep the original definitions and add - as suggested by George - a mask (two bits wide right now). Okay but George also thought NO_RDM may be pointless since we can just ignore this flag field simply for DT device, and he also thought one bit may be fine enough to cover two cases, strict and relaxed. So maybe finally, here is, #define XEN_DOMCTL_DEV_RDM_RELAXED1 #define XEN_DOMCTL_DEV_RDM_FLAGS_MASK (0x1) Except that then you don't need a mask. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On 06/07/15 12:09, Manish Jaggi wrote:
On Monday 06 July 2015 04:13 PM, Julien Grall wrote:
On 05/07/15 06:55, Manish Jaggi wrote:
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
u32 s;
u8 b;
u8 df;
u16 res;
} sbdf_t;
struct physdev_map_sbdf {
int domain_id;
sbdf_tsbdf;
sbdf_tgsbdf;
};
Each domain has a pdev list, which contains the list of all pci
devices.
The
pdev structure already has a sbdf information. The arch_pci_dev is
updated to
contain the gsbdf information. (gs- guest segment id)
Whenever there is trap from guest or an interrupt has to be injected,
the pdev
list is iterated to find the gsbdf.
Can you give more background for this section? i.e:
- Why do you need this?
- How xen will translate the gbdf to a vDeviceID?
In the context of the hypercall processing.
That wasn't my question. I asked, how Xen will find the mapping between
the gdbf and vDeviceID? He doesn't have access to the firmware table and
therefore not able to find the right one.
I believe gsbdf and vDeviceID would be same.
Xen and the guest need to translate the gsbdf the same way. If this is
clearly defined by a spec, then you should give a link to it.
If not, you have to explain in this design doc how you plan to have xen
and the guest using the same vdevID for a given gsbdf.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 03/32] libxc: introduce the notion of a container type
On 03/07/15 12:34, Roger Pau Monne wrote: Introduce the notion of a container type into xc_dom_image. This will be needed by later changes that will also use xc_dom_image in order to build HVM guests. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: libxl: allow permissive qemu-upstream pci passthrough.
On Fri, Jul 3, 2015 at 3:49 PM, Ian Campbell ian.campb...@citrix.com wrote: On Tue, 2015-06-02 at 16:47 +0100, Ian Campbell wrote: Anyone fancy (n)acking this followup to XSA-131? I think we probably want this for 4.6. As someone who has had dealings with the libxl side of hte permissive flag, I'll certainly Ack the idea of the change: Acked-by: George Dunlap george.dun...@eu.citrix.com Not qualified to say whether there's anyone on qmp listening, or if the flag will be ignored properly on older versions of qemu. -George From c395657b03a1e2b7616d987e7078694874981979 Mon Sep 17 00:00:00 2001 From: Ian Campbell ian.campb...@citrix.com Date: Mon, 1 Jun 2015 11:32:23 +0100 Subject: [PATCH] tools: libxl: allow permissive qemu-upstream pci passthrough. EMBARGOED UNTIL 2015-06-02 12:00 (WITH XSA-131 ET AL) Since XSA-131 qemu-xen now restricts access to PCI cfg by default. In order to allow local configuration of the existing libxl_device_pci permissive flag needs to be plumbed through via the new QMP property added by the XSA-131 patches. Versions of QEMU prior to XSA-131 did not support this permissive property, so we only pass it if it is true. Older versions only supported permissive mode. qemu-xen-traditional already supports the permissive mode setting via xenstore. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Anthony PERARD anthony.per...@citrix.com --- v2: Only set argument if permissive==true. --- tools/libxl/libxl_qmp.c | 12 1 file changed, 12 insertions(+) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 9aa7e2e..6484f5e 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -849,6 +849,18 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) QMP_PARAMETERS_SPRINTF(args, addr, %x.%x, PCI_SLOT(pcidev-vdevfn), PCI_FUNC(pcidev-vdevfn)); } +/* + * Version of QEMU prior to the XSA-131 fix did not support this + * property and were effectively always in permissive mode. The + * fix for XSA-131 switched the default to be restricted by + * default and added the permissive property. + * + * Therefore in order to support both old and new QEMU we only set + * the permissive flag if it is true. Users of older QEMU have no + * reason to set the flag so this is ok. + */ +if (pcidev-permissive) +qmp_parameters_add_bool(gc, args, permissive, true); rc = qmp_synchronous_send(qmp, device_add, args, NULL, NULL, qmp-timeout); ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 06/32] libxc: make arch_setup_boot{init/late} xc_dom_arch hooks
On 03/07/15 12:34, Roger Pau Monne wrote:
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 6fb4aee..993954e 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -926,41 +926,7 @@ static int meminit_pv(struct xc_dom_image *dom)
/*
*/
-static struct xc_dom_arch xc_dom_32_pae = {
-.guest_type = xen-3.0-x86_32p,
-.native_protocol = XEN_IO_PROTO_ABI_X86_32,
-.page_shift = PAGE_SHIFT_X86,
-.sizeof_pfn = 4,
-.alloc_magic_pages = alloc_magic_pages,
-.count_pgtables = count_pgtables_x86_32_pae,
-.setup_pgtables = setup_pgtables_x86_32_pae,
-.start_info = start_info_x86_32,
-.shared_info = shared_info_x86_32,
-.vcpu = vcpu_x86_32,
-.meminit = meminit_pv,
-};
-
-static struct xc_dom_arch xc_dom_64 = {
-.guest_type = xen-3.0-x86_64,
-.native_protocol = XEN_IO_PROTO_ABI_X86_64,
-.page_shift = PAGE_SHIFT_X86,
-.sizeof_pfn = 8,
-.alloc_magic_pages = alloc_magic_pages,
-.count_pgtables = count_pgtables_x86_64,
-.setup_pgtables = setup_pgtables_x86_64,
-.start_info = start_info_x86_64,
-.shared_info = shared_info_x86_64,
-.vcpu = vcpu_x86_64,
-.meminit = meminit_pv,
-};
-
-static void __init register_arch_hooks(void)
-{
-xc_dom_register_arch_hooks(xc_dom_32_pae);
-xc_dom_register_arch_hooks(xc_dom_64);
-}
Instead of moving this lot twice in two consecutive patches, have patch
5 move them to their eventual location, which makes this patch much smaller.
Otherwise, Reviewed-by: Andrew Cooper andrew.coo...@citrix.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 59040: regressions - FAIL
On Fri, 2015-07-03 at 21:59 +, osstest service owner wrote: flight 59040 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/59040/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-localmigrate.2 fail REGR. vs. 58958 http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html This one seems to have fallen into the merlot trap. test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 58965 From http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl-credit2/xen-unstable.html it appears this one is sporadically unreliable on cubietruck, but works just fine on arndale. Comparing to http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable.html it looks to be credit2 specific. d8v0 has a PC at 0x000c, which will be the entry point for the prefetch abort handler. ABT_LR shows it came from 0x0010 which is the data abt handler, which uses the same banked LR as prefetch abt so we don't know where it came from. SVR_LR shows that the last function call done in kernel mode was a call to fdt_check_header from early_init_dt_verify, but that might have been ages ago. Guest logs ends with it shutting down, but I think that is the previous test step completing. test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-start.2 fail REGR. vs. 58965 http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-debianhvm-amd64/xen-unstable.html 2015-07-03 15:40:16 Z guest debianhvm.guest.osstest 5a:36:0e:a0:00:1e 22 link/ip/tcp: ping gave (256): PING 172.16.146.71 (172.16.146.71) 56(84) bytes of data. | From 172.16.144.3 icmp_seq=1 Destination Host Unreachable | From 172.16.144.3 icmp_seq=2 Destination Host Unreachable | From 172.16.144.3 icmp_seq=3 Destination Host Unreachable | From 172.16.144.3 icmp_seq=4 Destination Host Unreachable | From 172.16.144.3 icmp_seq=5 Destination Host Unreachable | | --- 172.16.146.71 ping statistics --- | 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time XXXms | pipe 3 | (waiting) ... 2015-07-03 15:40:27 Z guest debianhvm.guest.osstest 5a:36:0e:a0:00:1e 22 link/ip/tcp: ok. (31s) 2015-07-03 15:40:27 Z executing ssh ... root@172.16.146.71 echo guest debianhvm.guest.osstest: ok ssh: connect to host 172.16.146.71 port 22: Connection refused Ian, I believe you observed some other instances of this in triaging another failure last week. http://logs.test-lab.xenproject.org/osstest/logs/59040/test-amd64-amd64-xl-qemuu-debianhvm-amd64/fiano0---var-log-xen-qemu-dm-debianhvm.guest.osstest.log is pretty uninteresting, we should perhaps arrange to remove some quiet's from guest commands lines somewhere, or to frob the guest console to include ttyS0, which it isn't clear it does. vnc snapshot just shows the login prompt. The bisector looks to be working on this one http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-qemuu-debianhvm-amd64.guest-start.2.html but I don't think it is going to conclude anything, since it looks intermittent. test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965 http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html 2015-07-03 15:39:29 Z executing ssh ... root@172.16.144.41 xl list 2015-07-03 15:39:30 Z guest debianhvm.guest.osstest not present on this host 2015-07-03 15:39:30 Z FAILURE: guest unexpectedly shutdown; state is '' failure: guest unexpectedly shutdown; state is '' The xl log just says: Waiting for domain debianhvm.guest.osstest (domid 1) to die [pid 4412] Domain 1 has shut down, reason code 0 0x0 Action for shutdown reason code 0 is destroy Domain 1 needs to be cleaned up: destroying the domain Done. Exiting now Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server
On Mon, Jul 6, 2015 at 7:25 AM, Yu Zhang yu.c.zh...@linux.intel.com wrote: MAX_NR_IO_RANGES is used by ioreq server as the maximum number of discrete ranges to be tracked. This patch changes its value to 8k, so that more ranges can be tracked on next generation of Intel platforms in XenGT. Future patches can extend the limit to be toolstack tunable, and MAX_NR_IO_RANGES can serve as a default limit. Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com I said this at the Hackathon, and I'll say it here: I think this is the wrong approach. The problem here is not that you don't have enough memory ranges. The problem is that you are not tracking memory ranges, but individual pages. You need to make a new interface that allows you to tag individual gfns as p2m_mmio_write_dm, and then allow one ioreq server to get notifications for all such writes. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/6] libxl: Use the block-tap script for LIBXL_DISK_BACKEND_TAP
On Mon, Jul 6, 2015 at 12:01 PM, Andrew Cooper andrew.coop...@citrix.com wrote: On 06/07/15 11:51, George Dunlap wrote: The block-tap script can now do everything needed for libxl; no need to link against the blktap library. To do this: * Set disk-script to block-tap and dev to format:pdev_path in device_disk_add for LIBXL_DISK_BACKEND_TAP * Remove libxl_blktap2.o and libxl_noblktap2.o and all code depending on them Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Dave Scott dave.sc...@eu.citrix.com CC: Jonathan Ludlam jonathan.lud...@eu.citrix.com CC: Wen Congyang we...@cn.fujitsu.com CC: Yang Hongyang yan...@cn.fujitsu.com CC: Felipe Franciosi felipe.franci...@citrix.com Note: This is broken for HVM domains at the moment because all block scripts are broken for HVM domains. That is a bug which should be a blocker for the 4.6 release. As such, I think there is justification for checking in this feature (enabling use of a 'system' blktap) with the assumption that the FIXME will go away before the release. That will technically break bisectability; but only for users of blktap (which does not include osstest). --- tools/libxl/Makefile | 5 --- tools/libxl/libxl.c | 28 - tools/libxl/libxl_blktap2.c | 93 --- tools/libxl/libxl_device.c| 14 --- tools/libxl/libxl_dm.c| 5 ++- tools/libxl/libxl_internal.h | 26 tools/libxl/libxl_noblktap2.c | 42 --- 7 files changed, 11 insertions(+), 202 deletions(-) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index cc9c152..43ab243 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -44,11 +44,6 @@ LIBXL_LIBS += $(LIBXL_LIBS-y) LIBXLU_LIBS = libxenlight.so LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o -ifeq ($(LIBXL_BLKTAP),y) You will also want to remove reference to LIBXL_BLKTAP from Rules.mk Indeed, there is quite a bit I seem to have missed... I'll add a patch exising the configure- and make-related bits, separately from both this patch and the rm -rf tools/blktap2 patch. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Sharing display between guests
Hi Dario On Thu, Jul 02, 2015 at 02:18:18PM +0200, Dario Faggioli wrote: I don't have much comments on all this, just that, reading, it, it sounded somewhat similar to what GL is doing: http://www.xenproject.org/component/allvideoshare/video/latest/ces15-globalogic.html http://www.xenproject.org/component/allvideoshare/video/globallogic-xen-android.html For some reason, the first video wouldn't play here, so I can really comment on the second one, but I don't think there was a screen sharing here. It demoes Android running in a domU, which is already a nice achievement, but it's not really the part that concern me the most. I'm slightly more concerned about the two VM displaying stuff at the same time. That would mean that we would have a static composition, that would be setup once and we could forget about it during the life of the system. Well, they use a DomU and Dom0, rather than 2 DomUs (or so I think), but is seems to me that at least some composition is indeed happening. Ideally, we would like both to be domU, with dom0 only taking care of the composition. I don't have much more details, I'm afraid, but if you think your use case is related, or at least that you could benefit from interacting with them and sharing experiences/code/whatever, just ask, I've Cc-ed some of them. :-) Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Sharing display between guests
Hi Ian, On Mon, Jul 06, 2015 at 12:53:49PM +0100, Ian Campbell wrote: (switching to my work address) On Thu, 2015-07-02 at 13:13 +0200, Maxime Ripard wrote: Hi, I've started using Xen on an Allwinner A33, which works great as an headless device using the latest PSCI patches in U-Boot. However, we would like to do something more with it, and we would need to have two VMs accessing the display at once, each one drawing in its own part of the framebuffer. Something that would look like this: Framebuffer +---+ | | |Guest 1| | | +---+ | | | | | | |Guest 2| | | | | | | +---+ Where thing start to get interesting is that the second guest would be running Android, and as such would need OpenGL support, and access to the GPU, and that ideally the first guest would need to be able to draw over all the screen to create some kind of a drop-down menu. Our first thought was to use two different planes of a DRM/KMS driver, one for each VM, with the second guest having the primary plane, and the first guest having an overlay, and we would set it up in dom0. That would mean that we would have a static composition, that would be setup once and we could forget about it during the life of the system. This way, we would also have a fixed size framebuffer assigned to Android, which is much easier to support, and since we have total control over the application in the first guest, we would be able to control how much transparency we want to leave (== how much of Android do we want to be displayed), and we would be able to create our drop-down menu. Now the hard part: is such a setup possible at all with Xen? Can we export a single plane to a guest and let it be the only user of it? If that is possible, how would that interact with the 3D acceleration? As it stands today Xen supports exposing a 2D only PV graphics device (called pvfb, essentially a flat/linear framebuffer) to guests, I think this has limited 2D acceleration support let alone 3D support. You can also (at least in principal, i.e. if the hardware isn't too strange) pass a GPU through to exactly one guest (often it's just dom0). Some people have also (I think) managed to use pvfb to expose a real linear fb to a guest, e.g. a surface in the real GPU which is setup by some more privileged domain. But, it sounds like you really want a way to expose the GPU functionality (i.e. 3D support) to at least one if not both guests. Are you expecting Guest 1 and Guest 2 to be isolated from each other in a secure way? Or is one considered to be more privileged than the other? I'd like to have both guests as isolated from each other as possible. But there's two sub-issues here actually: 1) Being able to have two VMs showing stuff on the same framebuffer at the same time, without being aware of the other. If we could make pvfb run on a DRM/KMS plane, that would be perfect for us. Another solution would be to split the framebuffer in half and have pvfb running on those two halves. 2) Then, one of the guests would be Android, which really requires OpenGL, but the second guests would ideally use it as well, but if it complicates things (and it really seems like it does), we can drop that from the requirement, which would make us fall in the exactly one guest case you were talking about (except that it wouldn't dom0, but one of the domU's that would access it). Our hardware is an A33-based board, that uses a Mali. I'm not exactly sure about what you meant with your if the hardware isn't too strange. Is there features or hints I should be looking for? (disclaimer: From here on I'm a bit outside the realms of things I'm getting even further from the space where I'm confident in my own understanding...) Various people have tried to solve this usecase by providing a PV 3D (OpenGL, Gallium, etc) protocol over the PV FB, but I think this turns out to be quite tricky (in terms of shuffling textures around as well as being able to validate the command stream) and generally little comes of it beyond a PoC. (It's been quite some time since I've seen someone try this approach). The other approach would involve exposing the actual hardware to the guest(s). In general unless your hardware has some special features (vGPU or SR-IOV or something similar) it is rarely safe to let two guests access the same bit of h/w unless they are both willing to co-operate and are assumed to be mutually destructive. Various folks, including Globalogic who Dario pointed too and Intel with XenGT (which has been renamed but I don't recall the new name) have tried to take a hybrid approach emulating parts of the device in some privileged layer and exposing some parts of the h/w directly to the
Re: [Xen-devel] Performance problem about address translation
在 2015-07-06, Mon, 15:44:53 ,Andrew Cooper 写到： On 06/07/2015 08:22, xinyue wrote: nbsp; Hi, nbsp;nbsp;nbsp; For I want to translate the virtual address in HVM DomU to virtual address in Xen. But when I use the function paging_gva_to_gfn and get_gfn, I can feel the performance down quickly, the machine become very hot and then I have to force the machine shutting down. Your machine clearly isn#39;t cooled sufficiently, which is the first problem. The codes I used as below: nbsp;nbsp;nbsp; uint32_t pfec = PFEC_page_present; nbsp;nbsp;nbsp; unsigned long gfn; nbsp;nbsp;nbsp; unsigned long mfn; nbsp;nbsp;nbsp; unsigned long virtaddr; nbsp;nbsp;nbsp; struct vcpu *vcpu = current; nbsp;nbsp;nbsp; struct domain *d = vcpu-gt;domain; nbsp;nbsp;nbsp; gfn = paging_gva_to_gfn(current, 0xc029, amp;pfec); nbsp;nbsp;nbsp; mfn = get_gfn(d, gfn, amp;t); nbsp;nbsp;nbsp; virtaddr = map_domain_page(mfn_x(mfn)); I also use the dbg_hvm_va2mfn function in debug.c, performance problem still present. Walking pagetables in software is slow.nbsp; There is no getting around this. Your performance problems will be caused by performing the operation far too often.nbsp; You should find a way to reduce this. Thanks very much, I think I only do this for just once. And after the thanslation is done, the performance is not turn to normal. Does that mean that if I wait long enough it will recovery? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Sharing display between guests
(switching to my work address) On Thu, 2015-07-02 at 13:13 +0200, Maxime Ripard wrote: Hi, I've started using Xen on an Allwinner A33, which works great as an headless device using the latest PSCI patches in U-Boot. However, we would like to do something more with it, and we would need to have two VMs accessing the display at once, each one drawing in its own part of the framebuffer. Something that would look like this: Framebuffer +---+ | | |Guest 1| | | +---+ | | | | | | |Guest 2| | | | | | | +---+ Where thing start to get interesting is that the second guest would be running Android, and as such would need OpenGL support, and access to the GPU, and that ideally the first guest would need to be able to draw over all the screen to create some kind of a drop-down menu. Our first thought was to use two different planes of a DRM/KMS driver, one for each VM, with the second guest having the primary plane, and the first guest having an overlay, and we would set it up in dom0. That would mean that we would have a static composition, that would be setup once and we could forget about it during the life of the system. This way, we would also have a fixed size framebuffer assigned to Android, which is much easier to support, and since we have total control over the application in the first guest, we would be able to control how much transparency we want to leave (== how much of Android do we want to be displayed), and we would be able to create our drop-down menu. Now the hard part: is such a setup possible at all with Xen? Can we export a single plane to a guest and let it be the only user of it? If that is possible, how would that interact with the 3D acceleration? As it stands today Xen supports exposing a 2D only PV graphics device (called pvfb, essentially a flat/linear framebuffer) to guests, I think this has limited 2D acceleration support let alone 3D support. You can also (at least in principal, i.e. if the hardware isn't too strange) pass a GPU through to exactly one guest (often it's just dom0). Some people have also (I think) managed to use pvfb to expose a real linear fb to a guest, e.g. a surface in the real GPU which is setup by some more privileged domain. But, it sounds like you really want a way to expose the GPU functionality (i.e. 3D support) to at least one if not both guests. Are you expecting Guest 1 and Guest 2 to be isolated from each other in a secure way? Or is one considered to be more privileged than the other? (disclaimer: From here on I'm a bit outside the realms of things I'm getting even further from the space where I'm confident in my own understanding...) Various people have tried to solve this usecase by providing a PV 3D (OpenGL, Gallium, etc) protocol over the PV FB, but I think this turns out to be quite tricky (in terms of shuffling textures around as well as being able to validate the command stream) and generally little comes of it beyond a PoC. (It's been quite some time since I've seen someone try this approach). The other approach would involve exposing the actual hardware to the guest(s). In general unless your hardware has some special features (vGPU or SR-IOV or something similar) it is rarely safe to let two guests access the same bit of h/w unless they are both willing to co-operate and are assumed to be mutually destructive. Various folks, including Globalogic who Dario pointed too and Intel with XenGT (which has been renamed but I don't recall the new name) have tried to take a hybrid approach emulating parts of the device in some privileged layer and exposing some parts of the h/w directly to the guest. AIUI this is necessarily specific to a particular GPU device and needs the device to have some convenient properties, but falls short of requiring full virtualisability of the h/w ala vGPU or SR-IOV. If not, is it something that is conceptually flawed, or does one just need to write the appropriate amount of code? Do you have a better solution to this problem? I don't think it is conceptually flawed, but I also think it's not an easy problem (sorry). Thanks a lot for your feedback, Maxime ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 04/32] libxc: introduce a domain loader for HVM guest firmware
On 03/07/15 12:34, Roger Pau Monne wrote: Introduce a very simple (and dummy) domain loader to be used to load the firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf executable the loader is fairly simple. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Looks plausible. I would s/__FUNCTION__/__func__/g throughout, and there are several coding style issues which could do with fixing. Otherwise, Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server
-Original Message- From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap Sent: 06 July 2015 13:36 To: Yu Zhang Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Paul Durrant; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On Mon, Jul 6, 2015 at 7:25 AM, Yu Zhang yu.c.zh...@linux.intel.com wrote: MAX_NR_IO_RANGES is used by ioreq server as the maximum number of discrete ranges to be tracked. This patch changes its value to 8k, so that more ranges can be tracked on next generation of Intel platforms in XenGT. Future patches can extend the limit to be toolstack tunable, and MAX_NR_IO_RANGES can serve as a default limit. Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com I said this at the Hackathon, and I'll say it here: I think this is the wrong approach. The problem here is not that you don't have enough memory ranges. The problem is that you are not tracking memory ranges, but individual pages. You need to make a new interface that allows you to tag individual gfns as p2m_mmio_write_dm, and then allow one ioreq server to get notifications for all such writes. I think that is conflating things. It's quite conceivable that more than one ioreq server will handle write_dm pages. If we had enough types to have two page types per server then I'd agree with you, but we don't. Paul -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Sharing display between guests
On Mon, 2015-07-06 at 14:26 +0200, Maxime Ripard wrote: Hi Ian, On Mon, Jul 06, 2015 at 12:53:49PM +0100, Ian Campbell wrote: (switching to my work address) On Thu, 2015-07-02 at 13:13 +0200, Maxime Ripard wrote: Hi, I've started using Xen on an Allwinner A33, which works great as an headless device using the latest PSCI patches in U-Boot. However, we would like to do something more with it, and we would need to have two VMs accessing the display at once, each one drawing in its own part of the framebuffer. Something that would look like this: Framebuffer +---+ | | |Guest 1| | | +---+ | | | | | | |Guest 2| | | | | | | +---+ Where thing start to get interesting is that the second guest would be running Android, and as such would need OpenGL support, and access to the GPU, and that ideally the first guest would need to be able to draw over all the screen to create some kind of a drop-down menu. Our first thought was to use two different planes of a DRM/KMS driver, one for each VM, with the second guest having the primary plane, and the first guest having an overlay, and we would set it up in dom0. That would mean that we would have a static composition, that would be setup once and we could forget about it during the life of the system. This way, we would also have a fixed size framebuffer assigned to Android, which is much easier to support, and since we have total control over the application in the first guest, we would be able to control how much transparency we want to leave (== how much of Android do we want to be displayed), and we would be able to create our drop-down menu. Now the hard part: is such a setup possible at all with Xen? Can we export a single plane to a guest and let it be the only user of it? If that is possible, how would that interact with the 3D acceleration? As it stands today Xen supports exposing a 2D only PV graphics device (called pvfb, essentially a flat/linear framebuffer) to guests, I think this has limited 2D acceleration support let alone 3D support. You can also (at least in principal, i.e. if the hardware isn't too strange) pass a GPU through to exactly one guest (often it's just dom0). Some people have also (I think) managed to use pvfb to expose a real linear fb to a guest, e.g. a surface in the real GPU which is setup by some more privileged domain. But, it sounds like you really want a way to expose the GPU functionality (i.e. 3D support) to at least one if not both guests. Are you expecting Guest 1 and Guest 2 to be isolated from each other in a secure way? Or is one considered to be more privileged than the other? I'd like to have both guests as isolated from each other as possible. But there's two sub-issues here actually: 1) Being able to have two VMs showing stuff on the same framebuffer at the same time, without being aware of the other. If we could make pvfb run on a DRM/KMS plane, that would be perfect for us. Another solution would be to split the framebuffer in half and have pvfb running on those two halves. Right, this portion is a bit more tractable in the short term I think. 2) Then, one of the guests would be Android, which really requires OpenGL, but the second guests would ideally use it as well, but if it complicates things (and it really seems like it does), we can drop that from the requirement, which would make us fall in the exactly one guest case you were talking about (except that it wouldn't dom0, but one of the domU's that would access it). IOW give the Android full access to the h/w and have it provide a 2d pvfb to the other guest, yes I think that could be made to work. However, there is a wrinkle, which is that passthrough normally requires an SMMU, which I'm reasonably sure the A33 doesn't have. The usual workaround (which I think Glaballogic use) is to allocate guest memory 1:1 (i.e. so it matches in IPA and PA space). This is a hack though and we don't like it :-/. Our hardware is an A33-based board, that uses a Mali. I'm not exactly sure about what you meant with your if the hardware isn't too strange. Is there features or hints I should be looking for? That was mostly a reference to x86 where various combinations of the BIOS, Video ROM and the legacy PC architecture can collude to make life hard (like not being able to execute the VBIOS twice, or only working in primary xor secondary mode, accesses which by-pass the SMMU, etc). I don't know specifically of anything similar with ARM or Mali. (disclaimer: From here on I'm a bit outside the realms of things I'm getting even further from the space where I'm confident in my own
Re: [Xen-devel] [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m
On 06.07.15 at 13:25, t...@xen.org wrote: At 10:50 +0100 on 06 Jul (1436179849), Jan Beulich wrote: On 01.07.15 at 20:09, edmund.h.wh...@intel.com wrote: Changes since v2: Addressed all v2 feedback *except*: In patch 5, the per-domain EPTP list page is still allocated from the Xen heap. If allocated from the domain heap Xen panics - IIRC on Haswell hardware when walking the EPTP list during exit processing in patch 6. With this little detail I can't take this as a valid reason not to make this change. Also - weren't we aiming at getting the page from the HAP pool of the domain anyway? This one keeps coming up again, and I think has not been explained very clearly. For me, the important detail is that this is basically an extension of the VMCx structures, and not part of any per-vcpu/per-p2m state: http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg03272.html Okay, I must have forgotten about you saying so. Viewed that way, it certainly makes sense. ISTR map_domain_page_global() slots being about as rare as xenheap pages, but I guess both of those have changed a fair amount. Except that we have some room to grow the vmap() area, but we can't reasonably grow the Xen heap. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Modified RTDS scheduler to use an event-driven model instead of polling.
On Thu, 2015-07-02 at 22:12 -0700, Meng Xu wrote:
Hi Dario,
Hi,
[Since I have commented on this thread in previous email, I just
top-post it for reminder.]
Just in case, this email is out of your radar... :-)
It is on my radar. It's just that I really had to drain my queue of
bugfixes. Sorry for the dealy, I'm looking at it today.
Regards,
Dario
I had discussed this patch with Dagaen as shown in
http://www.gossamer-threads.com/lists/xen/devel/386651
You don't need any detailed comment for this patch. We only need your
confirmation if this is in the correct direction and there is not
serious design issue in this implementation.
Once we are confirmed with that, we can send the next version with the
minor stuffs (such as coding style) done soon.
2015-06-27 12:46 GMT-07:00 Dagaen Golomb dgol...@seas.upenn.edu:
To do this, we create a new list that holds, for each
vcpu, the time least into the future that it may need to be
rescheduled. The scheduler chooses the lowest time off of this
list and waits until the specified time instead of running every
1 ms as it did before.
Signed-off-by: Dagaen Golomb dgol...@seas.upenn.edu
Signed-off-by: Meng Xu men...@cis.upenn.edu
---
xen/common/sched_rt.c | 100
+
1 file changed, 93 insertions(+), 7 deletions(-)
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 4372486..cce3446 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -4,6 +4,7 @@
*
* by Sisu Xi, 2013, Washington University in Saint Louis
* and Meng Xu, 2014, University of Pennsylvania
+ * and Dagaen Golomb, 2015, University of Pennsylvania
*
* based on the code of credit Scheduler
*/
@@ -152,6 +153,8 @@ struct rt_private {
struct list_head sdom; /* list of availalbe domains, used for
dump */
struct list_head runq; /* ordered list of runnable vcpus */
struct list_head depletedq; /* unordered list of depleted vcpus */
+struct timer replenishment_timer;
+unsigned NUM_CPUS;
cpumask_t tickled; /* cpus been tickled */
};
@@ -178,6 +181,8 @@ struct rt_vcpu {
unsigned flags; /* mark __RTDS_scheduled, etc.. */
};
+static void runq_tickle(const struct scheduler *, struct rt_vcpu *);
+
/*
* Domain
*/
@@ -391,13 +396,19 @@ __q_remove(struct rt_vcpu *svc)
* Insert svc with budget in RunQ according to EDF:
* vcpus with smaller deadlines go first.
* Insert svc without budget in DepletedQ unsorted;
+ *
+ * Returns the position, 1-indexed, of where the item was inserted.
+ * Returns a positive index if placed on runq, and a negative index (the
index
+ * in the depletedq * -1) if placed on the depletedq
*/
-static void
+static int
__runq_insert(const struct scheduler *ops, struct rt_vcpu *svc)
{
struct rt_private *prv = rt_priv(ops);
struct list_head *runq = rt_runq(ops);
+struct list_head *depletedq = rt_depletedq(ops);
struct list_head *iter;
+unsigned inserted_index = 1;
ASSERT( spin_is_locked(prv-lock) );
@@ -411,15 +422,77 @@ __runq_insert(const struct scheduler *ops, struct
rt_vcpu *svc)
struct rt_vcpu * iter_svc = __q_elem(iter);
if ( svc-cur_deadline = iter_svc-cur_deadline )
break;
+else
+++inserted_index;
}
list_add_tail(svc-q_elem, iter);
+return inserted_index;
}
else
{
-list_add(svc-q_elem, prv-depletedq);
+// If we are inserting into previously empty depletedq, rearm
+// rearm replenish timer. It will handle further scheduling until
+// the depletedq is empty again (if ever)
+if( list_empty(depletedq) )
+set_timer( prv-replenishment_timer, svc-cur_deadline );
+
+list_for_each(iter, depletedq)
+{
+struct rt_vcpu * iter_svc = __q_elem(iter);
+if ( svc-cur_deadline = iter_svc-cur_deadline )
+break;
+else
+++inserted_index;
+ }
+list_add_tail(svc-q_elem, iter);
+return -inserted_index;
}
}
+static void replenishment_handler(void* data)
+{
+const struct scheduler *ops = data;
+struct rt_private *prv = rt_priv(ops);
+struct list_head *depletedq = rt_depletedq(ops);
+struct list_head *iter;
+struct list_head *tmp;
+struct rt_vcpu *svc = NULL;
+s_time_t now = NOW();
+int new_position = 0;
+unsigned long flags;
+
+spin_lock_irqsave(prv-lock, flags);
+
+// Replenish the vCPU that triggered this, and resort it into runq
+list_for_each_safe(iter, tmp, depletedq)
+{
+svc = __q_elem(iter);
+if ( now = svc-cur_deadline )
[Xen-devel] [xen-unstable test] 59058: regressions - FAIL
flight 59058 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/59058/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 58965 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-installfail REGR. vs. 58965 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965 test-amd64-i386-freebsd10-i386 15 guest-localmigrate.2fail REGR. vs. 58965 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 58965 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 58948 test-amd64-i386-libvirt-xsm 11 guest-start fail like 58965 test-amd64-i386-libvirt 11 guest-start fail like 58965 test-amd64-amd64-libvirt 11 guest-start fail like 58965 test-amd64-amd64-libvirt-xsm 11 guest-start fail like 58965 test-armhf-armhf-xl-rtds 11 guest-start fail like 58965 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-localmigrate fail like 58965 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58965 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58965 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen b9dbe33d15a038500bcc3226a3ca31ee215122cd baseline version: xen c40317f11b3f05e7c06a2213560c8471081f2662 Last test of basis58965 2015-06-29 02:08:30 Z7 days Failing since 58974 2015-06-29 15:11:59 Z6 days7 attempts Testing same since59058 2015-07-05 10:39:08 Z1 days1 attempts People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Ard Biesheuvel a...@linaro.org Chen Baozi baoz...@gmail.com Dario Faggioli dario.faggi...@citrix.com Euan Harris euan.har...@citrix.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Jennifer Herbert jennifer.herb...@citrix.com Julien Grall julien.gr...@citrix.com Liang Li liang.z...@intel.com Samuel Thibault samuel.thiba...@ens-lyon.org Thomas Leonard tal...@gmail.com Tiejun Chen tiejun.c...@intel.com Wei Liu wei.l...@citrix.com Wen Congyang we...@cn.fujitsu.com Yang Zhang yang.z.zh...@intel.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl
Re: [Xen-devel] [PATCH v3 05/32] libxc: make arch_setup_meminit a xc_dom_arch hook
On 03/07/15 12:34, Roger Pau Monne wrote: This allows having different arch_setup_meminit implementations based on the guest type. It should not introduce any functional changes. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com However, would you mind doing a cleanup patch which changes the use of __init. Confusingly given its precedent in hypervisor code, xc_dom.h has #define __init __attribute__ ((constructor)). At a first guess, 'initcall' or even just 'constructor' would be more appropriate names. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 59040: regressions - FAIL
Ian Campbell writes (Re: [Xen-devel] [xen-unstable test] 59040: regressions - FAIL): From http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl-credit2/xen-unstable.html it appears this one is sporadically unreliable on cubietruck, but works just fine on arndale. ... it looks to be credit2 specific. .. Ian, I believe you observed some other instances of this in triaging another failure last week. Yes, but I'm afraid I don't remember exactly which failure. The bisector looks to be working on this one http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-qemuu-debianhvm-amd64.guest-start.2.html but I don't think it is going to conclude anything, since it looks intermittent. test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965 http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html 2015-07-03 15:39:29 Z executing ssh ... root@172.16.144.41 xl list 2015-07-03 15:39:30 Z guest debianhvm.guest.osstest not present on this host 2015-07-03 15:39:30 Z FAILURE: guest unexpectedly shutdown; state is '' failure: guest unexpectedly shutdown; state is '' The xl log just says: Waiting for domain debianhvm.guest.osstest (domid 1) to die [pid 4412] Domain 1 has shut down, reason code 0 0x0 Action for shutdown reason code 0 is destroy Domain 1 needs to be cleaned up: destroying the domain Done. Exiting now This is quite weird. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 07/32] xen/x86: fix arch_set_info_guest for HVM guests
On 03/07/15 12:34, Roger Pau Monne wrote:
Add checks for ignored vcpu fields in HVM mode. HVM vCPUs (BSP and APs) are
always started in 32bit protected mode with paging disabled.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
---
xen/arch/x86/domain.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a8fe046..a112953 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -795,6 +795,15 @@ int arch_set_info_guest(
c.nat-fs_base || c.nat-gs_base_user)) )
return -EINVAL;
}
+else if ( is_hvm_domain(d) )
+{
+if ( c(ctrlreg[0]) || c(ctrlreg[1]) || c(ctrlreg[2]) ||
+ c(ctrlreg[3]) || c(ctrlreg[4]) || c(ctrlreg[5]) ||
I am not sure that the cr0 and cr4 checks are sensible. While the new
ABI doesn't need them, there is nothing inherently wrong with setting
them via this interface.
+ c(ctrlreg[6]) || c(ctrlreg[7]) || c(ldt_base) ||
+ c(ldt_ents) || c(kernel_ss) || c(kernel_sp) ||
+ c(gdt_ents) )
+return -EINVAL;
+}
v-fpu_initialised = !!(flags VGCF_I387_VALID);
@@ -1064,15 +1073,14 @@ int arch_set_info_guest(
if ( v-vcpu_id == 0 )
update_domain_wallclock_time(d);
-/* Don't redo final setup */
-v-is_initialised = 1;
-
Is this a bugfix, or spurious movement?
~Andrew
if ( paging_mode_enabled(d) )
paging_update_paging_modes(v);
update_cr3(v);
out:
+/* Don't redo final setup */
+v-is_initialised = 1;
if ( flags VGCF_online )
clear_bit(_VPF_down, v-pause_flags);
else
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] libxc: fix PV vNUMA guest memory allocation
On 06/07/15 14:17, Wei Liu wrote:
In 415b58c1 (tools/libxc: Batch memory allocations for PV guests) the
number of super pages is calculated with the number of total pages. That
is wrong. It breaks PV guest vNUMA. The correct number of super pages
should be derived from the number of pages within that virtual NUMA
node.
Also change the name and type of super page variable to match the naming
convention and type of normal page variable. Make the necessary
adjustment to make code compile.
Reported-by: Dario Faggioli dario.faggi...@citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
---
Cc: Ross Lagerwall ross.lagerw...@citrix.com
---
tools/libxc/xc_dom_x86.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index acd7b3f..faabe96 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -879,9 +879,8 @@ int arch_setup_meminit(struct xc_dom_image *dom)
for ( i = 0; i nr_vmemranges; i++ )
{
unsigned int memflags;
-uint64_t pages;
+uint64_t pages, super_pages;
unsigned int pnode = vnode_to_pnode[vmemranges[i].nid];
-int nr_spages = dom-total_pages SUPERPAGE_PFN_SHIFT;
xen_pfn_t extents[SUPERPAGE_BATCH_SIZE];
xen_pfn_t pfn_base_idx;
@@ -891,15 +890,16 @@ int arch_setup_meminit(struct xc_dom_image *dom)
pages = (vmemranges[i].end - vmemranges[i].start)
PAGE_SHIFT;
+super_pages = pages SUPERPAGE_PFN_SHIFT;
pfn_base = vmemranges[i].start PAGE_SHIFT;
for ( pfn = pfn_base; pfn pfn_base+pages; pfn++ )
dom-p2m_host[pfn] = pfn;
pfn_base_idx = pfn_base;
-while (nr_spages) {
-int count = min(nr_spages, SUPERPAGE_BATCH_SIZE);
-nr_spages -= count;
+while (super_pages) {
+int count = min_t(uint64_t, super_pages,
SUPERPAGE_BATCH_SIZE);
This line alone indicates that int is not an appropriate type for
count. unsigned int as as an absolute minimum, as it will be bounded to
SUPERPAGE_BATCH_SIZE.
~Andrew
+super_pages -= count;
for ( pfn = pfn_base_idx, j = 0;
pfn pfn_base_idx + (count SUPERPAGE_PFN_SHIFT);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server
-Original Message- From: George Dunlap [mailto:george.dun...@eu.citrix.com] Sent: 06 July 2015 14:28 To: Paul Durrant; George Dunlap Cc: Yu Zhang; xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On 07/06/2015 02:09 PM, Paul Durrant wrote: -Original Message- From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap Sent: 06 July 2015 13:50 To: Paul Durrant Cc: Yu Zhang; xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On Mon, Jul 6, 2015 at 1:38 PM, Paul Durrant paul.durr...@citrix.com wrote: -Original Message- From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap Sent: 06 July 2015 13:36 To: Yu Zhang Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Paul Durrant; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On Mon, Jul 6, 2015 at 7:25 AM, Yu Zhang yu.c.zh...@linux.intel.com wrote: MAX_NR_IO_RANGES is used by ioreq server as the maximum number of discrete ranges to be tracked. This patch changes its value to 8k, so that more ranges can be tracked on next generation of Intel platforms in XenGT. Future patches can extend the limit to be toolstack tunable, and MAX_NR_IO_RANGES can serve as a default limit. Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com I said this at the Hackathon, and I'll say it here: I think this is the wrong approach. The problem here is not that you don't have enough memory ranges. The problem is that you are not tracking memory ranges, but individual pages. You need to make a new interface that allows you to tag individual gfns as p2m_mmio_write_dm, and then allow one ioreq server to get notifications for all such writes. I think that is conflating things. It's quite conceivable that more than one ioreq server will handle write_dm pages. If we had enough types to have two page types per server then I'd agree with you, but we don't. What's conflating things is using an interface designed for *device memory ranges* to instead *track writes to gfns*. What's the difference? Are you asserting that all device memory ranges have read side effects and therefore write_dm is not a reasonable optimization to use? I would not want to make that assertion. Using write_dm is not the problem; it's having thousands of memory ranges of 4k each that I object to. Which is why I suggested adding an interface to request updates to gfns (by marking them write_dm), rather than abusing the io range interface. And it's the assertion that use of write_dm will only be relevant to gfns, and that all such notifications only need go to a single ioreq server, that I have a problem with. Whilst the use of io ranges to track gfn updates is, I agree, not ideal I think the overloading of write_dm is not a step in the right direction. Paul -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] libxc: fix PV vNUMA guest memory allocation
On 07/06/2015 02:30 PM, Wei Liu wrote:
On Mon, Jul 06, 2015 at 02:26:37PM +0100, Andrew Cooper wrote:
On 06/07/15 14:17, Wei Liu wrote:
In 415b58c1 (tools/libxc: Batch memory allocations for PV guests) the
number of super pages is calculated with the number of total pages. That
is wrong. It breaks PV guest vNUMA. The correct number of super pages
should be derived from the number of pages within that virtual NUMA
node.
Also change the name and type of super page variable to match the naming
convention and type of normal page variable. Make the necessary
adjustment to make code compile.
Reported-by: Dario Faggioli dario.faggi...@citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
---
Cc: Ross Lagerwall ross.lagerw...@citrix.com
---
tools/libxc/xc_dom_x86.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index acd7b3f..faabe96 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -879,9 +879,8 @@ int arch_setup_meminit(struct xc_dom_image *dom)
for ( i = 0; i nr_vmemranges; i++ )
{
unsigned int memflags;
-uint64_t pages;
+uint64_t pages, super_pages;
unsigned int pnode = vnode_to_pnode[vmemranges[i].nid];
-int nr_spages = dom-total_pages SUPERPAGE_PFN_SHIFT;
xen_pfn_t extents[SUPERPAGE_BATCH_SIZE];
xen_pfn_t pfn_base_idx;
@@ -891,15 +890,16 @@ int arch_setup_meminit(struct xc_dom_image *dom)
pages = (vmemranges[i].end - vmemranges[i].start)
PAGE_SHIFT;
+super_pages = pages SUPERPAGE_PFN_SHIFT;
pfn_base = vmemranges[i].start PAGE_SHIFT;
for ( pfn = pfn_base; pfn pfn_base+pages; pfn++ )
dom-p2m_host[pfn] = pfn;
pfn_base_idx = pfn_base;
-while (nr_spages) {
-int count = min(nr_spages, SUPERPAGE_BATCH_SIZE);
-nr_spages -= count;
+while (super_pages) {
+int count = min_t(uint64_t, super_pages, SUPERPAGE_BATCH_SIZE);
This line alone indicates that int is not an appropriate type for
count. unsigned int as as an absolute minimum, as it will be bounded to
SUPERPAGE_BATCH_SIZE.
Yes, I also need to make count uint64_t.
Is this needed? count should never be larger than 512 (aka
SUPERPAGE_BATCH_SIZE).
--
Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy
I think we should go back here. I was involved in the design discussion, and from the very beginning I probably saw your plan but misunderstood it. I wouldn't be surprised if some others didn't quite understand what they were agreeing to. This way of doing things is different than the way we do it with most other options relating to pci devices (e.g., pci_permissive, pci_msitranslate, pci_sieze, c). All of those options use a default semantic: the domain-wide setting takes effect only if it's not set locally. If the syntax looks the same but the semantics is different, many people will be confused. If we're going to have the domain-wide policy override the per-device policy, then the naming should make that clear; for instance, override=(strict|relaxed|none), or strict_override=(1|0). Jan, What about this? This is involving our policy so please take a look at this as well. George, Actually we don't mean the domain-wide policy always override the per-device policy, or the per-device policy always override the per-device policy. Here we just take strict as the highest priority when it conflicts in two cases. As I said previously myself may not answer this very correctly but now I can recall or understand that one reason is that different devices can share one RMRR entry, so its possible that these two or more per-device policies are not same. So we need this particular rule which is not same as before. So I still prefer to keep our original implementation. If I'm missing something or wrong, please Jan correct me. Thanks Tiejun I don't happen to think these override semantics are actually going to turn out to be that useful; I do think a default semantic would be useful. But I'd be content if the name of the current setting were switched to override to make the semantics more clear. We can always add in default at some later point if we really want. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server
On Mon, Jul 6, 2015 at 1:38 PM, Paul Durrant paul.durr...@citrix.com wrote: -Original Message- From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap Sent: 06 July 2015 13:36 To: Yu Zhang Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Paul Durrant; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On Mon, Jul 6, 2015 at 7:25 AM, Yu Zhang yu.c.zh...@linux.intel.com wrote: MAX_NR_IO_RANGES is used by ioreq server as the maximum number of discrete ranges to be tracked. This patch changes its value to 8k, so that more ranges can be tracked on next generation of Intel platforms in XenGT. Future patches can extend the limit to be toolstack tunable, and MAX_NR_IO_RANGES can serve as a default limit. Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com I said this at the Hackathon, and I'll say it here: I think this is the wrong approach. The problem here is not that you don't have enough memory ranges. The problem is that you are not tracking memory ranges, but individual pages. You need to make a new interface that allows you to tag individual gfns as p2m_mmio_write_dm, and then allow one ioreq server to get notifications for all such writes. I think that is conflating things. It's quite conceivable that more than one ioreq server will handle write_dm pages. If we had enough types to have two page types per server then I'd agree with you, but we don't. What's conflating things is using an interface designed for *device memory ranges* to instead *track writes to gfns*. Fundamentally the reason you have this explosion of device memory ranges is that what you're tracking isn't device memory, and it isn't a range. If your umbrella isn't very good at hammering in nails, the solution is to go get a hammer, not to add steel reinforcement to your umbrella. My suggestion is, short-term, to simply allow the first ioreq server to register for write_dm notifications to get notifications, and return an error if a second one tries to do so. If it becomes important for a single domain to have two ioreq servers that need this functionality, then we can come up with an internal Xen structure, *designed for gfns*, to track this. My suspicion is that it will never be needed. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 59040: regressions - FAIL
On Mon, 2015-07-06 at 13:47 +0100, Ian Jackson wrote: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965 http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html 2015-07-03 15:39:29 Z executing ssh ... root@172.16.144.41 xl list 2015-07-03 15:39:30 Z guest debianhvm.guest.osstest not present on this host 2015-07-03 15:39:30 Z FAILURE: guest unexpectedly shutdown; state is '' failure: guest unexpectedly shutdown; state is '' The xl log just says: Waiting for domain debianhvm.guest.osstest (domid 1) to die [pid 4412] Domain 1 has shut down, reason code 0 0x0 Action for shutdown reason code 0 is destroy Domain 1 needs to be cleaned up: destroying the domain Done. Exiting now This is quite weird. I just spotted near the end of http://logs.test-lab.xenproject.org/osstest/logs/59040/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/serial-italia1.log that the BIOS failed to find a device to boot from, for some reason (which is still weird)... Jul 3 15:38:29.941066 (d1) HVM Loader Jul 3 15:38:29.941085 (d1) Detected Xen v4.6-unstable Jul 3 15:38:29.949058 (d1) Xenbus rings @0xfeffc000, event channel 1 Jul 3 15:38:29.949105 (d1) System requested ROMBIOS Jul 3 15:38:29.949145 (d1) CPU speed is 3093 MHz Jul 3 15:38:29.957103 (d1) Relocating guest memory for lowmem MMIO space enabled Jul 3 15:38:29.957138 (XEN) irq.c:276: Dom1 PCI link 0 changed 0 - 5 Jul 3 15:38:29.965066 (d1) PCI-ISA link 0 routed to IRQ5 Jul 3 15:38:29.965085 (XEN) irq.c:276: Dom1 PCI link 1 changed 0 - 10 Jul 3 15:38:29.973094 (d1) PCI-ISA link 1 routed to IRQ10 Jul 3 15:38:29.973113 (XEN) irq.c:276: Dom1 PCI link 2 changed 0 - 11 Jul 3 15:38:29.981088 (d1) PCI-ISA link 2 routed to IRQ11 Jul 3 15:38:29.981132 (XEN) irq.c:276: Dom1 PCI link 3 changed 0 - 5 Jul 3 15:38:29.989050 (d1) PCI-ISA link 3 routed to IRQ5 Jul 3 15:38:29.989087 (d1) pci dev 01:2 INTD-IRQ5 Jul 3 15:38:29.989102 (d1) pci dev 01:3 INTA-IRQ10 Jul 3 15:38:29.997056 (d1) pci dev 03:0 INTA-IRQ5 Jul 3 15:38:29.997072 (d1) pci dev 04:0 INTA-IRQ5 Jul 3 15:38:29.997086 (d1) No RAM in high memory; setting high_mem resource base to 1 Jul 3 15:38:30.005050 (d1) pci dev 02:0 bar 10 size 00200: 0f008 Jul 3 15:38:30.013064 (d1) pci dev 03:0 bar 14 size 00100: 0f208 Jul 3 15:38:30.013088 (d1) pci dev 02:0 bar 14 size 01000: 0f300 Jul 3 15:38:30.021068 (d1) pci dev 03:0 bar 10 size 00100: 0c001 Jul 3 15:38:30.029048 (d1) pci dev 04:0 bar 10 size 00100: 0c101 Jul 3 15:38:30.029068 (d1) pci dev 04:0 bar 14 size 00100: 0f3001000 Jul 3 15:38:30.037043 (d1) pci dev 01:2 bar 20 size 00020: 0c201 Jul 3 15:38:30.037076 (d1) pci dev 01:1 bar 20 size 00010: 0c221 Jul 3 15:38:30.045054 (d1) Multiprocessor initialisation: Jul 3 15:38:30.045093 (d1) - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. Jul 3 15:38:30.053063 (d1) - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. Jul 3 15:38:30.061060 (d1) Testing HVM environment: Jul 3 15:38:30.061098 (d1) - REP INSB across page boundaries ... passed Jul 3 15:38:30.069053 (d1) - GS base MSRs and SWAPGS ... passed Jul 3 15:38:30.069087 (d1) Passed 2 of 2 tests Jul 3 15:38:30.069122 (d1) Writing SMBIOS tables ... Jul 3 15:38:30.077038 (d1) Loading ROMBIOS ... Jul 3 15:38:30.077071 (d1) 16892 bytes of ROMBIOS high-memory extensions: Jul 3 15:38:30.085038 (d1) Relocating to 0xfc001000-0xfc0051fc ... done Jul 3 15:38:30.085077 (d1) Creating MP tables ... Jul 3 15:38:30.093048 (d1) Loading Cirrus VGABIOS ... Jul 3 15:38:30.093079 (d1) Loading PCI Option ROM ... Jul 3 15:38:30.093106 (d1) - Manufacturer: http://ipxe.org Jul 3 15:38:30.101089 (d1) - Product name: iPXE Jul 3 15:38:30.101118 (d1) Option ROMs: Jul 3 15:38:30.101157 (d1) c-c8fff: VGA BIOS Jul 3 15:38:30.109054 (d1) c9000-d8fff: Etherboot ROM Jul 3 15:38:30.109070 (d1) Loading ACPI ... Jul 3 15:38:30.109084 (d1) vm86 TSS at fc011480 Jul 3 15:38:30.109121 (d1) BIOS map: Jul 3 15:38:30.117085 (d1) f-f: Main BIOS Jul 3 15:38:30.117114 (d1) E820 table: Jul 3 15:38:30.117138 (d1) [00]: : - :0009e000: RAM Jul 3 15:38:30.125089 (d1) [01]: :0009e000 - :000a: RESERVED Jul 3 15:38:30.125113 (d1) HOLE: :000a - :000e Jul 3 15:38:30.133060 (d1) [02]: :000e - :0010: RESERVED Jul 3 15:38:30.141086 (d1) [03]: :0010 - :2fc0: RAM Jul 3 15:38:30.141104 (d1) HOLE: :2fc0 - :fc00 Jul 3 15:38:30.149034 (d1) [04]: :fc00 - 0001:: RESERVED Jul 3 15:38:30.149079 (d1) Invoking ROMBIOS ... Jul 3 15:38:30.157028 (XEN) stdvga.c:147:d1v0 entering stdvga and caching modes Jul 3 15:38:30.157075 (d1) VGABios $Id:
Re: [Xen-devel] [PATCH] tools: libxl: allow permissive qemu-upstream pci passthrough.
On Fri, Jul 03, 2015 at 03:49:29PM +0100, Ian Campbell wrote: On Tue, 2015-06-02 at 16:47 +0100, Ian Campbell wrote: Anyone fancy (n)acking this followup to XSA-131? I think we probably want this for 4.6. From c395657b03a1e2b7616d987e7078694874981979 Mon Sep 17 00:00:00 2001 From: Ian Campbell ian.campb...@citrix.com Date: Mon, 1 Jun 2015 11:32:23 +0100 Subject: [PATCH] tools: libxl: allow permissive qemu-upstream pci passthrough. EMBARGOED UNTIL 2015-06-02 12:00 (WITH XSA-131 ET AL) Since XSA-131 qemu-xen now restricts access to PCI cfg by default. In order to allow local configuration of the existing libxl_device_pci permissive flag needs to be plumbed through via the new QMP property added by the XSA-131 patches. Versions of QEMU prior to XSA-131 did not support this permissive property, so we only pass it if it is true. Older versions only supported permissive mode. qemu-xen-traditional already supports the permissive mode setting via xenstore. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Anthony PERARD anthony.per...@citrix.com Acked-by: Anthony PERARD anthony.per...@citrix.com --- v2: Only set argument if permissive==true. --- tools/libxl/libxl_qmp.c | 12 1 file changed, 12 insertions(+) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 9aa7e2e..6484f5e 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -849,6 +849,18 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) QMP_PARAMETERS_SPRINTF(args, addr, %x.%x, PCI_SLOT(pcidev-vdevfn), PCI_FUNC(pcidev-vdevfn)); } +/* + * Version of QEMU prior to the XSA-131 fix did not support this + * property and were effectively always in permissive mode. The + * fix for XSA-131 switched the default to be restricted by + * default and added the permissive property. + * + * Therefore in order to support both old and new QEMU we only set + * the permissive flag if it is true. Users of older QEMU have no + * reason to set the flag so this is ok. + */ +if (pcidev-permissive) +qmp_parameters_add_bool(gc, args, permissive, true); rc = qmp_synchronous_send(qmp, device_add, args, NULL, NULL, qmp-timeout); -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server
-Original Message- From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap Sent: 06 July 2015 13:50 To: Paul Durrant Cc: Yu Zhang; xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On Mon, Jul 6, 2015 at 1:38 PM, Paul Durrant paul.durr...@citrix.com wrote: -Original Message- From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap Sent: 06 July 2015 13:36 To: Yu Zhang Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Paul Durrant; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On Mon, Jul 6, 2015 at 7:25 AM, Yu Zhang yu.c.zh...@linux.intel.com wrote: MAX_NR_IO_RANGES is used by ioreq server as the maximum number of discrete ranges to be tracked. This patch changes its value to 8k, so that more ranges can be tracked on next generation of Intel platforms in XenGT. Future patches can extend the limit to be toolstack tunable, and MAX_NR_IO_RANGES can serve as a default limit. Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com I said this at the Hackathon, and I'll say it here: I think this is the wrong approach. The problem here is not that you don't have enough memory ranges. The problem is that you are not tracking memory ranges, but individual pages. You need to make a new interface that allows you to tag individual gfns as p2m_mmio_write_dm, and then allow one ioreq server to get notifications for all such writes. I think that is conflating things. It's quite conceivable that more than one ioreq server will handle write_dm pages. If we had enough types to have two page types per server then I'd agree with you, but we don't. What's conflating things is using an interface designed for *device memory ranges* to instead *track writes to gfns*. What's the difference? Are you asserting that all device memory ranges have read side effects and therefore write_dm is not a reasonable optimization to use? I would not want to make that assertion. Paul Fundamentally the reason you have this explosion of device memory ranges is that what you're tracking isn't device memory, and it isn't a range. If your umbrella isn't very good at hammering in nails, the solution is to go get a hammer, not to add steel reinforcement to your umbrella. My suggestion is, short-term, to simply allow the first ioreq server to register for write_dm notifications to get notifications, and return an error if a second one tries to do so. If it becomes important for a single domain to have two ioreq servers that need this functionality, then we can come up with an internal Xen structure, *designed for gfns*, to track this. My suspicion is that it will never be needed. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] Two PV vNUMA patches
The first one is just cosmetic change. The second patch fixes a bug. Wei Liu (2): libxc: remove trailing newline in xc_dom_panic format string libxc: fix PV vNUMA guest memory allocation tools/libxc/xc_dom_x86.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] libxc: remove trailing newline in xc_dom_panic format string
xc_dom_panic prints more information after user supplied strings, so
don't print a newline.
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/xc_dom_x86.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 920fe42..acd7b3f 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -863,7 +863,7 @@ int arch_setup_meminit(struct xc_dom_image *dom)
if ( total != dom-total_pages )
{
xc_dom_panic(dom-xch, XC_INTERNAL_ERROR,
- %s: vNUMA page count mismatch (0x%PRIpfn !=
0x%PRIpfn)\n,
+ %s: vNUMA page count mismatch (0x%PRIpfn !=
0x%PRIpfn),
__func__, total, dom-total_pages);
return -EINVAL;
}
@@ -936,11 +936,11 @@ int arch_setup_meminit(struct xc_dom_image *dom)
{
if ( pnode != XC_NUMA_NO_NODE )
xc_dom_panic(dom-xch, XC_INTERNAL_ERROR,
- %s: failed to allocate 0x%PRIx64 pages
(v=%d, p=%d)\n,
+ %s: failed to allocate 0x%PRIx64 pages
(v=%d, p=%d),
__func__, pages, i, pnode);
else
xc_dom_panic(dom-xch, XC_INTERNAL_ERROR,
- %s: failed to allocate 0x%PRIx64
pages\n,
+ %s: failed to allocate 0x%PRIx64
pages,
__func__, pages);
return rc;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] libxc: fix PV vNUMA guest memory allocation
In 415b58c1 (tools/libxc: Batch memory allocations for PV guests) the
number of super pages is calculated with the number of total pages. That
is wrong. It breaks PV guest vNUMA. The correct number of super pages
should be derived from the number of pages within that virtual NUMA
node.
Also change the name and type of super page variable to match the naming
convention and type of normal page variable. Make the necessary
adjustment to make code compile.
Reported-by: Dario Faggioli dario.faggi...@citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
---
Cc: Ross Lagerwall ross.lagerw...@citrix.com
---
tools/libxc/xc_dom_x86.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index acd7b3f..faabe96 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -879,9 +879,8 @@ int arch_setup_meminit(struct xc_dom_image *dom)
for ( i = 0; i nr_vmemranges; i++ )
{
unsigned int memflags;
-uint64_t pages;
+uint64_t pages, super_pages;
unsigned int pnode = vnode_to_pnode[vmemranges[i].nid];
-int nr_spages = dom-total_pages SUPERPAGE_PFN_SHIFT;
xen_pfn_t extents[SUPERPAGE_BATCH_SIZE];
xen_pfn_t pfn_base_idx;
@@ -891,15 +890,16 @@ int arch_setup_meminit(struct xc_dom_image *dom)
pages = (vmemranges[i].end - vmemranges[i].start)
PAGE_SHIFT;
+super_pages = pages SUPERPAGE_PFN_SHIFT;
pfn_base = vmemranges[i].start PAGE_SHIFT;
for ( pfn = pfn_base; pfn pfn_base+pages; pfn++ )
dom-p2m_host[pfn] = pfn;
pfn_base_idx = pfn_base;
-while (nr_spages) {
-int count = min(nr_spages, SUPERPAGE_BATCH_SIZE);
-nr_spages -= count;
+while (super_pages) {
+int count = min_t(uint64_t, super_pages, SUPERPAGE_BATCH_SIZE);
+super_pages -= count;
for ( pfn = pfn_base_idx, j = 0;
pfn pfn_base_idx + (count SUPERPAGE_PFN_SHIFT);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 59040: regressions - FAIL
On Mon, Jul 06, 2015 at 01:57:28PM +0100, Ian Campbell wrote: On Mon, 2015-07-06 at 13:47 +0100, Ian Jackson wrote: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965 http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html 2015-07-03 15:39:29 Z executing ssh ... root@172.16.144.41 xl list 2015-07-03 15:39:30 Z guest debianhvm.guest.osstest not present on this host 2015-07-03 15:39:30 Z FAILURE: guest unexpectedly shutdown; state is '' failure: guest unexpectedly shutdown; state is '' The xl log just says: Waiting for domain debianhvm.guest.osstest (domid 1) to die [pid 4412] Domain 1 has shut down, reason code 0 0x0 Action for shutdown reason code 0 is destroy Domain 1 needs to be cleaned up: destroying the domain Done. Exiting now This is quite weird. I just spotted near the end of http://logs.test-lab.xenproject.org/osstest/logs/59040/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/serial-italia1.log that the BIOS failed to find a device to boot from, for some reason (which is still weird)... Jul 3 15:38:29.941066 (d1) HVM Loader Jul 3 15:38:29.941085 (d1) Detected Xen v4.6-unstable Jul 3 15:38:29.949058 (d1) Xenbus rings @0xfeffc000, event channel 1 Jul 3 15:38:29.949105 (d1) System requested ROMBIOS Jul 3 15:38:29.949145 (d1) CPU speed is 3093 MHz Jul 3 15:38:29.957103 (d1) Relocating guest memory for lowmem MMIO space enabled Jul 3 15:38:29.957138 (XEN) irq.c:276: Dom1 PCI link 0 changed 0 - 5 Jul 3 15:38:29.965066 (d1) PCI-ISA link 0 routed to IRQ5 Jul 3 15:38:29.965085 (XEN) irq.c:276: Dom1 PCI link 1 changed 0 - 10 Jul 3 15:38:29.973094 (d1) PCI-ISA link 1 routed to IRQ10 Jul 3 15:38:29.973113 (XEN) irq.c:276: Dom1 PCI link 2 changed 0 - 11 Jul 3 15:38:29.981088 (d1) PCI-ISA link 2 routed to IRQ11 Jul 3 15:38:29.981132 (XEN) irq.c:276: Dom1 PCI link 3 changed 0 - 5 Jul 3 15:38:29.989050 (d1) PCI-ISA link 3 routed to IRQ5 Jul 3 15:38:29.989087 (d1) pci dev 01:2 INTD-IRQ5 Jul 3 15:38:29.989102 (d1) pci dev 01:3 INTA-IRQ10 Jul 3 15:38:29.997056 (d1) pci dev 03:0 INTA-IRQ5 Jul 3 15:38:29.997072 (d1) pci dev 04:0 INTA-IRQ5 Jul 3 15:38:29.997086 (d1) No RAM in high memory; setting high_mem resource base to 1 Jul 3 15:38:30.005050 (d1) pci dev 02:0 bar 10 size 00200: 0f008 Jul 3 15:38:30.013064 (d1) pci dev 03:0 bar 14 size 00100: 0f208 Jul 3 15:38:30.013088 (d1) pci dev 02:0 bar 14 size 01000: 0f300 Jul 3 15:38:30.021068 (d1) pci dev 03:0 bar 10 size 00100: 0c001 Jul 3 15:38:30.029048 (d1) pci dev 04:0 bar 10 size 00100: 0c101 Jul 3 15:38:30.029068 (d1) pci dev 04:0 bar 14 size 00100: 0f3001000 Jul 3 15:38:30.037043 (d1) pci dev 01:2 bar 20 size 00020: 0c201 Jul 3 15:38:30.037076 (d1) pci dev 01:1 bar 20 size 00010: 0c221 Jul 3 15:38:30.045054 (d1) Multiprocessor initialisation: Jul 3 15:38:30.045093 (d1) - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. Jul 3 15:38:30.053063 (d1) - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. Jul 3 15:38:30.061060 (d1) Testing HVM environment: Jul 3 15:38:30.061098 (d1) - REP INSB across page boundaries ... passed Jul 3 15:38:30.069053 (d1) - GS base MSRs and SWAPGS ... passed Jul 3 15:38:30.069087 (d1) Passed 2 of 2 tests Jul 3 15:38:30.069122 (d1) Writing SMBIOS tables ... Jul 3 15:38:30.077038 (d1) Loading ROMBIOS ... Jul 3 15:38:30.077071 (d1) 16892 bytes of ROMBIOS high-memory extensions: Jul 3 15:38:30.085038 (d1) Relocating to 0xfc001000-0xfc0051fc ... done Jul 3 15:38:30.085077 (d1) Creating MP tables ... Jul 3 15:38:30.093048 (d1) Loading Cirrus VGABIOS ... Jul 3 15:38:30.093079 (d1) Loading PCI Option ROM ... Jul 3 15:38:30.093106 (d1) - Manufacturer: http://ipxe.org Jul 3 15:38:30.101089 (d1) - Product name: iPXE Jul 3 15:38:30.101118 (d1) Option ROMs: Jul 3 15:38:30.101157 (d1) c-c8fff: VGA BIOS Jul 3 15:38:30.109054 (d1) c9000-d8fff: Etherboot ROM Jul 3 15:38:30.109070 (d1) Loading ACPI ... Jul 3 15:38:30.109084 (d1) vm86 TSS at fc011480 Jul 3 15:38:30.109121 (d1) BIOS map: Jul 3 15:38:30.117085 (d1) f-f: Main BIOS Jul 3 15:38:30.117114 (d1) E820 table: Jul 3 15:38:30.117138 (d1) [00]: : - :0009e000: RAM Jul 3 15:38:30.125089 (d1) [01]: :0009e000 - :000a: RESERVED Jul 3 15:38:30.125113 (d1) HOLE: :000a - :000e Jul 3 15:38:30.133060 (d1) [02]: :000e - :0010: RESERVED Jul 3 15:38:30.141086 (d1) [03]: :0010 - :2fc0: RAM Jul 3 15:38:30.141104 (d1) HOLE: :2fc0 - :fc00 Jul 3 15:38:30.149034 (d1) [04]: :fc00 - 0001:: RESERVED Jul 3
Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server
On 07/06/2015 02:09 PM, Paul Durrant wrote: -Original Message- From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap Sent: 06 July 2015 13:50 To: Paul Durrant Cc: Yu Zhang; xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On Mon, Jul 6, 2015 at 1:38 PM, Paul Durrant paul.durr...@citrix.com wrote: -Original Message- From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap Sent: 06 July 2015 13:36 To: Yu Zhang Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich; Andrew Cooper; Paul Durrant; Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server On Mon, Jul 6, 2015 at 7:25 AM, Yu Zhang yu.c.zh...@linux.intel.com wrote: MAX_NR_IO_RANGES is used by ioreq server as the maximum number of discrete ranges to be tracked. This patch changes its value to 8k, so that more ranges can be tracked on next generation of Intel platforms in XenGT. Future patches can extend the limit to be toolstack tunable, and MAX_NR_IO_RANGES can serve as a default limit. Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com I said this at the Hackathon, and I'll say it here: I think this is the wrong approach. The problem here is not that you don't have enough memory ranges. The problem is that you are not tracking memory ranges, but individual pages. You need to make a new interface that allows you to tag individual gfns as p2m_mmio_write_dm, and then allow one ioreq server to get notifications for all such writes. I think that is conflating things. It's quite conceivable that more than one ioreq server will handle write_dm pages. If we had enough types to have two page types per server then I'd agree with you, but we don't. What's conflating things is using an interface designed for *device memory ranges* to instead *track writes to gfns*. What's the difference? Are you asserting that all device memory ranges have read side effects and therefore write_dm is not a reasonable optimization to use? I would not want to make that assertion. Using write_dm is not the problem; it's having thousands of memory ranges of 4k each that I object to. Which is why I suggested adding an interface to request updates to gfns (by marking them write_dm), rather than abusing the io range interface. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] libxc: fix PV vNUMA guest memory allocation
On Mon, Jul 06, 2015 at 02:26:37PM +0100, Andrew Cooper wrote:
On 06/07/15 14:17, Wei Liu wrote:
In 415b58c1 (tools/libxc: Batch memory allocations for PV guests) the
number of super pages is calculated with the number of total pages. That
is wrong. It breaks PV guest vNUMA. The correct number of super pages
should be derived from the number of pages within that virtual NUMA
node.
Also change the name and type of super page variable to match the naming
convention and type of normal page variable. Make the necessary
adjustment to make code compile.
Reported-by: Dario Faggioli dario.faggi...@citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
---
Cc: Ross Lagerwall ross.lagerw...@citrix.com
---
tools/libxc/xc_dom_x86.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index acd7b3f..faabe96 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -879,9 +879,8 @@ int arch_setup_meminit(struct xc_dom_image *dom)
for ( i = 0; i nr_vmemranges; i++ )
{
unsigned int memflags;
-uint64_t pages;
+uint64_t pages, super_pages;
unsigned int pnode = vnode_to_pnode[vmemranges[i].nid];
-int nr_spages = dom-total_pages SUPERPAGE_PFN_SHIFT;
xen_pfn_t extents[SUPERPAGE_BATCH_SIZE];
xen_pfn_t pfn_base_idx;
@@ -891,15 +890,16 @@ int arch_setup_meminit(struct xc_dom_image *dom)
pages = (vmemranges[i].end - vmemranges[i].start)
PAGE_SHIFT;
+super_pages = pages SUPERPAGE_PFN_SHIFT;
pfn_base = vmemranges[i].start PAGE_SHIFT;
for ( pfn = pfn_base; pfn pfn_base+pages; pfn++ )
dom-p2m_host[pfn] = pfn;
pfn_base_idx = pfn_base;
-while (nr_spages) {
-int count = min(nr_spages, SUPERPAGE_BATCH_SIZE);
-nr_spages -= count;
+while (super_pages) {
+int count = min_t(uint64_t, super_pages,
SUPERPAGE_BATCH_SIZE);
This line alone indicates that int is not an appropriate type for
count. unsigned int as as an absolute minimum, as it will be bounded to
SUPERPAGE_BATCH_SIZE.
Yes, I also need to make count uint64_t.
Wei.
~Andrew
+super_pages -= count;
for ( pfn = pfn_base_idx, j = 0;
pfn pfn_base_idx + (count SUPERPAGE_PFN_SHIFT);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 59040: regressions - FAIL
On Mon, 2015-07-06 at 14:23 +0100, Wei Liu wrote: I saw this bug since the introduction of amd64-i386 stubdom test case. Now it looks like intermittent, i.e. we failed at the beginning, passed at some point, now it failed again. http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html gives the history of it. It looks as if italia* and chardonnay* might be susceptible but really I don't think there is sufficient information to draw any particular conclusion wrt the frequency of this bug or whether it might be host specific or not, since the passes on other hosts are general singletons. The 64-bit dom0 case is at http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html I'm not sure what, if anything, it tells us though. It does look to be more less prone to errors (it having now hit merlot notwithstanding, although it seems to reliably pass the install phase there). One potentially interesting case is that in the 32-bit dom0 case the stubdom is also 32-bit, while in the other case the stubdom is 64-bit. I'm not convinced using a 32-bit stubdom is the right choice, but I suppose it ought to work. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] libxc: fix PV vNUMA guest memory allocation
On Mon, Jul 06, 2015 at 02:33:35PM +0100, Ross Lagerwall wrote:
On 07/06/2015 02:30 PM, Wei Liu wrote:
On Mon, Jul 06, 2015 at 02:26:37PM +0100, Andrew Cooper wrote:
On 06/07/15 14:17, Wei Liu wrote:
In 415b58c1 (tools/libxc: Batch memory allocations for PV guests) the
number of super pages is calculated with the number of total pages. That
is wrong. It breaks PV guest vNUMA. The correct number of super pages
should be derived from the number of pages within that virtual NUMA
node.
Also change the name and type of super page variable to match the naming
convention and type of normal page variable. Make the necessary
adjustment to make code compile.
Reported-by: Dario Faggioli dario.faggi...@citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
---
Cc: Ross Lagerwall ross.lagerw...@citrix.com
---
tools/libxc/xc_dom_x86.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index acd7b3f..faabe96 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -879,9 +879,8 @@ int arch_setup_meminit(struct xc_dom_image *dom)
for ( i = 0; i nr_vmemranges; i++ )
{
unsigned int memflags;
-uint64_t pages;
+uint64_t pages, super_pages;
unsigned int pnode = vnode_to_pnode[vmemranges[i].nid];
-int nr_spages = dom-total_pages SUPERPAGE_PFN_SHIFT;
xen_pfn_t extents[SUPERPAGE_BATCH_SIZE];
xen_pfn_t pfn_base_idx;
@@ -891,15 +890,16 @@ int arch_setup_meminit(struct xc_dom_image *dom)
pages = (vmemranges[i].end - vmemranges[i].start)
PAGE_SHIFT;
+super_pages = pages SUPERPAGE_PFN_SHIFT;
pfn_base = vmemranges[i].start PAGE_SHIFT;
for ( pfn = pfn_base; pfn pfn_base+pages; pfn++ )
dom-p2m_host[pfn] = pfn;
pfn_base_idx = pfn_base;
-while (nr_spages) {
-int count = min(nr_spages, SUPERPAGE_BATCH_SIZE);
-nr_spages -= count;
+while (super_pages) {
+int count = min_t(uint64_t, super_pages,
SUPERPAGE_BATCH_SIZE);
This line alone indicates that int is not an appropriate type for
count. unsigned int as as an absolute minimum, as it will be bounded to
SUPERPAGE_BATCH_SIZE.
Yes, I also need to make count uint64_t.
Is this needed? count should never be larger than 512 (aka
SUPERPAGE_BATCH_SIZE).
Maybe uint64_t is overkill but I want to be as consistent as possible.
Wei.
--
Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 2/2] ts-debian-hvm-install: Arrange for installed guest to use a serial console
So that the guest boot will be logged somewhere useful (the qemu-dm
log).
It still seems to pickup a quiet from somewhere, so it's not as
useful as it might be, but it is an improvement.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
ts-debian-hvm-install | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index ea2d1ad..f05b1a7 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -98,19 +98,22 @@ END
}
sub grub_cfg () {
-
+# See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for
+# why console= is repeated.
return END;
set default=0
set timeout=5
menuentry 'debian guest auto Install' {
-linux /install.amd/vmlinuz console=vga console=ttyS0,115200n8
preseed/file=/preseed.cfg
+linux /install.amd/vmlinuz console=vga preseed/file=/preseed.cfg
console=ttyS0,115200n8 -- console=ttyS0,115200n8
initrd /install.amd/initrd.gz
}
END
}
sub isolinux_cfg () {
+# See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for
+# why console= is repeated.
return END;
default autoinstall
prompt 0
@@ -118,7 +121,7 @@ sub isolinux_cfg () {
label autoinstall
kernel /install.amd/vmlinuz
-append video=vesa:ywrap,mtrr vga=788 console=ttyS0,115200n8
preseed/file=/preseed.cfg initrd=/install.amd/initrd.gz
+append video=vesa:ywrap,mtrr vga=788 preseed/file=/preseed.cfg
initrd=/install.amd/initrd.gz console=ttyS0,115200n8 -- console=ttyS0,115200n8
END
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 1/2] When invoking xl create do so verbosely
xend.pm inherits from xl.pm, but I don't know what (if any) support
for verbosity it has, so the xm invocation is unchanged.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Toolstack/xend.pm | 1 +
Osstest/Toolstack/xl.pm | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 1d5d059..972b3b1 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -30,6 +30,7 @@ sub new {
NewDaemons = [qw(xend)],
OldDaemonInitd = 'xend',
_Command = 'xm',
+ _VerboseCommand = 'xm', # no verbosity here
Dom0MemFixed = 1,
}, $class;
}
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 23328d3..3c3d348 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -29,6 +29,7 @@ sub new {
NewDaemons = [],
Dom0MemFixed = 1,
_Command = 'xl',
+ _VerboseCommand = 'xl -vvv',
RestoreNeedsConfig = 1,
}, $class;
}
@@ -42,7 +43,7 @@ sub destroy ($$) {
sub create ($$) {
my ($self,$gho) = @_;
my $cfg = $gho-{CfgPath};
-target_cmd_root($self-{Host}, $self-{_Command}. create $cfg, 100);
+target_cmd_root($self-{Host}, $self-{_VerboseCommand}. create $cfg,
100);
}
sub consolecmd ($$) {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/32] libxc: remove dead HVM building code
On 03/07/15 12:34, Roger Pau Monne wrote: Remove xc_hvm_build_x86.c and xc_hvm_build_arm.c since xc_hvm_build is not longer used in order to create HVM guests. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com In principle, very much +1 However, I suspect this wants functional testing from the ARM folks. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] libxc: fix PV vNUMA guest memory allocation
In 415b58c1 (tools/libxc: Batch memory allocations for PV guests) the
number of super pages is calculated with the number of total pages. That
is wrong. It breaks PV guest vNUMA. The correct number of super pages
should be derived from the number of pages within that virtual NUMA
node.
Also change the name and type of super page variable to match the naming
convention and type of normal page variable. Make the necessary
adjustment to make code compile.
Reported-by: Dario Faggioli dario.faggi...@citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Reviewed-by: Ross Lagerwall ross.lagerw...@citrix.com
---
v2: uint64_t for count variable for consistency, no functional changes wrt v1
so I retain the Reviewed-by tag.
---
tools/libxc/xc_dom_x86.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index acd7b3f..6a04399 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -879,9 +879,8 @@ int arch_setup_meminit(struct xc_dom_image *dom)
for ( i = 0; i nr_vmemranges; i++ )
{
unsigned int memflags;
-uint64_t pages;
+uint64_t pages, super_pages;
unsigned int pnode = vnode_to_pnode[vmemranges[i].nid];
-int nr_spages = dom-total_pages SUPERPAGE_PFN_SHIFT;
xen_pfn_t extents[SUPERPAGE_BATCH_SIZE];
xen_pfn_t pfn_base_idx;
@@ -891,15 +890,17 @@ int arch_setup_meminit(struct xc_dom_image *dom)
pages = (vmemranges[i].end - vmemranges[i].start)
PAGE_SHIFT;
+super_pages = pages SUPERPAGE_PFN_SHIFT;
pfn_base = vmemranges[i].start PAGE_SHIFT;
for ( pfn = pfn_base; pfn pfn_base+pages; pfn++ )
dom-p2m_host[pfn] = pfn;
pfn_base_idx = pfn_base;
-while (nr_spages) {
-int count = min(nr_spages, SUPERPAGE_BATCH_SIZE);
-nr_spages -= count;
+while (super_pages) {
+uint64_t count =
+min_t(uint64_t, super_pages,SUPERPAGE_BATCH_SIZE);
+super_pages -= count;
for ( pfn = pfn_base_idx, j = 0;
pfn pfn_base_idx + (count SUPERPAGE_PFN_SHIFT);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 2/3] xen/vm_event: Support for guest-requested events
On Mon, Jul 6, 2015 at 6:26 AM, Jan Beulich jbeul...@suse.com wrote:
On 30.06.15 at 16:48, tleng...@novetta.com wrote:
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -342,13 +342,15 @@ struct arch_domain
/* Monitor options */
struct {
-uint16_t write_ctrlreg_enabled : 4;
-uint16_t write_ctrlreg_sync : 4;
-uint16_t write_ctrlreg_onchangeonly : 4;
-uint16_t mov_to_msr_enabled : 1;
-uint16_t mov_to_msr_extended : 1;
-uint16_t singlestep_enabled : 1;
-uint16_t software_breakpoint_enabled : 1;
+uint32_t write_ctrlreg_enabled : 4;
+uint32_t write_ctrlreg_sync : 4;
+uint32_t write_ctrlreg_onchangeonly : 4;
+uint32_t mov_to_msr_enabled : 1;
+uint32_t mov_to_msr_extended : 1;
+uint32_t singlestep_enabled : 1;
+uint32_t software_breakpoint_enabled : 1;
+uint32_t request_enabled : 1;
+uint32_t request_sync: 1;
Can you please switch to plain unsigned int if you already have to
touch this? There's no reason I can see to use a fixed width integer
type here.
Ack, will make it plain int.
IMHO having it fix-width is easier to read when adding new elements to
see
how many bits we have left free. I would not want this changed unless
there
is a clear benefit to doing so.
I can't see what benefit using fixed widht types here is: Best
demonstrated with uint64_t, gcc doesn't honor the type of the
field anyway. And hence counting the number of left bits (with
some unknown definition of left) is quite pointless too - it's an
internal structure, and when a new bit field needs to be added,
it doesn't really matter whether it grows the structure (at least
no more than any other field addition).
Bottom line - no fixed width types when not really warranted,
please.
Jan
SGTM.
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy
On 06.07.15 at 15:34, tiejun.c...@intel.com wrote: I think we should go back here. I was involved in the design discussion, and from the very beginning I probably saw your plan but misunderstood it. I wouldn't be surprised if some others didn't quite understand what they were agreeing to. This way of doing things is different than the way we do it with most other options relating to pci devices (e.g., pci_permissive, pci_msitranslate, pci_sieze, c). All of those options use a default semantic: the domain-wide setting takes effect only if it's not set locally. If the syntax looks the same but the semantics is different, many people will be confused. If we're going to have the domain-wide policy override the per-device policy, then the naming should make that clear; for instance, override=(strict|relaxed|none), or strict_override=(1|0). Jan, What about this? This is involving our policy so please take a look at this as well. I don't think the way things get expressed in the domain config directly relates to what the policy is. How to best express things in the config I'd really like to leave to the tools maintainers. George, Actually we don't mean the domain-wide policy always override the per-device policy, or the per-device policy always override the per-device policy. Here we just take strict as the highest priority when it conflicts in two cases. As I said previously myself may not answer this very correctly but now I can recall or understand that one reason is that different devices can share one RMRR entry, so its possible that these two or more per-device policies are not same. So we need this particular rule which is not same as before. So I still prefer to keep our original implementation. If I'm missing something or wrong, please Jan correct me. I don't think I fully understand what you try to describe above; instead I think the global vs per-device settings should very much behave just like others (i.e. fallback to global if there is no per- device setting). Furthermore, didn't we settle on not allowing pass-through of devices sharing RMRRs unless specifically told to by the admin (in which case part of what you write above would seem irrelevant to me)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 59040: regressions - FAIL
On Mon, Jul 06, 2015 at 02:37:31PM +0100, Ian Campbell wrote: On Mon, 2015-07-06 at 14:23 +0100, Wei Liu wrote: I saw this bug since the introduction of amd64-i386 stubdom test case. Now it looks like intermittent, i.e. we failed at the beginning, passed at some point, now it failed again. http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html gives the history of it. It looks as if italia* and chardonnay* might be susceptible but really I don't think there is sufficient information to draw any particular conclusion wrt the frequency of this bug or whether it might be host specific or not, since the passes on other hosts are general singletons. Note that we do have one pass vs five fails on italia0. The same goes for chardonay0 (one pass vs four fails). It's really weird. The 64-bit dom0 case is at http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html I'm not sure what, if anything, it tells us though. It does look to be more less prone to errors (it having now hit merlot notwithstanding, although it seems to reliably pass the install phase there). One potentially interesting case is that in the 32-bit dom0 case the stubdom is also 32-bit, while in the other case the stubdom is 64-bit. I'm not convinced using a 32-bit stubdom is the right choice, but I suppose it ought to work. Yeah, it ought to work. But making it actually work requires much effort. I would say let's mark that failure none blocking for the moment. Wei. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] libxc: fix PV vNUMA guest memory allocation
On Mon, 2015-07-06 at 14:17 +0100, Wei Liu wrote: In 415b58c1 (tools/libxc: Batch memory allocations for PV guests) the number of super pages is calculated with the number of total pages. That is wrong. It breaks PV guest vNUMA. The correct number of super pages should be derived from the number of pages within that virtual NUMA node. Also change the name and type of super page variable to match the naming convention and type of normal page variable. Make the necessary adjustment to make code compile. Reported-by: Dario Faggioli dario.faggi...@citrix.com Signed-off-by: Wei Liu wei.l...@citrix.com Thanks for looking at this so quickly. I think I've understood that you're sending a v2, so I'll test that one. Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 0/6] xen: arm: Parse PCI DT nodes' ranges and interrupt-map
On Mon, 2015-07-06 at 12:04 +0100, Julien Grall wrote: Hi Ian, On 03/07/15 16:55, Ian Campbell wrote: This series adds parsing of the DT ranges and interrupt-map properties for PCI devices, these contain the MMIOs and IRQs used by children on the bus. This replaces the specific mapping stuff on xgene. This is a quick respin based on Julien's comments on v4 which were missed in v5. I added my reviewed-by on all the patch It occurred to me that given the reason for sending v6 I probably ought to have dropped the R-by from patch #1. Are you happy for it to remain in v7 (based on your comments here) or shall I drop it and resend? and had 3 minors comments on #4. Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 1/2] When invoking xl create do so verbosely
Ian Campbell writes ([PATCH OSSTEST 1/2] When invoking xl create do so verbosely): xend.pm inherits from xl.pm, but I don't know what (if any) support for verbosity it has, so the xm invocation is unchanged. Acked-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
