Re: [Xen-devel] [PATCH 1/4] xen/blkback: don't keep persistent grants too long
On 06/08/18 17:58, Roger Pau Monné wrote:
> On Mon, Aug 06, 2018 at 01:33:59PM +0200, Juergen Gross wrote:
>> Persistent grants are allocated until a threshold per ring is being
>> reached. Those grants won't be freed until the ring is being destroyed
>> meaning there will be resources kept busy which might no longer be
>> used.
>>
>> Instead of freeing only persistent grants until the threshold is
>> reached add a timestamp and remove all persistent grants not having
>> been in use for a minute.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> drivers/block/xen-blkback/blkback.c | 77
>> +++--
>> drivers/block/xen-blkback/common.h | 1 +
>> 2 files changed, 50 insertions(+), 28 deletions(-)
>
> You should document this new parameter in
> Documentation/ABI/testing/sysfs-driver-xen-blkback.
Yes.
>
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c
>> b/drivers/block/xen-blkback/blkback.c
>> index b55b245e8052..485e3ecab144 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -84,6 +84,18 @@ MODULE_PARM_DESC(max_persistent_grants,
>> "Maximum number of grants to map persistently");
>>
>> /*
>> + * How long a persistent grant is allowed to remain allocated without being
>> in
>> + * use. The time is in seconds, 0 means indefinitely long.
>> + */
>> +
>> +unsigned int xen_blkif_pgrant_timeout = 60;
>> +module_param_named(persistent_grant_unused_seconds,
>> xen_blkif_pgrant_timeout,
>> + uint, 0644);
>> +MODULE_PARM_DESC(persistent_grant_unused_seconds,
>> + "Time in seconds an unused persistent grant is allowed to "
>> + "remain allocated. Default is 60, 0 means unlimited.");
>> +
>> +/*
>> * Maximum number of rings/queues blkback supports, allow as many queues as
>> there
>> * are CPUs if user has not specified a value.
>> */
>> @@ -123,6 +135,13 @@ module_param(log_stats, int, 0644);
>> /* Number of free pages to remove on each call to gnttab_free_pages */
>> #define NUM_BATCH_FREE_PAGES 10
>>
>> +static inline bool persistent_gnt_timeout(struct persistent_gnt
>> *persistent_gnt)
>> +{
>> +return xen_blkif_pgrant_timeout &&
>> + (jiffies - persistent_gnt->last_used >=
>> +HZ * xen_blkif_pgrant_timeout);
>> +}
>> +
>> static inline int get_free_page(struct xen_blkif_ring *ring, struct page
>> **page)
>> {
>> unsigned long flags;
>> @@ -278,6 +297,7 @@ static void put_persistent_gnt(struct xen_blkif_ring
>> *ring,
>> {
>> if(!test_bit(PERSISTENT_GNT_ACTIVE, persistent_gnt->flags))
>> pr_alert_ratelimited("freeing a grant already unused\n");
>> +persistent_gnt->last_used = jiffies;
>> set_bit(PERSISTENT_GNT_WAS_ACTIVE, persistent_gnt->flags);
>> clear_bit(PERSISTENT_GNT_ACTIVE, persistent_gnt->flags);
>> atomic_dec(&ring->persistent_gnt_in_use);
>> @@ -374,23 +394,23 @@ static void purge_persistent_gnt(struct xen_blkif_ring
>> *ring)
>> bool scan_used = false, clean_used = false;
>> struct rb_root *root;
>>
>> -if (ring->persistent_gnt_c < xen_blkif_max_pgrants ||
>> -(ring->persistent_gnt_c == xen_blkif_max_pgrants &&
>> -!ring->blkif->vbd.overflow_max_grants)) {
>> -goto out;
>> -}
>> -
>> if (work_busy(&ring->persistent_purge_work)) {
>> pr_alert_ratelimited("Scheduled work from previous purge is
>> still busy, cannot purge list\n");
>> goto out;
>> }
>>
>> -num_clean = (xen_blkif_max_pgrants / 100) * LRU_PERCENT_CLEAN;
>> -num_clean = ring->persistent_gnt_c - xen_blkif_max_pgrants + num_clean;
>> -num_clean = min(ring->persistent_gnt_c, num_clean);
>> -if ((num_clean == 0) ||
>> -(num_clean > (ring->persistent_gnt_c -
>> atomic_read(&ring->persistent_gnt_in_use
>> -goto out;
>> +if (ring->persistent_gnt_c < xen_blkif_max_pgrants ||
>> +(ring->persistent_gnt_c == xen_blkif_max_pgrants &&
>> +!ring->blkif->vbd.overflow_max_grants)) {
>> +num_clean = 0;
>> +} else {
>> +num_clean = (xen_blkif_max_pgrants / 100) * LRU_PERCENT_CLEAN;
>> +num_clean = ring->persistent_gnt_c - xen_blkif_max_pgrants +
>> +num_clean;
>> +num_clean = min(ring->persistent_gnt_c, num_clean);
>> +pr_debug("Going to purge at least %u persistent grants\n",
>> + num_clean);
>> +}
>>
>> /*
>> * At this point, we can assure that there will be no calls
>> @@ -401,9 +421,7 @@ static void purge_persistent_gnt(struct xen_blkif_ring
>> *ring)
>> * number of grants.
>> */
>>
>> -total = num_clean;
>> -
>> -pr_debug("Going to purge %u persistent grants\n", num_clean);
>> +total = 0;
>>
>> BUG_ON(!list_empty(&ring->persistent_purge_list));
>> root = &ring->persistent_gnts;
>> @@ -419,39 +437,42 @@ static v
[Xen-devel] Antw: Re: xen-tools-4.4.4 (SLES11): Unexpected error:
>>> George Dunlap schrieb am 06.08.2018 um 18:16 in >>> Nachricht : > On Thu, Aug 2, 2018 at 1:13 PM, Ulrich Windl > wrote: >> Hi! >> >> WHen using "xm list test12 -l" that seems to be in pvgrub state, I get this > error: > > Unfortunately Xen 4.4 is long out of security support, and xm/xend was > deprecated even in Xen 4.4. Have you tried using its replacement, xl? Hi! Thanks for responding! Actually Xen 4.4 being part of SLES11 is still under vendor support. And yes, I have tried xl once in the past, but didn't see an advantage, so I sticked to xm. BTW, while talking on it: Just recently I discovered that "xm list --long"'s "start_time" is the time the original VM was created (and not the time when the VM was locally created (think of live migration). However the "cpu_time" seems to cover the cpu on the local host (i.e. since migration) only. So when you try to get an average CPU usage, by dividing cpu_time by start_time, the numbers can be quite misleading. For example (numbers decoded, "95+20:33:53" meaning 95 days, 20 hours, 33 minutes, ...): name v01 online_vcpus 3 cpu_time 140934.85976 (1+15:08:54) start_time 1525341466.71 (Thu May 3 11:57:46 2018) uptime 8282033.2896 (95+20:33:53) CPU rate 0.0170169395394933 So is there a way to get the time of migration or the total time of cpu usage since initial creation? Regards, Ulrich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/4] xen/blkfront: cleanup stale persistent grants
On 06/08/18 18:16, Roger Pau Monné wrote:
> On Mon, Aug 06, 2018 at 01:34:01PM +0200, Juergen Gross wrote:
>> Add a periodic cleanup function to remove old persistent grants which
>> are no longer in use on the backend side. This avoids starvation in
>> case there are lots of persistent grants for a device which no longer
>> is involved in I/O business.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> drivers/block/xen-blkfront.c | 99
>> ++--
>> 1 file changed, 95 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index b5cedccb5d7d..19feb8835fc4 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -46,6 +46,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -121,6 +122,9 @@ static inline struct blkif_req *blkif_req(struct request
>> *rq)
>>
>> static DEFINE_MUTEX(blkfront_mutex);
>> static const struct block_device_operations xlvbd_block_fops;
>> +static struct delayed_work blkfront_work;
>> +static LIST_HEAD(info_list);
>> +static bool blkfront_work_active;
>>
>> /*
>> * Maximum number of segments in indirect requests, the actual value used by
>> @@ -216,6 +220,7 @@ struct blkfront_info
>> /* Save uncomplete reqs and bios for migration. */
>> struct list_head requests;
>> struct bio_list bio_list;
>> +struct list_head info_list;
>> };
>>
>> static unsigned int nr_minors;
>> @@ -1764,6 +1769,12 @@ static int write_per_ring_nodes(struct
>> xenbus_transaction xbt,
>> return err;
>> }
>>
>> +static void free_info(struct blkfront_info *info)
>> +{
>> +list_del(&info->info_list);
>> +kfree(info);
>> +}
>> +
>> /* Common code used when first setting up, and when resuming. */
>> static int talk_to_blkback(struct xenbus_device *dev,
>> struct blkfront_info *info)
>> @@ -1885,7 +1896,10 @@ static int talk_to_blkback(struct xenbus_device *dev,
>> destroy_blkring:
>> blkif_free(info, 0);
>>
>> -kfree(info);
>> +mutex_lock(&blkfront_mutex);
>> +free_info(info);
>> +mutex_unlock(&blkfront_mutex);
>> +
>> dev_set_drvdata(&dev->dev, NULL);
>>
>> return err;
>> @@ -1996,6 +2010,10 @@ static int blkfront_probe(struct xenbus_device *dev,
>> info->handle = simple_strtoul(strrchr(dev->nodename, '/')+1, NULL, 0);
>> dev_set_drvdata(&dev->dev, info);
>>
>> +mutex_lock(&blkfront_mutex);
>> +list_add(&info->info_list, &info_list);
>> +mutex_unlock(&blkfront_mutex);
>> +
>> return 0;
>> }
>>
>> @@ -2306,6 +2324,15 @@ static void blkfront_gather_backend_features(struct
>> blkfront_info *info)
>> if (indirect_segments <= BLKIF_MAX_SEGMENTS_PER_REQUEST)
>> indirect_segments = 0;
>> info->max_indirect_segments = indirect_segments;
>> +
>> +if (info->feature_persistent) {
>> +mutex_lock(&blkfront_mutex);
>> +if (!blkfront_work_active) {
>> +blkfront_work_active = true;
>> +schedule_delayed_work(&blkfront_work, HZ * 10);
>
> Does it make sense to provide a module parameter to rune the schedule
> of the cleanup routine?
I don't think this is something anyone would like to tune.
In case you think it should be tunable I can add a parameter, of course.
>
>> +}
>> +mutex_unlock(&blkfront_mutex);
>
> Is it really necessary to have the blkfront_work_active boolean? What
> happens if you queue the same delayed work more than once?
In case there is already work queued later calls of
schedule_delayed_work() will be ignored.
So yes, I can drop the global boolean (I still need a local flag in
blkfront_delay_work() for controlling the need to call
schedule_delayed_work() again).
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125778: trouble: blocked/broken/pass
flight 125778 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125778/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen e752f28409678ce3ade49986b39309178fb2a6d6 baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z5 days Failing since125741 2018-08-02 10:01:09 Z4 days7 attempts Testing same since 125772 2018-08-06 16:00:37 Z0 days5 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini jobs: build-arm64-xsm broken build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64-xsm broken broken-step build-arm64-xsm hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 480 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 12/15] x86: add iommu_op to enable modification of IOMMU mappings
> From: Paul Durrant
> Sent: Saturday, August 4, 2018 1:22 AM
>
> This patch adds an iommu_op which checks whether it is possible or
> safe for a domain to modify its own IOMMU mappings and, if so, creates
> a rangeset to track modifications.
Have to say that there might be a concept mismatch between us,
so I will stop review here until we get aligned on the basic
understanding.
What an IOMMU does is to provide DMA isolation between devices.
Each device can be hooked with a different translation structure
(representing a different bfn address space). Linux kernel uses this
mechanism to harden kernel drivers (through dma APIs). Multiple
devices can be also attached to the same address space, used by
hypervisor when devices are assigned to the same VM.
Now with pvIOMMU exposed to dom0, , dom0 could use it to harden
kernel drivers too. Then there will be multiple bfn address spaces:
- A default bfn address space created by Xen, where bfn = pfn
- multiple per-bdf bfn address spaces created by Dom0, where
bfn is completely irrelevant to pfn.
the default space should not be changed by Dom0. It is attached
to devices which dom0 doesn't enable pviommu mapping.
per-bdf address spaces can be changed by Dom0, attached to
devices which dom0 enables pviommu mapping. then pviommu ops
should accept a bdf parameter. and internally Xen needs to maintain
multiple page tables under dom0, and find a right page table according
to specified bdf to complete the operation.
Now your series look assuming always just one bfn address space
cross all assigned devices per domain... I'm not sure how it works.
Did I misunderstand anything?
>
> NOTE: The actual map and unmap operations are introduced by
> subsequent
> patches.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Julien Grall
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
>
> v4:
> - Set sync_iommu_pt to false instead of need_iommu.
>
> v2:
> - New in v2.
> ---
> xen/arch/x86/iommu_op.c | 42
> +
> xen/drivers/passthrough/iommu.c | 2 +-
> xen/drivers/passthrough/pci.c | 4 ++--
> xen/include/public/iommu_op.h | 6 ++
> xen/include/xen/iommu.h | 3 +++
> 5 files changed, 54 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/iommu_op.c b/xen/arch/x86/iommu_op.c
> index bcfcd49102..b29547bffd 100644
> --- a/xen/arch/x86/iommu_op.c
> +++ b/xen/arch/x86/iommu_op.c
> @@ -78,6 +78,42 @@ static int iommu_op_query_reserved(struct
> xen_iommu_op_query_reserved *op)
> return 0;
> }
>
> +static int iommu_op_enable_modification(void)
> +{
> +struct domain *currd = current->domain;
> +struct domain_iommu *iommu = dom_iommu(currd);
> +const struct iommu_ops *ops = iommu->platform_ops;
> +
> +/* Has modification already been enabled? */
> +if ( iommu->iommu_op_ranges )
> +return 0;
> +
> +/*
> + * The IOMMU mappings cannot be modified if:
> + * - the IOMMU is not enabled or,
> + * - the current domain is dom0 and tranlsation is disabled or,
> + * - HAP is enabled and the IOMMU shares the mappings.
> + */
> +if ( !iommu_enabled ||
> + (is_hardware_domain(currd) && iommu_passthrough) ||
> + iommu_use_hap_pt(currd) )
> +return -EACCES;
> +
> +/*
> + * The IOMMU implementation must provide the lookup method if
> + * modification of the mappings is to be supported.
> + */
> +if ( !ops->lookup_page )
> +return -EOPNOTSUPP;
> +
> +iommu->iommu_op_ranges = rangeset_new(currd, NULL, 0);
> +if ( !iommu->iommu_op_ranges )
> +return -ENOMEM;
> +
> +currd->sync_iommu_pt = 0; /* Disable synchronization */
> +return 0;
> +}
> +
> static void iommu_op(xen_iommu_op_t *op)
> {
> switch ( op->op )
> @@ -86,6 +122,10 @@ static void iommu_op(xen_iommu_op_t *op)
> op->status = iommu_op_query_reserved(&op->u.query_reserved);
> break;
>
> +case XEN_IOMMUOP_enable_modification:
> +op->status = iommu_op_enable_modification();
> +break;
> +
> default:
> op->status = -EOPNOTSUPP;
> break;
> @@ -98,6 +138,7 @@ int do_one_iommu_op(xen_iommu_op_buf_t *buf)
> size_t offset;
> static const size_t op_size[] = {
> [XEN_IOMMUOP_query_reserved] = sizeof(struct
> xen_iommu_op_query_reserved),
> +[XEN_IOMMUOP_enable_modification] = 0,
> };
> size_t size;
> int rc;
> @@ -184,6 +225,7 @@ int
> compat_one_iommu_op(compat_iommu_op_buf_t *buf)
> size_t offset;
> static const size_t op_size[] = {
> [XEN_IOMMUOP_query_reserved] = sizeof(struct
> compat_iommu_op_query_reserved),
> +[XEN_IOMMUOP_enable_modification] = 0,
> };
> size_t size;
> xen_iommu_op_t nat;
> diff --git a/xen/drivers/passthrough/iommu.c
> b/xen/drivers/passthr
[Xen-devel] [libvirt test] 125768: regressions - trouble: blocked/broken/fail/pass
flight 125768 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/125768/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm broken build-arm64 broken build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Regressions which are regarded as allowable (not blocking): build-arm64 2 hosts-allocate broken REGR. vs. 123814 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 123814 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a build-arm64 3 capture-logs broken blocked in 123814 build-arm64-xsm 3 capture-logs broken blocked in 123814 build-arm64-pvops 3 capture-logs broken blocked in 123814 version targeted for testing: libvirt 087de2f5a3dffb27d2eeb0c50a86d5d6984e5a5e baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 62 days Failing since123840 2018-06-06 04:19:28 Z 61 days 47 attempts Testing same since 125768 2018-08-06 15:03:07 Z0 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Clementine Hayat Cole Robinson Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Shi Lei Shichangkuo Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský w00251574 Weilun Zhu jobs: build-amd64-xsm pass build-arm64-xsm broken build-i386-xsm pass build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt blocked build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu
Re: [Xen-devel] [PATCH v5 11/15] mm / iommu: split need_iommu() into has_iommu_pt() and sync_iommu_pt()
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> The name 'need_iommu' is a little confusing as it suggests a domain needs
> to use the IOMMU but something might not be set up yet, when in fact it
> doesn't become true until IOMMU mappings for the domain have been
> created.
>
> Two different meanings are also inferred from it in various places in the
> code:
>
> - Some callers want to test whether a domain has IOMMU mappings
> - Some callers want to test whether they need to synchronize the domain's
> P2M and IOMMU mappings
>
> This patch therefore creates two new boolean flags, 'has_iommu_pt' and
> 'sync_iommu_pt' to convey those meanings separately and creates the
> corresponding macros. All callers of need_iommu() are then modified to
> use the macro appropriate to what they are trying to test.
sync_iommu_pt sounds like an operation. what about need_sync_iommu?
and for has_iommu_pt, what about iommu_enabled where 'enabled'
implies page table created?
>
> NOTE: The test of need_iommu(d) in the AMD IOMMU initialization code
> has
> been replaced with a test of iommu_dom0_strict since this more
> accurately reflects the meaning of the test and brings it into
> line with a similar test in the Intel VT-d code.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Stefano Stabellini
> Cc: Julien Grall
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Konrad Rzeszutek Wilk
> Cc: Tim Deegan
> Cc: Wei Liu
> Cc: Tamas K Lengyel
> Cc: George Dunlap
> Cc: Jun Nakajima
> Cc: Kevin Tian
> Cc: Razvan Cojocaru
> Cc: Suravee Suthikulpanit
> Cc: Brian Woods
>
> v4:
> - New in v4.
> ---
> xen/arch/arm/p2m.c | 2 +-
> xen/arch/x86/hvm/mtrr.c | 5 +++--
> xen/arch/x86/mm.c | 2 +-
> xen/arch/x86/mm/mem_sharing.c | 2 +-
> xen/arch/x86/mm/p2m-ept.c | 2 +-
> xen/arch/x86/mm/p2m-pt.c| 2 +-
> xen/arch/x86/mm/p2m.c | 8
> xen/arch/x86/mm/paging.c| 2 +-
> xen/arch/x86/x86_64/mm.c| 3 ++-
> xen/common/memory.c | 6 +++---
> xen/common/vm_event.c | 2 +-
> xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
> xen/drivers/passthrough/device_tree.c | 2 +-
> xen/drivers/passthrough/iommu.c | 17 ++---
> xen/drivers/passthrough/pci.c | 6 +++---
> xen/include/asm-arm/grant_table.h | 2 +-
> xen/include/asm-arm/iommu.h | 2 +-
> xen/include/asm-x86/grant_table.h | 2 +-
> xen/include/asm-x86/iommu.h | 2 +-
> xen/include/xen/sched.h | 12
> 20 files changed, 46 insertions(+), 37 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index eb39861b73..c972b72baf 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -951,7 +951,7 @@ static int __p2m_set_entry(struct p2m_domain
> *p2m,
> if ( lpae_valid(orig_pte) && entry->p2m.base != orig_pte.p2m.base )
> p2m_free_entry(p2m, orig_pte, level);
>
> -if ( need_iommu(p2m->domain) &&
> +if ( sync_iommu_pt(p2m->domain) &&
> (lpae_valid(orig_pte) || lpae_valid(*entry)) )
> {
> rc = iommu_iotlb_flush(p2m->domain, _bfn(gfn_x(sgfn)),
> diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> index c502dda693..61131d4b61 100644
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -824,7 +824,8 @@ HVM_REGISTER_SAVE_RESTORE(MTRR,
> hvm_save_mtrr_msr, hvm_load_mtrr_msr,
>
> void memory_type_changed(struct domain *d)
> {
> -if ( need_iommu(d) && d->vcpu && d->vcpu[0] )
> +if ( (sync_iommu_pt(d) || iommu_use_hap_pt(d)) &&
> + d->vcpu && d->vcpu[0] )
> {
> p2m_memory_type_changed(d);
> flush_all(FLUSH_CACHE);
> @@ -872,7 +873,7 @@ int epte_get_entry_emt(struct domain *d, unsigned
> long gfn, mfn_t mfn,
> return MTRR_TYPE_UNCACHABLE;
> }
>
> -if ( !need_iommu(d) && !cache_flush_permitted(d) )
> +if ( !has_iommu_pt(d) && !cache_flush_permitted(d) )
> {
> *ipat = 1;
> return MTRR_TYPE_WRBACK;
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 08878574f3..462398096f 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2727,7 +2727,7 @@ static int _get_page_type(struct page_info *page,
> unsigned long type,
> {
> /* Special pages should not be accessible from devices. */
> struct domain *d = page_get_owner(page);
> -if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
> +if ( d && is_pv_domain(d) && unlikely(sync_iommu_pt(d)) )
> {
> mfn_t mfn = page_to_mfn(page);
>
> diff --git a/xen/arch/x86/mm/mem_sharing.c
> b/xen/arch/x86/mm/mem_sha
Re: [Xen-devel] [PATCH v5 10/15] mm / iommu: include need_iommu() test in iommu_use_hap_pt()
> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Saturday, August 4, 2018 1:22 AM > > The name 'iommu_use_hap_pt' suggests that that P2M table is in use as > the > domain's IOMMU pagetable which, prior to this patch, is not strictly true > since the macro did not test whether the domain actually has IOMMU > mappings. > > Signed-off-by: Paul Durrant Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 09/15] vtd: add lookup_page method to iommu_ops
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> This patch adds a new method to the VT-d IOMMU implementation to find
> the
> MFN currently mapped by the specified BFN along with a wrapper function
> in
> generic IOMMU code to call the implementation if it exists.
>
> This functionality will be used by a subsequent patch.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Wei Liu
> ---
> Cc: Kevin Tian
> Cc: Jan Beulich
> Cc: George Dunlap
>
> v3:
> - Addressed comments from George.
>
> v2:
> - Addressed some comments from Jan.
> ---
> xen/drivers/passthrough/iommu.c | 11 +++
> xen/drivers/passthrough/vtd/iommu.c | 34
> ++
> xen/drivers/passthrough/vtd/iommu.h | 3 +++
> xen/include/xen/iommu.h | 4
> 4 files changed, 52 insertions(+)
>
> diff --git a/xen/drivers/passthrough/iommu.c
> b/xen/drivers/passthrough/iommu.c
> index b10a37e5d7..9b7baca93f 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -305,6 +305,17 @@ int iommu_unmap_page(struct domain *d, bfn_t
> bfn)
> return rc;
> }
>
> +int iommu_lookup_page(struct domain *d, bfn_t bfn, mfn_t *mfn,
> + unsigned int *flags)
> +{
> +const struct domain_iommu *hd = dom_iommu(d);
> +
> +if ( !iommu_enabled || !hd->platform_ops )
> +return -EOPNOTSUPP;
> +
> +return hd->platform_ops->lookup_page(d, bfn, mfn, flags);
> +}
> +
> static void iommu_free_pagetables(unsigned long unused)
> {
> do {
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index 282e227414..8cd3b59aa0 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1830,6 +1830,39 @@ static int __must_check
> intel_iommu_unmap_page(struct domain *d,
> return dma_pte_clear_one(d, bfn_to_baddr(bfn));
> }
>
> +static int intel_iommu_lookup_page(struct domain *d, bfn_t bfn, mfn_t
> *mfn,
> + unsigned int *flags)
Not looking at later patches yet... but in concept bfn address
space is per device instead of per domain. In default situation
(w/o pvIOMMU exposed), all devices assigned to dom0 share
the same address space (bfn=pfn) which is currently linked
from domain structure. Then with pvIOMMU exposed, dom0
starts to manage individual pfn address space (called IOVA
address space within dom0) per assigned device. In that case
lookup should accept a bdf number and then find the right
page table...
> +{
> +struct domain_iommu *hd = dom_iommu(d);
> +struct dma_pte *page = NULL, *pte = NULL, val;
> +u64 pg_maddr;
> +
> +spin_lock(&hd->arch.mapping_lock);
> +
> +pg_maddr = addr_to_dma_page_maddr(d, bfn_to_baddr(bfn), 0);
> +if ( pg_maddr == 0 )
> +{
> +spin_unlock(&hd->arch.mapping_lock);
> +return -ENOMEM;
> +}
> +
> +page = map_vtd_domain_page(pg_maddr);
> +pte = page + (bfn_x(bfn) & LEVEL_MASK);
> +val = *pte;
> +
> +unmap_vtd_domain_page(page);
> +spin_unlock(&hd->arch.mapping_lock);
> +
> +if ( !dma_pte_present(val) )
> +return -ENOENT;
> +
> +*mfn = maddr_to_mfn(dma_pte_addr(val));
> +*flags = dma_pte_read(val) ? IOMMUF_readable : 0;
> +*flags |= dma_pte_write(val) ? IOMMUF_writable : 0;
> +
> +return 0;
> +}
> +
> int iommu_pte_flush(struct domain *d, uint64_t bfn, uint64_t *pte,
> int order, int present)
> {
> @@ -2661,6 +2694,7 @@ const struct iommu_ops intel_iommu_ops = {
> .teardown = iommu_domain_teardown,
> .map_page = intel_iommu_map_page,
> .unmap_page = intel_iommu_unmap_page,
> +.lookup_page = intel_iommu_lookup_page,
> .free_page_table = iommu_free_page_table,
> .reassign_device = reassign_device_ownership,
> .get_device_group_id = intel_iommu_group_id,
> diff --git a/xen/drivers/passthrough/vtd/iommu.h
> b/xen/drivers/passthrough/vtd/iommu.h
> index 72c1a2e3cd..47bdfcb5ea 100644
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -272,6 +272,9 @@ struct dma_pte {
> #define dma_set_pte_prot(p, prot) do { \
> (p).val = ((p).val & ~DMA_PTE_PROT) | ((prot) & DMA_PTE_PROT); \
> } while (0)
> +#define dma_pte_prot(p) ((p).val & DMA_PTE_PROT)
> +#define dma_pte_read(p) (dma_pte_prot(p) & DMA_PTE_READ)
> +#define dma_pte_write(p) (dma_pte_prot(p) & DMA_PTE_WRITE)
> #define dma_pte_addr(p) ((p).val & PADDR_MASK & PAGE_MASK_4K)
> #define dma_set_pte_addr(p, addr) do {\
> (p).val |= ((addr) & PAGE_MASK_4K); } while (0)
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index cc0be81b4e..7c5d46df81 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -100,6 +100,8 @@ void iommu_teardown(struct domain *d);
> int __must_check iommu_map_page(struct domain *d, bfn_t bfn,
>
Re: [Xen-devel] [PATCH v5 07/15] iommu: track reserved ranges using a rangeset
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> Ranges that should be considered reserved in the IOMMU are not
> necessarily
> limited to RMRRs. If iommu_inclusive_mapping is set then any frame
> number
> falling within an E820 reserved region should also be considered as
> reserved in the IOMMU.
I don't think it is a good extension. RMRR by definition requires
identity mapping in IOMMU page table, thus must be also reserved
in bfn address space (to avoid being used for other purpose).
Normal E820 reserved regions have no such requirement. Guest
can use same bfn location for any purpose. I'm not sure why we
want to add more limitations here.
> This patch adds a rangeset to the domain_iommu structure that is then
> used
> to track all reserved ranges. This will be needed by a subsequent patch
> to test whether it is safe to modify a particular IOMMU entry.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: George Dunlap
> Reviewed-by: Wei Liu
> ---
> Cc: Jan Beulich
> Cc: Kevin Tian
>
> v2:
> - New in v2.
> ---
> xen/drivers/passthrough/iommu.c | 10 +-
> xen/drivers/passthrough/vtd/iommu.c | 20 +---
> xen/drivers/passthrough/vtd/x86/vtd.c | 17 -
> xen/include/xen/iommu.h | 6 ++
> 4 files changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/xen/drivers/passthrough/iommu.c
> b/xen/drivers/passthrough/iommu.c
> index 21e6886a3f..b10a37e5d7 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -147,6 +147,10 @@ int iommu_domain_init(struct domain *d)
> if ( !iommu_enabled )
> return 0;
>
> +hd->reserved_ranges = rangeset_new(d, NULL, 0);
> +if ( !hd->reserved_ranges )
> +return -ENOMEM;
> +
> hd->platform_ops = iommu_get_ops();
> return hd->platform_ops->init(d);
> }
> @@ -248,12 +252,16 @@ int iommu_construct(struct domain *d)
>
> void iommu_domain_destroy(struct domain *d)
> {
> -if ( !iommu_enabled || !dom_iommu(d)->platform_ops )
> +const struct domain_iommu *hd = dom_iommu(d);
> +
> +if ( !iommu_enabled || !hd->platform_ops )
> return;
>
> iommu_teardown(d);
>
> arch_iommu_domain_destroy(d);
> +
> +rangeset_destroy(hd->reserved_ranges);
> }
>
> int iommu_map_page(struct domain *d, bfn_t bfn, mfn_t mfn,
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index c9f50f04ad..282e227414 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1910,6 +1910,7 @@ static int rmrr_identity_mapping(struct domain
> *d, bool_t map,
> unsigned long end_pfn = PAGE_ALIGN_4K(rmrr->end_address) >>
> PAGE_SHIFT_4K;
> struct mapped_rmrr *mrmrr;
> struct domain_iommu *hd = dom_iommu(d);
> +int err = 0;
>
> ASSERT(pcidevs_locked());
> ASSERT(rmrr->base_address < rmrr->end_address);
> @@ -1923,8 +1924,6 @@ static int rmrr_identity_mapping(struct domain
> *d, bool_t map,
> if ( mrmrr->base == rmrr->base_address &&
> mrmrr->end == rmrr->end_address )
> {
> -int ret = 0;
> -
> if ( map )
> {
> ++mrmrr->count;
> @@ -1934,28 +1933,35 @@ static int rmrr_identity_mapping(struct
> domain *d, bool_t map,
> if ( --mrmrr->count )
> return 0;
>
> -while ( base_pfn < end_pfn )
> +err = rangeset_remove_range(hd->reserved_ranges,
> +base_pfn, end_pfn);
> +while ( !err && base_pfn < end_pfn )
> {
> if ( clear_identity_p2m_entry(d, base_pfn) )
> -ret = -ENXIO;
> +err = -ENXIO;
> +
> base_pfn++;
> }
>
> list_del(&mrmrr->list);
> xfree(mrmrr);
> -return ret;
> +return err;
> }
> }
>
> if ( !map )
> return -ENOENT;
>
> +err = rangeset_add_range(hd->reserved_ranges, base_pfn, end_pfn);
> +if ( err )
> +return err;
> +
> while ( base_pfn < end_pfn )
> {
> -int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
> -
> +err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
> if ( err )
> return err;
> +
> base_pfn++;
> }
>
> diff --git a/xen/drivers/passthrough/vtd/x86/vtd.c
> b/xen/drivers/passthrough/vtd/x86/vtd.c
> index 6fed4a92cb..032412b8c6 100644
> --- a/xen/drivers/passthrough/vtd/x86/vtd.c
> +++ b/xen/drivers/passthrough/vtd/x86/vtd.c
> @@ -164,10 +164,25 @@ void __hwdom_init
> vtd_set_hwdom_mapping(struct domain *d)
>
> if ( !rc )
> rc = ret;
> +
> +/*
> + * The only reason a reserved page would be mapped is that
> + * iommu_inclusive_mappin
Re: [Xen-devel] [PATCH v5 06/15] public / x86: introduce __HYPERCALL_iommu_op
> From: Paul Durrant > Sent: Saturday, August 4, 2018 1:22 AM > > This patch introduces the boilerplate for a new hypercall to allow a > domain to control IOMMU mappings for its own pages. > Whilst there is duplication of code between the native and compat entry > points which appears ripe for some form of combination, I think it is > better to maintain the separation as-is because the compat entry point > will necessarily gain complexity in subsequent patches. > > NOTE: This hypercall is only implemented for x86 and is currently > restricted by XSM to dom0. Its scope can be expanded in future > if need be. > > Signed-off-by: Paul Durrant [...] > diff --git a/xen/arch/x86/iommu_op.c b/xen/arch/x86/iommu_op.c > new file mode 100644 > index 00..744c0fce27 > --- /dev/null > +++ b/xen/arch/x86/iommu_op.c > @@ -0,0 +1,184 @@ > +/ > ** > + * x86/iommu_op.c > + * > + * Paravirtualised IOMMU functionality although only x86 is supported, logic in this file is vendor agnostic. Better move to a common place now... Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 05/15] iommu: don't domain_crash() inside iommu_map/unmap_page()
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Saturday, August 4, 2018 1:22 AM
>
> Turn iommu_map/unmap_page() into straightforward wrappers that check
> the
iommu_iotlb_flush is also changed.
> existence of the relevant iommu_op and call through to it. This makes them
> usable by PV IOMMU code to be delivered in future patches.
> Leave the decision on whether to invoke domain_crash() up to the caller.
> This has the added benefit that the (module/line number) message that
> domain_crash() spits out will be more indicative of where the problem lies.
>
> NOTE: This patch includes one bit of clean-up in set_identity_p2m_entry()
> replacing use of p2m->domain with the domain pointer passed into the
> function.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: George Dunlap
> Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian , with one small comment:
>
> if ( need_iommu(p2m->domain) &&
> (lpae_valid(orig_pte) || lpae_valid(*entry)) )
> +{
> rc = iommu_iotlb_flush(p2m->domain, _bfn(gfn_x(sgfn)),
> 1UL << page_order);
> +if ( unlikely(rc) && !is_hardware_domain(p2m->domain) )
> +domain_crash(p2m->domain);
> +}
to reduce duplication, does it make sense to introduce a wrapper
like domain_crash_nd ('nd' indicate !is_hardware_domain, and
becomes a nop for hardware domain)? Then it becomes:
if ( unlikely(rc) )
domain_crash_nd(p2m->domain);
Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125777: regressions - trouble: blocked/broken/fail/pass
flight 125777 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125777/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-armhf 6 xen-buildfail REGR. vs. 125729 Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen e752f28409678ce3ade49986b39309178fb2a6d6 baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z5 days Failing since125741 2018-08-02 10:01:09 Z4 days6 attempts Testing same since 125772 2018-08-06 16:00:37 Z0 days4 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini jobs: build-arm64-xsm broken build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64-xsm broken broken-step build-arm64-xsm hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 480 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 04/15] iommu: push use of type-safe BFN and MFN into iommu_ops
> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Saturday, August 4, 2018 1:22 AM > > This patch modifies the methods in struct iommu_ops to use type-safe BFN > and MFN. This follows on from the prior patch that modified the functions > exported in xen/iommu.h. > > Signed-off-by: Paul Durrant > Reviewed-by: Wei Liu Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 03/15] iommu: make use of type-safe BFN and MFN in exported functions
> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Saturday, August 4, 2018 1:22 AM > > This patch modifies the declaration of the entry points to the IOMMU > sub-system to use bfn_t and mfn_t in place of unsigned long. A subsequent > patch will similarly modify the methods in the iommu_ops structure. > > Signed-off-by: Paul Durrant > Reviewed-by: Wei Liu Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 02/15] iommu: introduce the concept of BFN...
> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Saturday, August 4, 2018 1:22 AM > > ...meaning 'bus frame number' i.e. a frame number mapped in the IOMMU > rather than the MMU. > > This patch is a largely cosmetic change that substitutes the terms 'gfn' > and 'gaddr' for 'bfn' and 'baddr' in all the places where the frame number > or address relate to the IOMMU rather than the MMU. > > The parts that are not purely cosmetic are: > > - the introduction of a type-safe declaration of bfn_t and definition of >INVALID_BFN to make the substitution of gfn_x(INVALID_GFN) mechanical. > - the introduction of __bfn_to_baddr and __baddr_to_bfn (and type-safe >variants without the leading __) with some use of the former. > > Subsequent patches will convert code to make use of type-safe BFNs. > > Signed-off-by: Paul Durrant > Reviewed-by: Wei Liu [...] > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h > index 24654e8e22..4ebf91f17e 100644 > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -14,8 +14,9 @@ > * should be adhered to. > * > * mfn: Machine Frame Number > - * The values Xen puts into its own pagetables. This is the host physical > - * memory address space with RAM, MMIO etc. > + * The values Xen puts into its own pagetables, 2nd stage pagetables > (where > + * hardware assisted 2nd stage translation is used) or IOMMU page > tables. > + * This is the host physical memory address space with RAM, MMIO etc. there is also shadow page table... not sure whether it is really helpful to list all of them out. "Xen-owned pagetables" should be sufficient to cover. > * > * gfn: Guest Frame Number > * The values a guest puts in its own pagetables. For an auto-translated > @@ -26,6 +27,11 @@ > * A linear idea of a guest physical address space. For an auto-translated > * guest, pfn == gfn while for a non-translated guest, pfn != gfn. > * > + * bfn: Bus Frame Number (definitions in include/xen/iommu.h) > + * The linear frame numbers of IOMMU address space. All initiators for a > + * given domain share a single IOMMU address space and, by default, > Xen will > + * ensure bfn == pfn. > + * Above description is a bit confusing: - for 'domain', are you talking about VM or IOMMU domain? If the former then each initiator could have its own IOMMU address space when a virtual IOMMU (either pvIOMMU or emulated IOMMU) is exposed. - since you talk about 'by default', better also talk about non-default case, i.e. when virtual IOMMU is exposed then bfn is a separate address space managed by guest > * WARNING: Some of these terms have changed over time while others > have been > * used inconsistently, meaning that a lot of existing code does not match > the > * definitions above. New code should use these terms as described here, > and > -- > 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 03/17] libxl: Handle Linux stubdomain specific QEMU options.
From: Eric Shelton
This patch creates an appropriate command line for the QEMU instance
running in a Linux-based stubdomain.
NOTE: a number of items are not currently implemented for Linux-based
stubdomains, such as:
- save/restore
- QMP socket
- graphics output (e.g., VNC)
Signed-off-by: Eric Shelton
Simon:
* fix disk path
* fix cdrom path and "format"
* pass downscript for network interfaces
Signed-off-by: Simon Gaiser
[drop Qubes-specific parts]
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- fix serial specified with serial=[ ... ] syntax
- error out on multiple consoles (incompatible with stubdom)
- drop erroneous chunk about cdrom
---
tools/libxl/libxl_dm.c | 114 +-
1 file changed, 81 insertions(+), 33 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ebe8e0c..82ff490 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -25,9 +25,24 @@
#include
#include
-static const char *libxl_tapif_script(libxl__gc *gc)
+static const char *libxl_tapif_script(libxl__gc *gc,
+ const libxl_domain_build_info *info)
{
#if defined(__linux__) || defined(__FreeBSD__)
+if (info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
+return libxl__sprintf(gc, "/etc/qemu-ifup");
+return libxl__strdup(gc, "no");
+#else
+return GCSPRINTF("%s/qemu-ifup", libxl__xen_script_dir_path());
+#endif
+}
+
+static const char *libxl_tapif_downscript(libxl__gc *gc,
+ const libxl_domain_build_info *info)
+{
+#if defined(__linux__) || defined(__FreeBSD__)
+if (info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
+return libxl__sprintf(gc, "/etc/qemu-ifdown");
return libxl__strdup(gc, "no");
#else
return GCSPRINTF("%s/qemu-ifup", libxl__xen_script_dir_path());
@@ -616,8 +631,8 @@ static int libxl__build_device_model_args_old(libxl__gc *gc,
"tap,vlan=%d,ifname=%s,bridge=%s,"
"script=%s,downscript=%s",
nics[i].devid, ifname, nics[i].bridge,
- libxl_tapif_script(gc),
- libxl_tapif_script(gc)),
+ libxl_tapif_script(gc, b_info),
+ libxl_tapif_downscript(gc, b_info)),
NULL);
ioemu_nics++;
}
@@ -933,6 +948,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
const char *path, *chardev;
char *user = NULL;
struct passwd *user_base, user_pwbuf;
+bool is_stubdom = libxl_defbool_val(b_info->device_model_stubdomain);
dm_args = flexarray_make(gc, 16, 1);
dm_envs = flexarray_make(gc, 16, 1);
@@ -943,24 +959,27 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
"-xen-domid",
GCSPRINTF("%d", guest_domid), NULL);
-flexarray_append(dm_args, "-chardev");
-flexarray_append(dm_args,
- GCSPRINTF("socket,id=libxl-cmd,"
-"path=%s/qmp-libxl-%d,server,nowait",
-libxl__run_dir_path(), guest_domid));
+/* There is currently no way to access the QMP socket in the stubdom */
+if (!is_stubdom) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxl-cmd,"
+"path=%s/qmp-libxl-%d,server,nowait",
+libxl__run_dir_path(), guest_domid));
-flexarray_append(dm_args, "-no-shutdown");
-flexarray_append(dm_args, "-mon");
-flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
+flexarray_append(dm_args, "-no-shutdown");
+flexarray_append(dm_args, "-mon");
+flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
-flexarray_append(dm_args, "-chardev");
-flexarray_append(dm_args,
- GCSPRINTF("socket,id=libxenstat-cmd,"
-"path=%s/qmp-libxenstat-%d,server,nowait",
-libxl__run_dir_path(), guest_domid));
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxenstat-cmd,"
+
"path=%s/qmp-libxenstat-%d,server,nowait",
+libxl__run_dir_path(), guest_domid));
-flexarray_append(dm_args, "-mon");
-flexarray_append(dm_args, "chardev=libxenstat-cmd,mode=control");
+flexarray_append(dm_args, "-mon");
+flexarray_append(dm_args, "chardev=libxenstat-cmd,mode=control");
+}
for (i = 0; i < guest_config->num_channels; i++) {
[Xen-devel] [RFC PATCH v2 06/17] libxl: create vkb device only for guests with graphics output
The forced vkb device is meant for better performance of qemu access
(at least according to ebbd2561b4cefb299f0f68a88b2788504223de18 "libxl:
Add a vkbd frontend/backend pair for HVM guests"), which isn't used if
there is no configured channel to actually access that keyboard.
One can still add vkb device manually if needed.
This is continuation of b053f0c4c9e533f3d97837cf897eb920b8355ed3 "libxl: do
not start dom0 qemu for stubdomain when not needed".
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
---
tools/libxl/libxl_create.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ff27d30..a0acd6b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1451,9 +1451,13 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
libxl__device_console_add(gc, domid, &console, state, &device);
libxl__device_console_dispose(&console);
-libxl_device_vkb_init(&vkb);
-libxl__device_add(gc, domid, &libxl__vkb_devtype, &vkb);
-libxl_device_vkb_dispose(&vkb);
+if (libxl_defbool_val(d_config->b_info.u.hvm.vnc.enable)
+|| libxl_defbool_val(d_config->b_info.u.hvm.spice.enable)
+|| libxl_defbool_val(d_config->b_info.u.hvm.sdl.enable)) {
+libxl_device_vkb_init(&vkb);
+libxl__device_add(gc, domid, &libxl__vkb_devtype, &vkb);
+libxl_device_vkb_dispose(&vkb);
+}
dcs->sdss.dm.guest_domid = domid;
if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 14/17] xenconsoled: deduplicate error handling
Signed-off-by: Marek Marczykowski-Górecki
---
tools/console/daemon/io.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index c2c37dc..ea07442 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -819,9 +819,7 @@ static int console_create_ring(struct console *con)
if (rc == -1) {
err = errno;
- xenevtchn_close(con->xce_handle);
- con->xce_handle = NULL;
- goto out;
+ goto err_xce;
}
con->local_port = rc;
con->remote_port = remote_port;
@@ -829,11 +827,7 @@ static int console_create_ring(struct console *con)
if (con->master_fd == -1) {
if (!console_create_tty(con)) {
err = errno;
- xenevtchn_close(con->xce_handle);
- con->xce_handle = NULL;
- con->local_port = -1;
- con->remote_port = -1;
- goto out;
+ goto err_xce;
}
}
@@ -843,6 +837,13 @@ static int console_create_ring(struct console *con)
/* if everything ok, signal backend readiness, in backend tree */
set_backend_state(con, XenbusStateConnected);
+ err_xce:
+ if (err) {
+ xenevtchn_close(con->xce_handle);
+ con->xce_handle = NULL;
+ con->local_port = -1;
+ con->remote_port = -1;
+ }
out:
return err;
}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.
General idea is to allow freely set device_model_version and device_model_stubdomain_override and choose the right options based on this choice. Also, allow to specific path to stubdomain kernel/ramdisk, for greater flexibility. Right now when qemu-xen in stubdomain is selected, it is assumed it's Linux-based and few decisions are based on it, specifically: - qemu args encoding (\x1b as separator, to allow spaces in arguments) - save/restore stream access (specific FDs passed to qemu by a wrapper script) - QMP access, if any It may be a good idea to document "stubdomain API" somewhere. Is there such document for MiniOS one? Here is an initial version for Linux one: Assumptions about Linux-based stubdomain for qemu-xen: * qemu command line is stored by toolstack in /vm//image/dmargs xenstore entry, arguments are separated with \x1b character * qemu can access saved state (if any) at its FD 3 * qemu can write its state (for save/migration) to its FD 4 * qemu expects backend for serial console at /dev/hvc3 * disks configured for the target are available as /dev/xvd*, in configuration order * qemu can call /etc/qemu-ifup and /etc/qemu-ifdown to connect/disconnect network interface to appropriate network Initial version has no QMP support - in initial patches it is completely disabled, which means no suspend/restore. QMP normally would be used for PCI passthrough setup, but it is worked around with MiniOS-like control protocol over xenstore, which then is translated to QMP on stubdomain side. Some option is to use separate console for that, but that require xenstoled supporting multiple consoles per domain (the goal is to not have qemu in dom0 at all). Also, it would be preferable to evaluate how libxl handle potentially malicious QMP responses. Another option is to use xenstore - either translate everything needed to MiniOS-like thing, or write already json-formatted requests to xenstore and watch there for responses. When using separate xenstore dir for that, with per-command entries (command id as a key name?) that would solve concurrency problem. QMP support over separate console: patch "libxl: access QMP socket via console for qemu-in-stubdomain" implements some early PoC of this. Major limitation: only one connection at a time and no means of out of band reset (and re-negotiate). I've tried adding very simple `qmp_reset` command for in-band connection reset, but it is unreliable because of the first limitation - xl process running in background hold this connection open and every other xl instance interfere with it. On the other hand, for libvirt use case one connection could be enough (leaving alone libvirtd restart). Xenconsoled patches add support for multiple consoles in xenconsoled, to avoid the need for qemu in dom0 for this to work. Multiple consoles for a stubdomain are used for: - logs (console 0) - save + restore (console 1, 2) - qmp (console 3) - serial terminal to target domU (console 4) Xenconsoled patches are in fact a separate series, but I'm sending them here to ease dependencies handling (latter libxl patches use that). What qmp-libxenstat socket is for? PCI passthrough support require some more love. Right now, libxl tries to setup pcifront for both target HVM and stubdomain and the former fails (race condition): xen-pciback pci-259-0: 22 Couldn't locate PCI device (:00:1b.0)! perhaps already in-use? Fortunately it isn't needed. There is also a PCI related problem on domain shutdown - it looks like first stubdomain is paused and then libxl waits for pcifront there. Also, MSI doesn't work (qemu output): [00:05.0] xen_pt_msgctrl_reg_write: setup MSI (register: 81). [00:05.0] msi_msix_setup: requested pirq 55 for MSI (vec: 0, entry: 0) [00:05.0] msi_msix_setup: Error: Mapping of MSI (err: 1, vec: 0, entry 0) [00:05.0] xen_pt_msgctrl_reg_write: Warning: Can not map MSI (register: 80)! [00:05.0] Write-back to unknown field 0x44 (partially) inhibited (0x00) [00:05.0] If the device doesn't work, try enabling permissive mode [00:05.0] (unsafe) and if it helps report the problem to xen-devel The actual stubdomain implementation is here: https://github.com/marmarek/qubes-vmm-xen-stubdom-linux (branch for-upstream) See readme there for build instructions. Remaining parts for eliminating dom0's instance of qemu: - do not force QDISK backend for CDROM This patch series is third (fourth?) attempt to get rid of limitation "if you want to use stubdomain, you're stuck with qemu-traditional", done over years, by many people. I think it should be acceptable plan to gradually add features to qemu-xen+stubdomain configuration - not necessary waiting with committing any of those patches until full feature set of qemu-xen is supported. After all, right now "feature set supported by qemu-xen+stubdom" is empty, so wouldn't be worse. Changes in v2: - apply review comments by Jason Andryuk Cc:
[Xen-devel] [RFC PATCH v2 17/17] libxl: use xenconsoled even for multiple stubdomain's consoles
Since multiple consoles support was added to xenconsoled, use it for
stubdomain. This makes it possible to have HVM without qemu in dom0 at
al. As long as no other feature requiring qemu in dom0 is used, like VNC
or qdisk.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libxl/libxl_dm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ab851cc..582f122 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2144,7 +2144,9 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
for (i = 0; i < num_console; i++) {
console[i].devid = i;
-console[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
+/* will be changed back to LIBXL__CONSOLE_BACKEND_IOEMU if qemu
+ * will be in use */
+console[i].consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
/* STUBDOM_CONSOLE_LOGGING (console 0) is for minios logging
* STUBDOM_CONSOLE_SAVE (console 1) is for writing the save file
* STUBDOM_CONSOLE_RESTORE (console 2) is for reading the save file
@@ -2160,9 +2162,6 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
if (ret) goto out;
console[i].output = GCSPRINTF("file:%s", filename);
free(filename);
-/* will be changed back to LIBXL__CONSOLE_BACKEND_IOEMU if qemu
- * will be in use */
-console[i].consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
break;
case STUBDOM_CONSOLE_SAVE:
console[i].output = GCSPRINTF("file:%s",
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 11/17] xenconsoled: add support for consoles using 'state' xenstore entry
Add support for standard xenbus initialization protocol using 'state'
xenstore entry. It will be necessary for secondary consoles.
For consoles supporting it, read 'state' entry on the frontend and
proceed accordingly - either init console or close it. When closing,
make sure all the in-transit data is flushed (both from shared ring and
from local buffer), if possible. This is especially important for
MiniOS-based qemu stubdomain, which closes console just after writing
device model state to it.
For consoles without 'state' field behavior is unchanged - on any watch
event try to connect console, as long as domain is alive.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/console/daemon/io.c | 86 ++--
1 file changed, 83 insertions(+), 3 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 4d4e223..82806b2 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -110,6 +111,7 @@ struct console {
struct domain *d;
bool optional;
bool use_gnttab;
+ bool have_state;
};
struct console_type {
@@ -118,6 +120,7 @@ struct console_type {
char *log_suffix;
bool optional;
bool use_gnttab;
+ bool have_state; // uses 'state' xenstore entry
};
static struct console_type console_type[] = {
@@ -157,6 +160,8 @@ typedef void (*VOID_ITER_FUNC_ARG2)(struct console *, void
*);
typedef int (*INT_ITER_FUNC_ARG3)(struct console *,
struct domain *dom, void **);
+static void handle_tty_write(struct console *con);
+
static inline bool console_enabled(struct console *con)
{
return con->local_port != -1;
@@ -672,6 +677,20 @@ static int xs_gather(struct xs_handle *xs, const char
*dir, ...)
return ret;
}
+static void set_backend_state(struct console *con, int state)
+{
+ char path[PATH_MAX], state_str[2], *be_path;
+
+ snprintf(state_str, sizeof(state_str), "%d", state);
+ snprintf(path, sizeof(path), "%s/backend", con->xspath);
+ be_path = xs_read(xs, XBT_NULL, path, NULL);
+ if (be_path) {
+ snprintf(path, sizeof(path), "%s/state", be_path);
+ xs_write(xs, XBT_NULL, path, state_str, 1);
+ free(be_path);
+ }
+}
+
static void console_unmap_interface(struct console *con)
{
if (con->interface == NULL)
@@ -683,7 +702,7 @@ static void console_unmap_interface(struct console *con)
con->interface = NULL;
con->ring_ref = -1;
}
-
+
static int console_create_ring(struct console *con)
{
int err, remote_port, ring_ref, rc;
@@ -787,10 +806,70 @@ static int console_create_ring(struct console *con)
if (log_guest && (con->log_fd == -1))
con->log_fd = create_console_log(con);
+ /* if everything ok, signal backend readiness, in backend tree */
+ set_backend_state(con, XenbusStateConnected);
+
out:
return err;
}
+/* gracefully close console */
+static int console_close(struct console *con) {
+
+ if (con->interface && con->master_fd != -1 && con->buffer.data) {
+ /* handle remaining data in buffers */
+ buffer_append(con);
+
+ /* write it out, if possible */
+ if (con->master_pollfd_idx != -1) {
+ if (fds[con->master_pollfd_idx].revents &
+ POLLOUT)
+ handle_tty_write(con);
+ }
+ }
+
+ console_close_tty(con);
+ console_unmap_interface(con);
+ set_backend_state(con, XenbusStateClosed);
+
+ return 0;
+}
+
+
+static int handle_console_state(struct console *con) {
+ int err, state;
+
+ if (!con->have_state)
+ return console_create_ring(con);
+
+ err = xs_gather(xs, con->xspath,
+ "state", "%u", &state,
+ NULL);
+ if (err)
+ /* no 'state' entry, assume removal */
+ state = XenbusStateClosed;
+
+ switch (state) {
+ case XenbusStateInitialising:
+ case XenbusStateInitWait:
+ /* wait for frontent init */
+ return 0;
+ case XenbusStateInitialised:
+ case XenbusStateConnected:
+ /* ok, init backend (also on restart) */
+ return console_create_ring(con);
+ case XenbusStateClosing:
+ case XenbusStateClosed:
+ /* close requested */
+ return console_close(con);
+ default:
+ dolog(LOG_ERR,
+ "Invalid state %d set by console %s of domain
%d\n",
+ state, con->xspath, con->d->domid);
+
[Xen-devel] [RFC PATCH v2 02/17] libxl: Add "stubdomain_version" to domain_build_info.
From: Eric Shelton
This enum gives the ability to select between a MiniOS-based QEMU
traditional stub domain and a Linux-based QEMU upstream stub domain. To
use the Linux-based stubdomain, the following two lines should be
included in the appropriate xl.cfg file:
device_model_version="qemu-xen"
device_model_stubdomain_override=1
To use the MiniOS-based stubdomain, the following is used instead:
device_model_version="qemu-xen-traditional"
device_model_stubdomain_override=1
Signed-off-by: Eric Shelton
Reviewed-by: Jason Andryuk
---
tools/libxl/libxl_create.c | 34 +-
tools/libxl/libxl_types.idl | 7 +++
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1ccb3e3..1d92b5f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -159,12 +159,36 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
}
if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
-b_info->device_model_version !=
-LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
libxl_defbool_val(b_info->device_model_stubdomain)) {
-LOG(ERROR,
-"device model stubdomains require \"qemu-xen-traditional\"");
-return ERROR_INVAL;
+if (!b_info->stubdomain_version) {
+switch (b_info->device_model_version) {
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_MINIOS;
+break;
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_LINUX;
+break;
+default: abort();
+}
+}
+
+switch (b_info->device_model_version) {
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_MINIOS)
{
+LOG(ERROR,
+"\"qemu-xen-traditional\" require \"minios\" as
stubdomain");
+return ERROR_INVAL;
+}
+break;
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_LINUX) {
+LOG(ERROR,
+"\"qemu-xen\" require \"linux\" as stubdomain");
+return ERROR_INVAL;
+}
+break;
+default: abort();
+}
}
if (!b_info->max_vcpus)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 4a38580..847e2fe 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -101,6 +101,12 @@ libxl_device_model_version =
Enumeration("device_model_version", [
(2, "QEMU_XEN"), # Upstream based qemu-xen device model
])
+# Give the kernel running in the stub-domain
+libxl_stubdomain_version = Enumeration("stubdomain_version", [
+(1, "MINIOS"),
+(2, "LINUX"),
+])
+
libxl_console_type = Enumeration("console_type", [
(0, "UNKNOWN"),
(1, "SERIAL"),
@@ -491,6 +497,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("device_model_version", libxl_device_model_version),
("device_model_stubdomain", libxl_defbool),
+("stubdomain_version", libxl_stubdomain_version),
# if you set device_model you must set device_model_version too
("device_model", string),
("device_model_ssidref", uint32),
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 04/17] libxl: Build the domain with a Linux based stubdomain
From: Eric Shelton
This will build a Linux-based stubdomain with QEMU upstream.
Signed-off-by: Eric Shelton
Simon:
* use initramfs instead of disk with rootfs
* don't initialize qmp (unused in Qubes)
* Make libxl_domain_need_memory consistent with actual stubdoma build
code (bugfix relevant also for non-linux case)
* Make stubdomain memory size configurable
Signed-off-by: Simon Gaiser
Marek:
* Make kernel and ramdisk paths configurable.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
---
tools/libxl/libxl_create.c | 75 +++--
tools/libxl/libxl_dm.c | 48 ++--
tools/libxl/libxl_internal.c | 22 +++-
tools/libxl/libxl_internal.h | 4 ++-
tools/libxl/libxl_mem.c | 6 ++-
tools/libxl/libxl_types.idl | 3 +-
6 files changed, 126 insertions(+), 32 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1d92b5f..ff27d30 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -162,32 +162,54 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
libxl_defbool_val(b_info->device_model_stubdomain)) {
if (!b_info->stubdomain_version) {
switch (b_info->device_model_version) {
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+b_info->stubdomain_version =
LIBXL_STUBDOMAIN_VERSION_MINIOS;
+break;
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+b_info->stubdomain_version =
LIBXL_STUBDOMAIN_VERSION_LINUX;
+break;
+default: abort();
+}
+}
+
+switch (b_info->device_model_version) {
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_MINIOS;
+if (b_info->stubdomain_version !=
LIBXL_STUBDOMAIN_VERSION_MINIOS) {
+LOG(ERROR,
+"\"qemu-xen-traditional\" require \"minios\" as
stubdomain");
+return ERROR_INVAL;
+}
break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_LINUX;
+if (b_info->stubdomain_version !=
LIBXL_STUBDOMAIN_VERSION_LINUX) {
+LOG(ERROR,
+"\"qemu-xen\" require \"linux\" as stubdomain");
+return ERROR_INVAL;
+}
break;
default: abort();
-}
}
-switch (b_info->device_model_version) {
-case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_MINIOS)
{
-LOG(ERROR,
-"\"qemu-xen-traditional\" require \"minios\" as
stubdomain");
-return ERROR_INVAL;
+if (!b_info->stubdomain_kernel) {
+switch (b_info->stubdomain_version) {
+case LIBXL_STUBDOMAIN_VERSION_MINIOS:
+b_info->stubdomain_kernel =
+libxl__abs_path(NOGC, "ioemu-stubdom.gz",
libxl__xenfirmwaredir_path());
+b_info->stubdomain_ramdisk = NULL;
+break;
+case LIBXL_STUBDOMAIN_VERSION_LINUX:
+b_info->stubdomain_kernel =
+libxl__abs_path(NOGC,
+"stubdom-linux-kernel",
+libxl__xenfirmwaredir_path());
+b_info->stubdomain_ramdisk =
+libxl__abs_path(NOGC,
+"stubdom-linux-rootfs",
+libxl__xenfirmwaredir_path());
+break;
+default:
+abort();
}
-break;
-case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_LINUX) {
-LOG(ERROR,
-"\"qemu-xen\" require \"linux\" as stubdomain");
-return ERROR_INVAL;
-}
-break;
-default: abort();
}
}
@@ -226,6 +248,19 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
b_info->target_memkb = b_info->max_memkb;
+if (b_info->stubdomain_memkb == LIBXL_MEMKB_DEFAULT) {
+switch (b_info->stubdomain_version) {
+case LIBXL_STUBDOMAIN_VERSION_MINIOS:
+b_info->stubdomain_memkb = 28 * 1024;
+break;
+case LIBXL_STUBDOMAIN_VERSION_LINUX:
+b_info->stubdomain_memkb = LIBXL_LINUX_STUBDOM_MEM * 1024;;
+break;
+default:
+b_info->stubdomain_memkb = 0; // no stubdomai
[Xen-devel] [RFC PATCH v2 10/17] xenconsoled: install xenstore watch for all supported consoles
Not only for the primary one (/local/domain//console path).
Signed-off-by: Marek Marczykowski-Górecki
---
tools/console/daemon/io.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 8dac279..4d4e223 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -791,24 +791,24 @@ static int console_create_ring(struct console *con)
return err;
}
-static bool watch_domain(struct domain *dom, bool watch)
+static int watch_domain(struct console *con, struct domain *dom, void **data)
{
+ bool watch = data;
char domid_str[3 + MAX_STRLEN(dom->domid)];
bool success;
- struct console *con = &dom->console[0];
snprintf(domid_str, sizeof(domid_str), "dom%u", dom->domid);
if (watch) {
success = xs_watch(xs, con->xspath, domid_str);
if (success)
- console_iter_int_arg1(dom, console_create_ring);
+ console_create_ring(con);
else
xs_unwatch(xs, con->xspath, domid_str);
} else {
success = xs_unwatch(xs, con->xspath, domid_str);
}
- return success;
+ return !success;
}
static int console_init(struct console *con, struct domain *dom, void **data)
@@ -878,7 +878,7 @@ static struct domain *create_domain(int domid)
if (console_iter_int_arg3(dom, console_init, (void **)&con_type))
goto out;
- if (!watch_domain(dom, true))
+ if (console_iter_int_arg3(dom, watch_domain, (void**)true))
goto out;
dom->next = dom_head;
@@ -952,7 +952,7 @@ static void console_close_evtchn(struct console *con)
static void shutdown_domain(struct domain *d)
{
d->is_dead = true;
- watch_domain(d, false);
+ console_iter_int_arg3(d, watch_domain, (void**)false);
console_iter_void_arg1(d, console_unmap_interface);
console_iter_void_arg1(d, console_close_evtchn);
}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 12/17] xenconsoled: make console_type->use_gnttab less confusing
Before this commit 'use_gnttab' means xenconsoled should first try
special GNTTAB_RESERVED_CONSOLE entry, and only then fallback to
ring-ref xenstore entry (being gfn of actual ring).
In case of secondary consoles, ring-ref entry contains grant table
reference (not gfn of it), which makes the old meaning of use_gnttab
really confusing (should be false for such consoles).
To solve this, add new entry in console_type (and console) structures
named 'use_reserverd_gnttab' with the old meaning of 'use_gnttab', then
use 'ues_gnttab' for consoles where ring-ref holds grant table
reference.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/console/daemon/io.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 82806b2..3f2b9cb 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -111,6 +111,7 @@ struct console {
struct domain *d;
bool optional;
bool use_gnttab;
+ bool use_reserved_gnttab;
bool have_state;
};
@@ -120,6 +121,7 @@ struct console_type {
char *log_suffix;
bool optional;
bool use_gnttab;
+ bool use_reserved_gnttab;
bool have_state; // uses 'state' xenstore entry
};
@@ -130,6 +132,7 @@ static struct console_type console_type[] = {
.log_suffix = "",
.optional = false,
.use_gnttab = true,
+ .use_reserved_gnttab = true,
},
#if defined(CONFIG_ARM)
{
@@ -695,7 +698,7 @@ static void console_unmap_interface(struct console *con)
{
if (con->interface == NULL)
return;
- if (xgt_handle && con->ring_ref == -1)
+ if (xgt_handle && con->use_gnttab)
xengnttab_unmap(xgt_handle, con->interface, 1);
else
munmap(con->interface, XC_PAGE_SIZE);
@@ -739,12 +742,19 @@ static int console_create_ring(struct console *con)
if (!con->interface && xgt_handle && con->use_gnttab) {
/* Prefer using grant table */
- con->interface = xengnttab_map_grant_ref(xgt_handle,
- dom->domid, GNTTAB_RESERVED_CONSOLE,
- PROT_READ|PROT_WRITE);
- con->ring_ref = -1;
+ if (con->use_reserved_gnttab) {
+ con->interface = xengnttab_map_grant_ref(xgt_handle,
+ dom->domid, GNTTAB_RESERVED_CONSOLE,
+ PROT_READ|PROT_WRITE);
+ con->ring_ref = -1;
+ } else {
+ con->interface = xengnttab_map_grant_ref(xgt_handle,
+ dom->domid, ring_ref,
+ PROT_READ|PROT_WRITE);
+ con->ring_ref = ring_ref;
+ }
}
- if (!con->interface) {
+ if (!con->interface && (!con->use_gnttab || con->use_reserved_gnttab)) {
/* Fall back to xc_map_foreign_range */
con->interface = xc_map_foreign_range(
xc, dom->domid, XC_PAGE_SIZE,
@@ -918,6 +928,7 @@ static int console_init(struct console *con, struct domain
*dom, void **data)
con->log_suffix = (*con_type)->log_suffix;
con->optional = (*con_type)->optional;
con->use_gnttab = (*con_type)->use_gnttab;
+ con->use_reserved_gnttab = (*con_type)->use_reserved_gnttab;
con->have_state = (*con_type)->have_state;
xsname = (char *)(*con_type)->xsname;
xspath = xs_get_domain_path(xs, dom->domid);
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 15/17] xenconsoled: add support for non-pty output
Handle 'output' xenstore entry, as qemu does. Right now support only few
simple options:
- "pty" (unchanged)
- "file:path" (overwrite file)
- "pipe:path" (read-write file/pipe)
- "null"
Also, when ever read() returns 0, stop reading from that source, instead
of spinning in a loop.
For now, in case of reconnect, intentionally use pty (ignore 'output'
xenstore entry), as for normal files close+open can be harmful
(especially with O_TRUNC).
Signed-off-by: Marek Marczykowski-Górecki
---
According to qemu docs, "pipe" should behave differently - it should
open two pipes, with ".in" and ".out". According to actual qemu code, it
does that, but if it fails it fallbacks to just one file. And libxl
relies on that fallback, so I've implemented that version only.
If xenconsoled would have some man page, I'd add it there...
---
tools/console/daemon/io.c | 62
1 file changed, 57 insertions(+), 5 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index ea07442..15deca4 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -96,6 +96,8 @@ struct console {
int master_fd;
int master_pollfd_idx;
int slave_fd;
+ bool master_fd_can_read;
+ bool master_fd_can_write;
int log_fd;
struct buffer buffer;
char *xspath;
@@ -730,6 +732,53 @@ static void console_unmap_interface(struct console *con)
con->ring_ref = -1;
}
+static int create_console_output(struct console *con)
+{
+ int err;
+ char *output, *path;
+
+ if (asprintf(&path, "%s/%s", con->xspath, "output") == -1) {
+ err = ENOMEM;
+ goto out;
+ }
+
+ con->master_fd_can_read = true;
+ con->master_fd_can_write = true;
+
+ output = xs_read(xs, XBT_NULL, path, NULL);
+
+ if (!output || !strcmp(output, "pty")) {
+ if (!console_create_tty(con)) {
+ err = errno;
+ goto out;
+ }
+ } else if (!strncmp(output, "file:", 5)) {
+ con->master_fd = open(output+5, O_WRONLY | O_CREAT | O_TRUNC,
0600);
+ if (con->master_fd == -1) {
+ err = errno;
+ goto out;
+ }
+ /* this is write-only file */
+ con->master_fd_can_read = false;
+ } else if (!strncmp(output, "pipe:", 5)) {
+ con->master_fd = open(output+5, O_RDWR);
+ if (con->master_fd == -1) {
+ err = errno;
+ goto out;
+ }
+ } else if (!strcmp(output, "null")) {
+ con->master_fd = open("/dev/null", O_RDWR);
+ if (con->master_fd == -1) {
+ err = errno;
+ goto out;
+ }
+ }
+
+ err = 0;
+out:
+ return err;
+}
+
static int console_create_ring(struct console *con)
{
int err, remote_port, ring_ref, rc;
@@ -825,10 +874,9 @@ static int console_create_ring(struct console *con)
con->remote_port = remote_port;
if (con->master_fd == -1) {
- if (!console_create_tty(con)) {
- err = errno;
+ err = create_console_output(con);
+ if (err)
goto err_xce;
- }
}
if (log_guest && (con->log_fd == -1))
@@ -941,6 +989,8 @@ static int console_init(struct console *con, struct domain
*dom, void **data)
con->master_fd = -1;
con->master_pollfd_idx = -1;
+ con->master_fd_can_read = true;
+ con->master_fd_can_write = true;
con->slave_fd = -1;
con->log_fd = -1;
con->ring_ref = -1;
@@ -1152,6 +1202,8 @@ static void handle_tty_read(struct console *con)
*/
if (len < 0) {
console_handle_broken_tty(con, domain_is_valid(dom->domid));
+ } else if (len == 0) {
+ con->master_fd_can_read = false;
} else if (domain_is_valid(dom->domid)) {
prod = intf->in_prod;
for (i = 0; i < len; i++) {
@@ -1396,10 +1448,10 @@ static void maybe_add_console_tty_fd(struct console
*con)
{
if (con->master_fd != -1) {
short events = 0;
- if (!con->d->is_dead && ring_free_bytes(con))
+ if (!con->d->is_dead && con->master_fd_can_read &&
ring_free_bytes(con))
events |= POLLIN;
- if (!buffer_empty(&con->buffer))
+ if (con->master_fd_can_write && !buffer_empty(&con->buffer))
events |= POLLOUT;
if (events)
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 05/17] libxl: use xenstore for pci hotplug qemu-in-linux-stubdom commands
From: Simon Gaiser
There is no QMP socket access, re-use the same mechanism as for MiniOS
based stubdom.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libxl/libxl_pci.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4755a0c..311fad4 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -995,6 +995,7 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid,
libxl_device_pci *pcidev, i
uint32_t flag = XEN_DOMCTL_DEV_RDM_RELAXED;
uint32_t domainid = domid;
bool isstubdom = libxl_is_stubdom(ctx, domid, &domainid);
+uint32_t dm_domid;
if (type == LIBXL_DOMAIN_TYPE_INVALID)
return ERROR_FAIL;
@@ -1010,7 +1011,15 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid,
libxl_device_pci *pcidev, i
rc = qemu_pci_add_xenstore(gc, domid, pcidev);
break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-rc = libxl__qmp_pci_add(gc, domid, pcidev);
+dm_domid = libxl_get_stubdom_id(ctx, domid);
+
+if (dm_domid != 0
+&& libxl__stubdomain_version_running(gc, dm_domid) ==
+ LIBXL_STUBDOMAIN_VERSION_LINUX) {
+rc = qemu_pci_add_xenstore(gc, domid, pcidev);
+} else {
+rc = libxl__qmp_pci_add(gc, domid, pcidev);
+}
break;
default:
return ERROR_INVAL;
@@ -1362,7 +1371,7 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
libxl_device_pci *assigned;
libxl_domain_type type = libxl__domain_type(gc, domid);
int hvm = 0, rc, num;
-int stubdomid = 0;
+int stubdomid = libxl_get_stubdom_id(ctx, domid);
uint32_t domainid = domid;
bool isstubdom = libxl_is_stubdom(ctx, domid, &domainid);
@@ -1390,7 +1399,13 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
rc = qemu_pci_remove_xenstore(gc, domid, pcidev, force);
break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-rc = libxl__qmp_pci_del(gc, domid, pcidev);
+if (stubdomid != 0
+&& libxl__stubdomain_version_running(gc, stubdomid) ==
+ LIBXL_STUBDOMAIN_VERSION_LINUX) {
+rc = qemu_pci_remove_xenstore(gc, domid, pcidev, force);
+} else {
+rc = libxl__qmp_pci_del(gc, domid, pcidev);
+}
break;
default:
rc = ERROR_INVAL;
@@ -1470,7 +1485,6 @@ out:
LOGED(ERROR, domainid, "xc_deassign_device failed");
}
-stubdomid = libxl_get_stubdom_id(ctx, domid);
if (stubdomid != 0) {
libxl_device_pci pcidev_s = *pcidev;
libxl__device_pci_remove_common(gc, stubdomid, &pcidev_s, force);
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 07/17] libxl: add save/restore support for qemu-xen in stubdomain
Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
relevant consoles.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
---
tools/libxl/libxl_dm.c | 23 +++
tools/libxl/libxl_dom_suspend.c | 10 --
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 167dad9..330d552 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1454,10 +1454,17 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
flexarray_append(dm_args, "-xen-domid-restrict");
if (state->saved_state) {
-/* This file descriptor is meant to be used by QEMU */
-*dm_state_fd = open(state->saved_state, O_RDONLY);
-flexarray_append(dm_args, "-incoming");
-flexarray_append(dm_args, GCSPRINTF("fd:%d",*dm_state_fd));
+if (is_stubdom) {
+/* Linux stubdomain connects specific FD to STUBDOM_CONSOLE_RESTORE
+ */
+flexarray_append(dm_args, "-incoming");
+flexarray_append(dm_args, "fd:3");
+} else {
+/* This file descriptor is meant to be used by QEMU */
+*dm_state_fd = open(state->saved_state, O_RDONLY);
+flexarray_append(dm_args, "-incoming");
+flexarray_append(dm_args, GCSPRINTF("fd:%d",*dm_state_fd));
+}
}
for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
flexarray_append(dm_args, b_info->extra[i]);
@@ -1940,14 +1947,6 @@ void libxl__spawn_stub_dm(libxl__egc *egc,
libxl__stub_dm_spawn_state *sdss)
assert(libxl_defbool_val(guest_config->b_info.device_model_stubdomain));
-if (guest_config->b_info.stubdomain_version ==
LIBXL_STUBDOMAIN_VERSION_LINUX) {
-if (d_state->saved_state) {
-LOG(ERROR, "Save/Restore not supported yet with Linux Stubdom.");
-ret = -1;
-goto out;
-}
-}
-
sdss->pvqemu.guest_domid = 0;
libxl_domain_create_info_init(&dm_config->c_info);
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 1e904ba..8c8ae84 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -73,7 +73,8 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
{
int ret = 0;
uint32_t const domid = dsps->domid;
-const char *const filename = dsps->dm_savefile;
+uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
+const char * filename = dsps->dm_savefile;
switch (libxl__device_model_version_running(gc, domid)) {
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
@@ -86,8 +87,13 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
if (libxl__qmp_stop(gc, domid))
return ERROR_FAIL;
/* Save DM state into filename */
+if (dm_domid) {
+/* if DM is in stubdomain, instruct it to use console, which is
+ * connected to a file pointed by filename */
+filename = "/proc/self/fd/4";
+}
ret = libxl__qmp_save(gc, domid, filename, dsps->live);
-if (ret)
+if (ret && !dm_domid)
unlink(filename);
break;
default:
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 16/17] libxl: access QMP socket via console for qemu-in-stubdomain
Add support for talking with qemu in stubdomain via QMP connected to a
console. Since a console doesn't have out of band connect/disconnect
signaling, use (new) qmp_reset command at every connect, to force
renegotiation.
This commit doesn't deal with multiple users accessing the same console.
For example all connected libxl users will see responses for commands
send by any user. If commands IDs would be unique (they aren't),
theoretically that wouldn't be a problem. But two instances sending
commands at once is still problematic.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libxl/libxl_dm.c | 18 -
tools/libxl/libxl_internal.h | 5 ++--
tools/libxl/libxl_qmp.c | 52 +
3 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 6eea377..ab851cc 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -959,18 +959,23 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
"-xen-domid",
GCSPRINTF("%d", guest_domid), NULL);
-/* There is currently no way to access the QMP socket in the stubdom */
-if (!is_stubdom) {
-flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args, "-chardev");
+/* stubdom + qemu-xen implies linux based stubdom */
+if (is_stubdom)
+flexarray_append(dm_args,
+ GCSPRINTF("serial,id=libxl-cmd,path=/dev/hvc%d",
+ STUBDOM_CONSOLE_QMP));
+else
flexarray_append(dm_args,
GCSPRINTF("socket,id=libxl-cmd,"
"path=%s/qmp-libxl-%d,server,nowait",
libxl__run_dir_path(), guest_domid));
-flexarray_append(dm_args, "-no-shutdown");
-flexarray_append(dm_args, "-mon");
-flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
+flexarray_append(dm_args, "-no-shutdown");
+flexarray_append(dm_args, "-mon");
+flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
+if (!is_stubdom) {
flexarray_append(dm_args, "-chardev");
flexarray_append(dm_args,
GCSPRINTF("socket,id=libxenstat-cmd,"
@@ -2143,6 +2148,7 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
/* STUBDOM_CONSOLE_LOGGING (console 0) is for minios logging
* STUBDOM_CONSOLE_SAVE (console 1) is for writing the save file
* STUBDOM_CONSOLE_RESTORE (console 2) is for reading the save file
+ * STUBDOM_CONSOLE_QMP (console 3) is for accessing qmp socket (linux
stubdom only)
*/
switch (i) {
char *filename;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fbcb0b7..8ef415e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -115,8 +115,9 @@
#define STUBDOM_CONSOLE_LOGGING 0
#define STUBDOM_CONSOLE_SAVE 1
#define STUBDOM_CONSOLE_RESTORE 2
-#define STUBDOM_CONSOLE_SERIAL 3
-#define STUBDOM_SPECIAL_CONSOLES 3
+#define STUBDOM_CONSOLE_QMP 3
+#define STUBDOM_CONSOLE_SERIAL 4
+#define STUBDOM_SPECIAL_CONSOLES 4
#define LIBXL_LINUX_STUBDOM_MEM 128
#define TAP_DEVICE_SUFFIX "-emu"
#define DOMID_XS_PATH "domid"
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 987bf02..b39ff90 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -476,6 +476,16 @@ out:
return ret;
}
+static int qmp_open_pty(libxl__qmp_handler *qmp, const char *qmp_pty_path)
+{
+qmp->qmp_fd = open(qmp_pty_path,
+ O_RDWR | O_NOCTTY | O_NONBLOCK | O_CLOEXEC);
+if (qmp->qmp_fd < 0) {
+return -1;
+}
+return 0;
+}
+
static void qmp_close(libxl__qmp_handler *qmp)
{
callback_id_pair *pp = NULL;
@@ -766,15 +776,47 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc,
uint32_t domid)
int ret = 0;
libxl__qmp_handler *qmp = NULL;
char *qmp_socket;
+uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
qmp = qmp_init_handler(gc, domid);
if (!qmp) return NULL;
-qmp_socket = GCSPRINTF("%s/qmp-libxl-%d", libxl__run_dir_path(), domid);
-if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
-LOGED(ERROR, domid, "Connection error");
-qmp_free_handler(qmp);
-return NULL;
+if (dm_domid) {
+/* sanity check */
+if (libxl__stubdomain_version_running(gc, dm_domid) ==
+LIBXL_STUBDOMAIN_VERSION_MINIOS) {
+LOGED(ERROR, domid, "QMP socket unsupported for minios
stubdomain");
+qmp_free_handler(qmp);
+return NULL;
+}
+ret = libxl_console_get_tty(CTX, dm_domid,
+STUBDOM_CONSOLE_QMP,
+LIBXL_CONSOLE_TYPE_PV,
+&qmp_socke
[Xen-devel] [RFC PATCH v2 08/17] xl: add stubdomain related options to xl config parser
Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Jason Andryuk --- docs/man/xl.cfg.pod.5.in | 23 +++ tools/xl/xl_parse.c | 7 +++ 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in index b727181..54a9585 100644 --- a/docs/man/xl.cfg.pod.5.in +++ b/docs/man/xl.cfg.pod.5.in @@ -2700,10 +2700,25 @@ model which they were installed with. =item B -Override the path to the binary to be used as the device-model. The -binary provided here MUST be consistent with the -B which you have specified. You should not -normally need to specify this option. +Override the path to the binary to be used as the device-model running in +toolstack domain. The binary provided here MUST be consistent with the +B which you have specified. You should not normally need +to specify this option. + +=item B + +Override the path to the kernel image used as device-model stubdomain. +The binary provided here MUST be consistent with the +B which you have specified. +In case of B it is expected to be MiniOS-based stubdomain +image, in case of B it is expected to be Linux-based stubdomain +kernel. + +=item B + +Override the path to the ramdisk image used as device-model stubdomain. +The binary provided here is to be used by a kernel pointed by B. +It is known to be used only by Linux-based stubdomain kernel. =item B diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 971ec1b..a7cd8a7 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -2496,6 +2496,13 @@ skip_usbdev: xlu_cfg_replace_string(config, "device_model_user", &b_info->device_model_user, 0); +xlu_cfg_replace_string (config, "stubdomain_kernel", +&b_info->stubdomain_kernel, 0); +xlu_cfg_replace_string (config, "stubdomain_ramdisk", +&b_info->stubdomain_ramdisk, 0); +if (!xlu_cfg_get_long (config, "stubdomain_memory", &l, 0)) +b_info->stubdomain_memkb = l * 1024; + #define parse_extra_args(type)\ e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \ &b_info->extra##type, 0);\ -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 13/17] xenconsoled: add support for up to 3 secondary consoles
Based on previous few commits, this adds basic support for multiple
consoles in xenconsoled. A static number of them - up to 3 (+ one
primary).
Signed-off-by: Marek Marczykowski-Górecki
---
I know this is awful, but everything else I can think of (real support
for multiple consoles, dynamically allocated) requires major restructure
of the code. Given I'm still not sure if multiple consoles are the way
to go with stubdomain, I'd rather not invest time in something that
could never by actually useful.
---
tools/console/daemon/io.c | 24
1 file changed, 24 insertions(+)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 3f2b9cb..c2c37dc 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -134,6 +134,30 @@ static struct console_type console_type[] = {
.use_gnttab = true,
.use_reserved_gnttab = true,
},
+ {
+ .xsname = "/device/console/1",
+ .ttyname = "tty",
+ .log_suffix = "-con1",
+ .optional = true,
+ .use_gnttab = true,
+ .have_state = true,
+ },
+ {
+ .xsname = "/device/console/2",
+ .ttyname = "tty",
+ .log_suffix = "-con2",
+ .optional = true,
+ .use_gnttab = true,
+ .have_state = true,
+ },
+ {
+ .xsname = "/device/console/3",
+ .ttyname = "tty",
+ .log_suffix = "-con3",
+ .optional = true,
+ .use_gnttab = true,
+ .have_state = true,
+ },
#if defined(CONFIG_ARM)
{
.xsname = "/vuart/0",
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 09/17] libxl: use \x1b to separate qemu arguments for linux stubdomain
This allows using arguments with spaces, like -append.
Stubdomain side of this require "xenstore-client: Add option for raw
in-/output" commit.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
---
tools/libxl/libxl_dm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 330d552..6eea377 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1855,6 +1855,7 @@ static int libxl__write_stub_dmargs(libxl__gc *gc,
int i;
char *vm_path;
char *dmargs, *path;
+const char arg_sep = linux_stubdom ? '\x1b' : ' ';
int dmargs_size;
struct xs_permissions roperm[2];
xs_transaction_t t;
@@ -1880,8 +1881,9 @@ static int libxl__write_stub_dmargs(libxl__gc *gc,
if (linux_stubdom ||
(strcmp(args[i], "-sdl") &&
strcmp(args[i], "-M") && strcmp(args[i], "xenfv"))) {
-strcat(dmargs, " ");
strcat(dmargs, args[i]);
+if (args[i + 1] != NULL)
+strncat(dmargs, &arg_sep, 1);
}
i++;
}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v2 01/17] libxl: fix qemu-trad cmdline for no sdl/vnc case
When qemu is running in stubdomain, any attempt to initialize vnc/sdl
there will crash it (on failed attempt to load a keymap from a file). If
vfb is present, all those cases are skipped. But since
b053f0c4c9e533f3d97837cf897eb920b8355ed3 "libxl: do not start dom0 qemu
for stubdomain when not needed" it is possible to create a stubdomain
without vfb and contrary to the comment -vnc none do trigger VNC
initialization code (just skips exposing it externally).
Change the implicit SDL avoiding method to -nographics option, used when
none of SDL or VNC is enabled.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
---
Changes in v2:
- typo in qemu option
---
tools/libxl/libxl_dm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index fdd7fa3..ebe8e0c 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -475,14 +475,14 @@ static int libxl__build_device_model_args_old(libxl__gc
*gc,
if (libxl_defbool_val(vnc->findunused)) {
flexarray_append(dm_args, "-vncunused");
}
-} else
+} else if (!sdl)
/*
* VNC is not enabled by default by qemu-xen-traditional,
- * however passing -vnc none causes SDL to not be
- * (unexpectedly) enabled by default. This is overridden by
- * explicitly passing -sdl below as required.
+ * however skipping -vnc causes SDL to be
+ * (unexpectedly) enabled by default. If undesired, disable graphics at
+ * all.
*/
-flexarray_append_pair(dm_args, "-vnc", "none");
+flexarray_append(dm_args, "-nographic");
if (sdl) {
flexarray_append(dm_args, "-sdl");
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125776: trouble: blocked/broken/pass
flight 125776 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125776/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen e752f28409678ce3ade49986b39309178fb2a6d6 baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z5 days Failing since125741 2018-08-02 10:01:09 Z4 days5 attempts Testing same since 125772 2018-08-06 16:00:37 Z0 days3 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini jobs: build-arm64-xsm broken build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64-xsm broken broken-step build-arm64-xsm hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 480 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125774: trouble: blocked/broken/pass
flight 125774 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125774/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen e752f28409678ce3ade49986b39309178fb2a6d6 baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z5 days Failing since125741 2018-08-02 10:01:09 Z4 days4 attempts Testing same since 125772 2018-08-06 16:00:37 Z0 days2 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini jobs: build-arm64-xsm broken build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64-xsm broken broken-step build-arm64-xsm hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 480 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/biomerge: Use true and false for boolean values
On 08/06/2018 07:42 AM, Juergen Gross wrote: > On 05/08/18 02:50, Gustavo A. R. Silva wrote: >> Return statements in functions returning bool should use true or false >> instead of an integer value. >> >> This code was detected with the help of Coccinelle. >> >> Signed-off-by: Gustavo A. R. Silva > Reviewed-by: Juergen Gross Thanks. Applied to for-linus-4.19 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
On 08/06/2018 04:16 PM, Thomas Gleixner wrote: > On Mon, 6 Aug 2018, Boris Ostrovsky wrote: > >> x86 maintainers, this needs your ack please. > Reviewed-by: Thomas Gleixner > Thanks. Applied to for-linus-4.19 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
On Mon, 6 Aug 2018, Boris Ostrovsky wrote: > x86 maintainers, this needs your ack please. Reviewed-by: Thomas Gleixner ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
x86 maintainers, this needs your ack please.
-boris
On 07/24/2018 08:45 AM, M. Vefa Bicakci wrote:
> Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
> adjustment corruption") has moved the query and calculation of the
> x86_virt_bits and x86_phys_bits fields of the cpuinfo_x86 struct
> from the get_cpu_cap function to a new function named
> get_cpu_address_sizes.
>
> One of the call sites related to Xen PV VMs was unfortunately missed
> in the aforementioned commit. This prevents successful boot-up of
> kernel versions 4.17 and up in Xen PV VMs if CONFIG_DEBUG_VIRTUAL
> is enabled, due to the following code path:
>
> enlighten_pv.c::xen_start_kernel
> mmu_pv.c::xen_reserve_special_pages
> page.h::__pa
> physaddr.c::__phys_addr
> physaddr.h::phys_addr_valid
>
> phys_addr_valid uses boot_cpu_data.x86_phys_bits to validate physical
> addresses. boot_cpu_data.x86_phys_bits is no longer populated before
> the call to xen_reserve_special_pages due to the aforementioned commit
> though, so the validation performed by phys_addr_valid fails, which
> causes __phys_addr to trigger a BUG, preventing boot-up.
>
> Signed-off-by: M. Vefa Bicakci
> Cc: "Kirill A. Shutemov"
> Cc: Andy Lutomirski
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Thomas Gleixner
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: xen-devel@lists.xenproject.org
> Cc: x...@kernel.org
> Cc: sta...@vger.kernel.org # for v4.17 and up
> Fixes: d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits adjustment
> corruption")
>
> ---
>
> Changes since v1:
> - Move the call to get_cpu_address_sizes below the call to
> x86_configure_nx.
> - Amend the commit message to describe why PV VMs do not boot up
> successfully when CONFIG_DEBUG_VIRTUAL is enabled.
> ---
> arch/x86/kernel/cpu/common.c | 2 +-
> arch/x86/kernel/cpu/cpu.h| 1 +
> arch/x86/xen/enlighten_pv.c | 3 +++
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index f73fa6f6d85e..dd282482de09 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -911,7 +911,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> apply_forced_caps(c);
> }
>
> -static void get_cpu_address_sizes(struct cpuinfo_x86 *c)
> +void get_cpu_address_sizes(struct cpuinfo_x86 *c)
> {
> u32 eax, ebx, ecx, edx;
>
> diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
> index 38216f678fc3..12a5f0cec0b2 100644
> --- a/arch/x86/kernel/cpu/cpu.h
> +++ b/arch/x86/kernel/cpu/cpu.h
> @@ -46,6 +46,7 @@ extern const struct cpu_dev *const __x86_cpu_dev_start[],
> *const __x86_cpu_dev_end[];
>
> extern void get_cpu_cap(struct cpuinfo_x86 *c);
> +extern void get_cpu_address_sizes(struct cpuinfo_x86 *c);
> extern void cpu_detect_cache_sizes(struct cpuinfo_x86 *c);
> extern void init_scattered_cpuid_features(struct cpuinfo_x86 *c);
> extern u32 get_scattered_cpuid_leaf(unsigned int level,
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 105a57d73701..ee3b00c7acda 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -1256,6 +1256,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
> get_cpu_cap(&boot_cpu_data);
> x86_configure_nx();
>
> + /* Determine virtual and physical address sizes */
> + get_cpu_address_sizes(&boot_cpu_data);
> +
> /* Let's presume PV guests always boot on vCPU with id 0. */
> per_cpu(xen_vcpu_id, 0) = 0;
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] backport of XSA-274 patch to 4.9.x kernel (could use a review)
I just got the following patch from a colleague. It's a backport of
the XSA 274 kernel patch to 4.9.x kernels. The kernel patch given in
the XSA would not apply cleanly. Would someone mind reviewing it? It
would be much appreciated.
commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
This version applies to v4.9.
error_entry and error_exit communicate the user vs kernel status of
the frame using %ebx. This is unnecessary -- the information is in
regs->cs. Just use regs->cs.
This makes error_entry simpler and makes error_exit more robust.
It also fixes a nasty bug. Before all the Spectre nonsense, The
xen_failsafe_callback entry point returned like this:
ALLOC_PT_GPREGS_ON_STACK
SAVE_C_REGS
SAVE_EXTRA_REGS
ENCODE_FRAME_POINTER
jmp error_exit
And it did not go through error_entry. This was bogus: RBX
contained garbage, and error_exit expected a flag in RBX.
Fortunately, it generally contained *nonzero* garbage, so the
correct code path was used. As part of the Spectre fixes, code was
added to clear RBX to mitigate certain speculation attacks. Now,
depending on kernel configuration, RBX got zeroed and, when running
some Wine workloads, the kernel crashes. This was introduced by:
commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
exceptions/interrupts, to reduce speculation attack surface")
With this patch applied, RBX is no longer needed as a flag, and the
problem goes away.
Cc: Brian Gerst
Cc: Borislav Petkov
Cc: Dominik Brodowski
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
Cc: Andy Lutomirski
Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for exceptions/interrupts,
to reduce speculation attack surface")
Reported-and-tested-by: "M. Vefa Bicakci"
Signed-off-by: Sarah Newman
---
arch/x86/entry/entry_64.S | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index d58d8dc..0dab47a 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -774,7 +774,7 @@ ENTRY(\sym)
call\do_sym
- jmp error_exit /* %ebx: no swapgs flag */
+ jmp error_exit
.endif
END(\sym)
.endm
@@ -1043,7 +1043,6 @@ END(paranoid_exit)
/*
* Save all registers in pt_regs, and switch gs if needed.
- * Return: EBX=0: came from user mode; EBX=1: otherwise
*/
ENTRY(error_entry)
cld
@@ -1087,7 +1086,6 @@ ENTRY(error_entry)
* for these here too.
*/
.Lerror_kernelspace:
- incl%ebx
leaqnative_irq_return_iret(%rip), %rcx
cmpq%rcx, RIP+8(%rsp)
je .Lerror_bad_iret
@@ -1119,28 +1117,19 @@ ENTRY(error_entry)
/*
* Pretend that the exception came from user mode: set up pt_regs
-* as if we faulted immediately after IRET and clear EBX so that
-* error_exit knows that we will be returning to user mode.
+* as if we faulted immediately after IRET.
*/
mov %rsp, %rdi
callfixup_bad_iret
mov %rax, %rsp
- decl%ebx
jmp .Lerror_entry_from_usermode_after_swapgs
END(error_entry)
-
-/*
- * On entry, EBX is a "return to kernel mode" flag:
- * 1: already in kernel mode, don't need SWAPGS
- * 0: user gsbase is loaded, we need SWAPGS and standard preparation for
return to usermode
- */
ENTRY(error_exit)
- movl%ebx, %eax
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
- testl %eax, %eax
- jnz retint_kernel
+ testb $3, CS(%rsp)
+ jz retint_kernel
jmp retint_user
END(error_exit)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] x86/spec-ctrl: Add support for modifying SSBD AMD VIA LS_CFG MSR
On Thu, Aug 02, 2018 at 01:09:06AM -0600, Jan Beulich wrote: > >>> On 02.08.18 at 00:20, wrote: > > On Tue, Jul 31, 2018 at 05:25:27AM -0600, Jan Beulich wrote: > >> Code structure wise this looks to undo a fair part of what patch > >> 1 has done. It would be nice to limit code churn. > > > > Patch 1 stand alone just to improve reporting the capabilities of the > > processor. Currently Xen doesn't mention anything if SSBD is actually > > enable on AMD processors. Patch 2-3 add it where Xen can it > > dynamically. > > Which is all fine, but couldn't patch 1 be written in a way that the > next one(s) don't have to turn code structure all over again. Rather than change 1, I changed patch 3 (well now patch 2). > >> Why can't this be called from init_speculation_mitigations()? > > > > IIRC I was having memory init problems with. It was moved to later in > > the boot so that xmalloc would work correctly. I haven't touched this > > code in over month. If you want a 100% tested answer I can retest > > putting it in init_speculation_mitigations(). > > Would be nice if that could be arranged for, as the rather specialized > call looks pretty odd in (iirc __start_xen(); iirc because you've dropped > too much of the context in your reply, and I'm too lazy to dig out the > original patch again). It was __start_xen(). Well, IIRC xalloc didn't work (well writing to the address given) until after arch_init_memory(). For it to work in init_speculation_mitigations(), I'd assume you'd need to call arch_init_memory() before init_speculation_mitigations(). > >> You really should notice such anomalies / inconsistencies yourself: > >> You properly use uint64_t here, so why not also uint32_t on the > >> preceding line? That said - why a fixed width type anyway for > >> those variables - unsigned int looks to be just fine there. > > > > IIRC they're __32 in struct I'm reading from so I decided to use that. > > I can change them though, that's easily. > > Thanks - we prefer to avoid u and s in favor of uint_t > and int_t in new code, and __u as well as __s should > go away rather sooner than later anyway, as representing name > space violations (__s8, for example, already looks to be unused). Noted, I've changed all of them. > >> This function is called from exactly one place, with the > >> parameter set to true. Makes me wonder what the actual > >> purpose of this patch is. > > > > See earlier in this email. > > Where? I can't find anything as to the purpose. Your response to > patch 1's comments on mine might have been a hint, but then again > the function parameter here seems contrary to the alternatives > patching plans, at least at the first glance. If you want to keep > the parameter (rather than introducing it when needed), please at > least outline the plans in the description. To be honest, I assumed that only patch 1 would get accepted and then once there was the infrastructure (alternative c funcs), I'd rework the rest into a patch set that would introduce allowing HVM guests to change SSBD via MSR interception (since there is some interest in that). I guess I should have been clearer up front about it. > >> Still I wonder whether less code duplication wouldn't be better. > > > > current_cpu_data isn't available when ssbd_amd_ls_cfg_init is called. > > By "isn't available" you mean "hasn't been populated yet"? Else > I don't understand. It hasn't been populated yet. > >> I find such a hard-coded upper bound quite concerning. Is nr_sockets > >> not correct in the AMD case? If so, that would want fixing, such that > >> you can use the variable here. > > > > It's been a while since I wrote this but IIRC, it has to do with > > nr_sockets either being off or not available when the code is run. > > For Family 17h which the patches are for, there's a max of two sockets. > > I've implied that from how you wrote the patches, but such hard coding > will only make for more code churn later on. Try to be as generic as > possible. Well, nr_sockets gets set in smp_prepare_cpus, which gets called after init_speculation_mitigations() and ssbd_amd_ls_cfg_init(). It could be put later on in the boot, but it needs to be run at least before other cpus are brought online. I'm welcome to any suggestions about how to restructure things though. Also, settings SSBD via the LS_CFG MSR is not a permanent method. Once hardware supports using SPEC_CTRL for it, it won't be needed. For multisocket systems, there should only be 2 sockets. I agree with making things generic, but this early in the boot there's limited information. > >> Btw - why the xen_ prefix for the variable? > > > > See the first reply, but basically it's for if Xen has SSBD turned on > > or not via using the LS_CFG MSR. > > Personally I'd prefer if the xen_-prefixed sub-name-space was left to > the public interface. Make it an infix if you want to express what you've > explained? > > Jan Noted. I'll change that. Thanks again for the feedb
[Xen-devel] [linux-next test] 125753: regressions - trouble: blocked/broken/fail/pass
flight 125753 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/125753/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm broken build-arm64 broken build-arm64-pvops 3 capture-logs broken REGR. vs. 125735 build-arm64 3 capture-logs broken REGR. vs. 125735 build-arm64-xsm 3 capture-logs broken REGR. vs. 125735 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 125735 test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125735 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125735 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125735 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 125735 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125735 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125735 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125735 test-amd64-i386-examine 8 reboot fail REGR. vs. 125735 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 125735 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125735 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 125735 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125735 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125735 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 125735 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125735 test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 125735 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR.
[Xen-devel] [PATCH v1 3/4] xen/arm: Add SCIFA UART support for early printk
From: Oleksandr Tyshchenko Add support for Renesas "Stout" development board based on R-Car H2 SoC which has SCIFA compatible UART. Actually existing SCIF UART support (debug-scif.inc) and newly added SCIFA UART support (debug-scifa.inc) differ only in registers offsets. Signed-off-by: Oleksandr Tyshchenko CC: Stefano Stabellini CC: Julien Grall --- docs/misc/arm/early-printk.txt | 3 ++- xen/arch/arm/Rules.mk | 1 + xen/arch/arm/arm32/debug-scifa.inc | 51 ++ 3 files changed, 54 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/arm32/debug-scifa.inc diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt index f765f59..f1b55d3 100644 --- a/docs/misc/arm/early-printk.txt +++ b/docs/misc/arm/early-printk.txt @@ -39,12 +39,13 @@ the name of the machine: - fastmodel: printk on ARM Fastmodel software emulators - hikey960: printk with pl011 with Hikey 960 - juno: printk with pl011 on Juno platform - - lager: printk with SCIF0 on Renesas R-Car H2 processors + - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor) - midway: printk with the pl011 on Calxeda Midway processors - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs - omap5432: printk with UART3 on TI OMAP5432 processors - rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors - seattle: printk with pl011 for AMD Seattle processor + - stout: printk with SCIFA0 on Renesas Stout board (R-Car H2 processor) - sun6i: printk with 8250 on Allwinner A31 processors - sun7i: printk with 8250 on Allwinner A20 processors - thunderx: printk with pl011 for Cavium ThunderX processor diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index f264592..e011f8b 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -40,6 +40,7 @@ EARLY_PRINTK_mvebu := mvebu,0xd0012000 EARLY_PRINTK_omap5432 := 8250,0x4802,2 EARLY_PRINTK_rcar3 := scif,0xe6e88000 EARLY_PRINTK_seattle:= pl011,0xe101 +EARLY_PRINTK_stout := scifa,0xe6c4 EARLY_PRINTK_sun6i := 8250,0x01c28000,2 EARLY_PRINTK_sun7i := 8250,0x01c28000,2 EARLY_PRINTK_thunderx := pl011,0x87e02400 diff --git a/xen/arch/arm/arm32/debug-scifa.inc b/xen/arch/arm/arm32/debug-scifa.inc new file mode 100644 index 000..b5e60db --- /dev/null +++ b/xen/arch/arm/arm32/debug-scifa.inc @@ -0,0 +1,51 @@ +/* + * xen/arch/arm/arm32/debug-scifa.inc + * + * SCIFA specific debug code + * + * Oleksandr Tyshchenko + * Copyright (C) 2018 EPAM Systems Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * 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 General Public License for more details. + */ + +#include + +/* + * SCIFA UART wait UART to be ready to transmit + * rb: register which contains the UART base address + * rc: scratch register + */ +.macro early_uart_ready rb rc +1: +ldrh \rc, [\rb, #SCIFA_SCASSR] /* <- SCASSR (status register) */ +tst\rc, #SCASSR_TDFE /* Check TDFE bit */ +beq1b /* Wait for the UART to be ready */ +.endm + +/* + * SCIFA UART transmit character + * rb: register which contains the UART base address + * rt: register which contains the character to transmit + */ +.macro early_uart_transmit rb rt +strb \rt, [\rb, #SCIFA_SCAFTDR] /* -> SCAFTDR (data register) */ +ldrh \rt, [\rb, #SCIFA_SCASSR] /* <- SCASSR (status register) */ +and\rt, \rt, #(~(SCASSR_TEND | SCASSR_TDFE)) /* Clear TEND and TDFE bits */ +strh \rt, [\rb, #SCIFA_SCASSR] /* -> SCASSR (status register) */ +.endm + +/* + * Local variables: + * mode: ASM + * indent-tabs-mode: nil + * End: + */ -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board
From: Oleksandr Tyshchenko
Renesas "Stout" development board (with different expansion boards)
is also based on R-Car Gen2 SoC. So extend compat array with
board's compatible strings.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/platforms/rcar2.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/platforms/rcar2.c b/xen/arch/arm/platforms/rcar2.c
index df0ac84..ee2ded0 100644
--- a/xen/arch/arm/platforms/rcar2.c
+++ b/xen/arch/arm/platforms/rcar2.c
@@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
static const char *const rcar2_dt_compat[] __initconst =
{
"renesas,lager",
+"renesas,r8a7790stout",
+"renesas,r8a7790stout-view",
+"renesas,r8a7790stout-had",
+"renesas,r8a7790stout-full",
NULL
};
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 1/4] xen/arm: drivers: scif: Remove unused #define-s
From: Oleksandr Tyshchenko Signed-off-by: Oleksandr Tyshchenko CC: Stefano Stabellini CC: Julien Grall --- xen/drivers/char/scif-uart.c| 4 xen/include/asm-arm/scif-uart.h | 11 --- 2 files changed, 15 deletions(-) diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c index 4a71bac..465fb34 100644 --- a/xen/drivers/char/scif-uart.c +++ b/xen/drivers/char/scif-uart.c @@ -29,10 +29,6 @@ #include #include -#define PARITY_NONE0 -#define PARITY_EVEN1 -#define PARITY_ODD 2 - #define scif_readb(uart, off) readb((uart)->regs + (off)) #define scif_writeb(uart, off, val)writeb((val), (uart)->regs + (off)) diff --git a/xen/include/asm-arm/scif-uart.h b/xen/include/asm-arm/scif-uart.h index d030b26..8137850 100644 --- a/xen/include/asm-arm/scif-uart.h +++ b/xen/include/asm-arm/scif-uart.h @@ -47,17 +47,6 @@ #define SCSCR_CKE1(1 << 1)/* Clock Enable 1 */ #define SCSCR_CKE0(1 << 0)/* Clock Enable 0 */ -#define SCSCR_CKE00(0) -#define SCSCR_CKE01(SCSCR_CKE0) -#define SCSCR_CKE10(SCSCR_CKE1) -#define SCSCR_CKE11(SCSCR_CKE1 | SCSCR_CKE0) - -/* Serial Mode Register (SCSMR) */ -#define SCSMR_CHR (1 << 6)/* 7-bit Character Length */ -#define SCSMR_PE (1 << 5)/* Parity Enable */ -#define SCSMR_ODD (1 << 4)/* Odd Parity */ -#define SCSMR_STOP(1 << 3)/* Stop Bit Length */ - /* Serial Status Register (SCFSR) */ #define SCFSR_ER (1 << 7)/* Receive Error */ #define SCFSR_TEND(1 << 6)/* Transmission End */ -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 0/4] Renesas Stout board support (R-Car Gen2)
From: Oleksandr Tyshchenko Hi, all. The purpose of this patch series is to add required support to be able to run Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console interface. Actually Xen already has support for SCIF compatible UARTs which are used on Renesas Lager (R-Car Gen2), Salvator-X, H3ULCB/M3ULCB (R-Car Gen3) and other development boards. So this patch series extends existing support to be able to handle both interfaces. Tested on Stout (ARM32) and H3ULCB (ARM64) boards using current master. Have a plan to update Xen Wiki regarding this board. You can find current patch series here: repo: https://github.com/otyshchenko1/xen.git branch: stout_xen_4.12_unstable [1] https://elinux.org/R-Car/Boards/Stout Oleksandr Tyshchenko (4): xen/arm: drivers: scif: Remove unused #define-s xen/arm: drivers: scif: Add support for SCIFA compatible UARTs xen/arm: Add SCIFA UART support for early printk xen/arm: Reuse R-Car Gen2 platform code for Stout board docs/misc/arm/early-printk.txt | 3 +- xen/arch/arm/Rules.mk | 1 + xen/arch/arm/arm32/debug-scifa.inc | 51 ++ xen/arch/arm/platforms/rcar2.c | 4 ++ xen/drivers/char/scif-uart.c | 133 - xen/include/asm-arm/scif-uart.h| 55 ++- 6 files changed, 196 insertions(+), 51 deletions(-) create mode 100644 xen/arch/arm/arm32/debug-scifa.inc -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 2/4] xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
From: Oleksandr Tyshchenko
Extend existing driver to be able to handle SCIFA interface as well.
SCIF and SCIFA have lot in common, though SCIFA has different
offsets and bits for some registers.
Use compatible string to recognize what interface is present
on a target board.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/drivers/char/scif-uart.c| 129 +++-
xen/include/asm-arm/scif-uart.h | 44 --
2 files changed, 138 insertions(+), 35 deletions(-)
diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 465fb34..d1eb713 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -1,7 +1,7 @@
/*
* xen/drivers/char/scif-uart.c
*
- * Driver for SCIF (Serial communication interface with FIFO)
+ * Driver for SCIF(A) (Serial communication interface with FIFO (A))
* compatible UART.
*
* Oleksandr Tyshchenko
@@ -40,8 +40,57 @@ static struct scif_uart {
char __iomem *regs;
struct irqaction irqaction;
struct vuart_info vuart;
+const struct port_params *params;
} scif_com = {0};
+enum
+{
+SCIF_PORT,
+SCIFA_PORT,
+NR_PORTS,
+};
+
+struct port_params
+{
+unsigned int status_reg;
+unsigned int tx_fifo_reg;
+unsigned int rx_fifo_reg;
+unsigned int overrun_reg;
+unsigned int overrun_mask;
+unsigned int error_mask;
+unsigned int irq_flags;
+unsigned int fifo_size;
+};
+
+static const struct port_params port_params[NR_PORTS] =
+{
+[SCIF_PORT] =
+{
+.status_reg = SCIF_SCFSR,
+.tx_fifo_reg = SCIF_SCFTDR,
+.rx_fifo_reg = SCIF_SCFRDR,
+.overrun_reg = SCIF_SCLSR,
+.overrun_mask = SCLSR_ORER,
+.error_mask = SCFSR_PER | SCFSR_FER | SCFSR_BRK | SCFSR_ER,
+.irq_flags= SCSCR_RIE | SCSCR_TIE | SCSCR_REIE,
+.fifo_size= 16,
+},
+
+[SCIFA_PORT] =
+{
+.status_reg = SCIFA_SCASSR,
+.tx_fifo_reg = SCIFA_SCAFTDR,
+.rx_fifo_reg = SCIFA_SCAFRDR,
+.overrun_reg = SCIFA_SCASSR,
+.overrun_mask = SCASSR_ORER,
+.error_mask = SCASSR_PER | SCASSR_FER | SCASSR_BRK | SCASSR_ER |
+SCASSR_ORER,
+.irq_flags= SCASCR_RIE | SCASCR_TIE | SCASCR_DRIE | SCASCR_ERIE |
+SCASCR_BRIE,
+.fifo_size= 64,
+},
+};
+
static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs
*regs)
{
struct serial_port *port = data;
@@ -49,7 +98,7 @@ static void scif_uart_interrupt(int irq, void *data, struct
cpu_user_regs *regs)
uint16_t status, ctrl;
ctrl = scif_readw(uart, SCIF_SCSCR);
-status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+status = scif_readw(uart, uart->params->status_reg) & ~SCFSR_TEND;
/* Ignore next flag if TX Interrupt is disabled */
if ( !(ctrl & SCSCR_TIE) )
status &= ~SCFSR_TDFE;
@@ -65,13 +114,19 @@ static void scif_uart_interrupt(int irq, void *data,
struct cpu_user_regs *regs)
serial_rx_interrupt(port, regs);
/* Error Interrupt */
-if ( status & SCIF_ERRORS )
-scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
-if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
-scif_writew(uart, SCIF_SCLSR, 0);
+if ( status & uart->params->error_mask )
+scif_writew(uart, uart->params->status_reg,
+~uart->params->error_mask);
+if ( uart->params->overrun_reg != uart->params->status_reg )
+{
+if ( scif_readw(uart, uart->params->overrun_reg) &
+ uart->params->overrun_mask )
+scif_writew(uart, uart->params->overrun_reg,
+~uart->params->overrun_mask);
+}
ctrl = scif_readw(uart, SCIF_SCSCR);
-status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+status = scif_readw(uart, uart->params->status_reg) & ~SCFSR_TEND;
/* Ignore next flag if TX Interrupt is disabled */
if ( !(ctrl & SCSCR_TIE) )
status &= ~SCFSR_TDFE;
@@ -86,7 +141,7 @@ static void __init scif_uart_init_preirq(struct serial_port
*port)
* Wait until last bit has been transmitted. This is needed for a smooth
* transition when we come from early printk
*/
-while ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
+while ( !(scif_readw(uart, uart->params->status_reg) & SCFSR_TEND) );
/* Disable TX/RX parts and all interrupts */
scif_writew(uart, SCIF_SCSCR, 0);
@@ -95,10 +150,13 @@ static void __init scif_uart_init_preirq(struct
serial_port *port)
scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
/* Clear all errors and flags */
-scif_readw(uart, SCIF_SCFSR);
-scif_writew(uart, SCIF_SCFSR, 0);
-scif_readw(uart, SCIF_SCLSR);
-scif_writew(uart, SCIF_SCLSR, 0);
+scif_readw(uart, uart->params->status_re
[Xen-devel] [xen-unstable-smoke test] 125772: trouble: blocked/broken/pass
flight 125772 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125772/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen e752f28409678ce3ade49986b39309178fb2a6d6 baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z5 days Failing since125741 2018-08-02 10:01:09 Z4 days3 attempts Testing same since 125772 2018-08-06 16:00:37 Z0 days1 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini jobs: build-arm64-xsm broken build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64-xsm broken broken-step build-arm64-xsm hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 480 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 23/32] libxl_qmp: Respond to QMP greeting
On Thu, Aug 02, 2018 at 01:26:35PM +0200, Roger Pau Monné wrote:
> On Fri, Jul 27, 2018 at 03:06:05PM +0100, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
> > ---
> > tools/libxl/libxl_qmp.c | 36 ++--
> > 1 file changed, 30 insertions(+), 6 deletions(-)
> >
> > diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> > index e649b8054d..83afce3192 100644
> > --- a/tools/libxl/libxl_qmp.c
> > +++ b/tools/libxl/libxl_qmp.c
> > @@ -1309,6 +1309,9 @@ int libxl__qmp_initializations(libxl__gc *gc,
> > uint32_t domid,
> >
> > /* Implementation of libxl__ev_qmp */
> >
> > +/* hard coded message ID used for capability negociation */
> > +static int qmp_capability_negociation_msgid = 1;
>
> Could this be a define instead? Or at least constify it because it
> doesn't seem like it's modified (at least in this patch).
I guess a define will do.
> > static int qmp_ev_prepare_cmd(libxl__gc *gc,
> >libxl__ev_qmp *ev,
> >const char *cmd,
> > @@ -1379,7 +1382,7 @@ static int qmp_ev_handle_response(libxl__egc *egc,
> > }
> >
> > id = libxl__json_object_get_integer(o);
> > -if (id != ev->id)
> > +if (id != ev->id && id != qmp_capability_negociation_msgid)
> > return 0;
> >
> > switch (type) {
> > @@ -1413,9 +1416,21 @@ static int qmp_ev_handle_response(libxl__egc *egc,
> > abort();
> > }
> >
> > -ev->id = -1;
> > -ev->callback(egc, ev, response, rc); /* must be last */
> > -return 1;
> > +/*
> > + * Even if the current state is capability_negociation and the correct
> > ID
> > + * as been received, call the callback on error.
> > + */
> > +if (ev->qmp_state == qmp_state_capability_negociation &&
> > +id == qmp_capability_negociation_msgid &&
> > +rc == 0) {
> > +ev->qmp_state = qmp_state_connected;
> > +libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events |
> > POLLOUT);
> > +return 0;
> > +} else {
> > +ev->id = -1;
> > +ev->callback(egc, ev, response, rc); /* must be last */
> > +return 1;
> > +}
> > }
> >
> > /* return 1 when a user callback as been called */
> > @@ -1429,6 +1444,11 @@ static int qmp_ev_handle_message(libxl__egc *egc,
> > switch (type) {
> > case LIBXL__QMP_MESSAGE_TYPE_QMP:
> > /* greeting message */
> > +assert(ev->qmp_state == qmp_state_connecting);
> > +ev->qmp_state = qmp_state_greeting;
> > +/* Allow qmp_ev_callback_writable to be called in order to send
> > + * qmp_capabilities */
> > +libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events |
> > POLLOUT);
> > return 0;
> > case LIBXL__QMP_MESSAGE_TYPE_RETURN:
> > case LIBXL__QMP_MESSAGE_TYPE_ERROR:
> > @@ -1563,7 +1583,11 @@ static int qmp_ev_callback_writable(libxl__gc *gc,
> > libxl__ev_qmp *ev, int fd)
> > * be send for now will be in this call. */
> > libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events & ~POLLOUT);
> >
> > -if (ev->qmp_state == qmp_state_connected) {
> > +if (ev->qmp_state == qmp_state_greeting) {
> > +buf = qmp_prepare_qmp_cmd(gc, "qmp_capabilities", NULL,
> > + qmp_capability_negociation_msgid, &len);
> > +ev->qmp_state = qmp_state_capability_negociation;
> > +} else if (ev->qmp_state == qmp_state_connected) {
>
> A switch (ev->qmp_state) might be better.
I guess, it's less repetition of ev->qmp_state. I'll switch.
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75050: tolerable FAIL
This run is configured for baseline tests only. flight 75050 ovmf real [real] http://osstest.xensource.com/osstest/logs/75050/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75049 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75049 version targeted for testing: ovmf d3bc33731f5b039bf3df76e50cbb1f60ce697e9b baseline version: ovmf cd3a42640acdb4f5ac14ac19f22ede002124920c Last test of basis75049 2018-08-06 06:53:29 Z0 days Testing same since75050 2018-08-06 15:50:05 Z0 days1 attempts People who touched revisions under test: Dandan Bi jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit d3bc33731f5b039bf3df76e50cbb1f60ce697e9b Author: Dandan Bi Date: Tue Jul 17 10:14:04 2018 +0800 MdeModulePkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. Now the DxeSmmPerformanceLib is not used by any module. So remove it from edk2 code base to avoid being used by mistake. Cc: Liming Gao Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Liming Gao commit 29890da47d18c602c199819b78ae15c08e22cab0 Author: Dandan Bi Date: Tue Jul 17 10:10:49 2018 +0800 ShellPkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: Jaben Carsey Cc: Ruiyu Ni Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Jaben Carsey commit 18219ab369277151d908a4b6a75a8e371c810c3d Author: Dandan Bi Date: Tue Jul 17 10:10:15 2018 +0800 Vlv2TbltDevicePkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: David Wei Cc: Mang Guo Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: David Wei commit 5b292858ba9aa2a7c9fc7e4f99df8fe750399f80 Author: Dandan Bi Date: Tue Jul 17 10:06:34 2018 +0800 QuarkPlatformPkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: Michael D Kinney Cc: Kelly Steele Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Liming Gao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 31/32] libxl_disk: Cut libxl_cdrom_insert into step
On Thu, Aug 02, 2018 at 05:50:52PM +0200, Roger Pau Monné wrote: > On Fri, Jul 27, 2018 at 03:06:13PM +0100, Anthony PERARD wrote: > Can you provide a comment explaining how is this supposed to work? The > current code is already quite convoluted IMO (maybe because I'm not > familiar with it), so I think a comment would help reviewers. Have you read the CODING_STYLE file? I think you'll find that the section "ASYNCHRONOUS/LONG-RUNNING OPERATIONS" will give you some answer you are looking for. I'm not sure I'm following it perfectly, but at least partially. Thanks, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 30/32] libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp
On Thu, Aug 02, 2018 at 05:38:41PM +0200, Roger Pau Monné wrote: > On Fri, Jul 27, 2018 at 03:06:12PM +0100, Anthony PERARD wrote: > > + > > +if (qmp_ev_qemu_check_version(ev, 2, 11, 0)) > > +qmp_parameters_add_bool(gc, &args, "live", dsps->live); > > +QMP_PARAMETERS_SPRINTF(&args, "filename", "/dev/fdset/%d", fdset); > > +rc = libxl__ev_qmp_send(gc, ev, "xen-save-devices-state", args); > > I think some comments about the logic above would be helpful (at least > for me). Do you need to pass an extra argument to 2.11.0 and higher > versions in order to live-migrate? I'll keep the comment that was there before: /* live parameter was added to QEMU 2.11. It signal QEMU that the save * operation is for a live migration rather that for taking a snapshot. */ And for more explanation about this parameter, I think I'll let future archeologist find the commit that introduce its usage. (db0c7dde021c29c2ae0d847d70fb7b59e02ea522) -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 28/32] libxl_qmp: Store advertised QEMU version in libxl__ev_qmp
On Thu, Aug 02, 2018 at 05:08:15PM +0200, Roger Pau Monné wrote:
> On Fri, Jul 27, 2018 at 03:06:10PM +0100, Anthony PERARD wrote:
> > This will be used in a later patch.
> >
> > Signed-off-by: Anthony PERARD
> > ---
> > tools/libxl/libxl_internal.h | 7 +++
> > tools/libxl/libxl_qmp.c | 16
> > 2 files changed, 23 insertions(+)
> >
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 01c3868748..4fa54cdb6a 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -432,6 +432,13 @@ struct libxl__ev_qmp {
> > libxl__ev_qmp_callback *callback;
> > libxl__carefd *cfd; /* set to send a fd with the command, NULL
> > otherwise */
> >
> > +/* read-only when Connected */
> > +struct {
> > +int major;
> > +int minor;
> > +int micro;
> > +} qemu_version;
>
> I would init those field to some bogus value (-1) to make sure an use
> before initialization will more likely cause a failure.
I don't think it matter, but I'll do it in libxl__ev_qmp_init.
(Those field should not be read before they have been written.)
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/blkback: remove unused pers_gnts_lock from struct xen_blkif_ring
On Mon, Aug 06, 2018 at 01:34:03PM +0200, Juergen Gross wrote: > pers_gnts_lock isn't being used anywhere. Remove it. That was likely a leftover from when the list of persistent grants was shared between rings. > Signed-off-by: Juergen Gross Reviewed-by: Roger Pau Monné Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/4] xen/blkfront: reorder tests in xlblk_init()
On Mon, Aug 06, 2018 at 01:34:02PM +0200, Juergen Gross wrote: > In case we don't want pv block devices we should not test parameters > for sanity and eventually print out error messages. So test precluding > conditions before checking parameters. > > Signed-off-by: Juergen Gross Reviewed-by: Roger Pau Monné Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/4] xen/blkfront: cleanup stale persistent grants
On Mon, Aug 06, 2018 at 01:34:01PM +0200, Juergen Gross wrote:
> Add a periodic cleanup function to remove old persistent grants which
> are no longer in use on the backend side. This avoids starvation in
> case there are lots of persistent grants for a device which no longer
> is involved in I/O business.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/block/xen-blkfront.c | 99
> ++--
> 1 file changed, 95 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index b5cedccb5d7d..19feb8835fc4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -46,6 +46,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -121,6 +122,9 @@ static inline struct blkif_req *blkif_req(struct request
> *rq)
>
> static DEFINE_MUTEX(blkfront_mutex);
> static const struct block_device_operations xlvbd_block_fops;
> +static struct delayed_work blkfront_work;
> +static LIST_HEAD(info_list);
> +static bool blkfront_work_active;
>
> /*
> * Maximum number of segments in indirect requests, the actual value used by
> @@ -216,6 +220,7 @@ struct blkfront_info
> /* Save uncomplete reqs and bios for migration. */
> struct list_head requests;
> struct bio_list bio_list;
> + struct list_head info_list;
> };
>
> static unsigned int nr_minors;
> @@ -1764,6 +1769,12 @@ static int write_per_ring_nodes(struct
> xenbus_transaction xbt,
> return err;
> }
>
> +static void free_info(struct blkfront_info *info)
> +{
> + list_del(&info->info_list);
> + kfree(info);
> +}
> +
> /* Common code used when first setting up, and when resuming. */
> static int talk_to_blkback(struct xenbus_device *dev,
> struct blkfront_info *info)
> @@ -1885,7 +1896,10 @@ static int talk_to_blkback(struct xenbus_device *dev,
> destroy_blkring:
> blkif_free(info, 0);
>
> - kfree(info);
> + mutex_lock(&blkfront_mutex);
> + free_info(info);
> + mutex_unlock(&blkfront_mutex);
> +
> dev_set_drvdata(&dev->dev, NULL);
>
> return err;
> @@ -1996,6 +2010,10 @@ static int blkfront_probe(struct xenbus_device *dev,
> info->handle = simple_strtoul(strrchr(dev->nodename, '/')+1, NULL, 0);
> dev_set_drvdata(&dev->dev, info);
>
> + mutex_lock(&blkfront_mutex);
> + list_add(&info->info_list, &info_list);
> + mutex_unlock(&blkfront_mutex);
> +
> return 0;
> }
>
> @@ -2306,6 +2324,15 @@ static void blkfront_gather_backend_features(struct
> blkfront_info *info)
> if (indirect_segments <= BLKIF_MAX_SEGMENTS_PER_REQUEST)
> indirect_segments = 0;
> info->max_indirect_segments = indirect_segments;
> +
> + if (info->feature_persistent) {
> + mutex_lock(&blkfront_mutex);
> + if (!blkfront_work_active) {
> + blkfront_work_active = true;
> + schedule_delayed_work(&blkfront_work, HZ * 10);
Does it make sense to provide a module parameter to rune the schedule
of the cleanup routine?
> + }
> + mutex_unlock(&blkfront_mutex);
Is it really necessary to have the blkfront_work_active boolean? What
happens if you queue the same delayed work more than once?
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] xen-tools-4.4.4 (SLES11): Unexpected error:
On Thu, Aug 2, 2018 at 1:13 PM, Ulrich Windl wrote: > Hi! > > WHen using "xm list test12 -l" that seems to be in pvgrub state, I get this > error: Unfortunately Xen 4.4 is long out of security support, and xm/xend was deprecated even in Xen 4.4. Have you tried using its replacement, xl? -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen/blkback: don't keep persistent grants too long
On Mon, Aug 06, 2018 at 01:33:59PM +0200, Juergen Gross wrote:
> Persistent grants are allocated until a threshold per ring is being
> reached. Those grants won't be freed until the ring is being destroyed
> meaning there will be resources kept busy which might no longer be
> used.
>
> Instead of freeing only persistent grants until the threshold is
> reached add a timestamp and remove all persistent grants not having
> been in use for a minute.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/block/xen-blkback/blkback.c | 77
> +++--
> drivers/block/xen-blkback/common.h | 1 +
> 2 files changed, 50 insertions(+), 28 deletions(-)
You should document this new parameter in
Documentation/ABI/testing/sysfs-driver-xen-blkback.
>
> diff --git a/drivers/block/xen-blkback/blkback.c
> b/drivers/block/xen-blkback/blkback.c
> index b55b245e8052..485e3ecab144 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -84,6 +84,18 @@ MODULE_PARM_DESC(max_persistent_grants,
> "Maximum number of grants to map persistently");
>
> /*
> + * How long a persistent grant is allowed to remain allocated without being
> in
> + * use. The time is in seconds, 0 means indefinitely long.
> + */
> +
> +unsigned int xen_blkif_pgrant_timeout = 60;
> +module_param_named(persistent_grant_unused_seconds, xen_blkif_pgrant_timeout,
> +uint, 0644);
> +MODULE_PARM_DESC(persistent_grant_unused_seconds,
> + "Time in seconds an unused persistent grant is allowed to "
> + "remain allocated. Default is 60, 0 means unlimited.");
> +
> +/*
> * Maximum number of rings/queues blkback supports, allow as many queues as
> there
> * are CPUs if user has not specified a value.
> */
> @@ -123,6 +135,13 @@ module_param(log_stats, int, 0644);
> /* Number of free pages to remove on each call to gnttab_free_pages */
> #define NUM_BATCH_FREE_PAGES 10
>
> +static inline bool persistent_gnt_timeout(struct persistent_gnt
> *persistent_gnt)
> +{
> + return xen_blkif_pgrant_timeout &&
> +(jiffies - persistent_gnt->last_used >=
> + HZ * xen_blkif_pgrant_timeout);
> +}
> +
> static inline int get_free_page(struct xen_blkif_ring *ring, struct page
> **page)
> {
> unsigned long flags;
> @@ -278,6 +297,7 @@ static void put_persistent_gnt(struct xen_blkif_ring
> *ring,
> {
> if(!test_bit(PERSISTENT_GNT_ACTIVE, persistent_gnt->flags))
> pr_alert_ratelimited("freeing a grant already unused\n");
> + persistent_gnt->last_used = jiffies;
> set_bit(PERSISTENT_GNT_WAS_ACTIVE, persistent_gnt->flags);
> clear_bit(PERSISTENT_GNT_ACTIVE, persistent_gnt->flags);
> atomic_dec(&ring->persistent_gnt_in_use);
> @@ -374,23 +394,23 @@ static void purge_persistent_gnt(struct xen_blkif_ring
> *ring)
> bool scan_used = false, clean_used = false;
> struct rb_root *root;
>
> - if (ring->persistent_gnt_c < xen_blkif_max_pgrants ||
> - (ring->persistent_gnt_c == xen_blkif_max_pgrants &&
> - !ring->blkif->vbd.overflow_max_grants)) {
> - goto out;
> - }
> -
> if (work_busy(&ring->persistent_purge_work)) {
> pr_alert_ratelimited("Scheduled work from previous purge is
> still busy, cannot purge list\n");
> goto out;
> }
>
> - num_clean = (xen_blkif_max_pgrants / 100) * LRU_PERCENT_CLEAN;
> - num_clean = ring->persistent_gnt_c - xen_blkif_max_pgrants + num_clean;
> - num_clean = min(ring->persistent_gnt_c, num_clean);
> - if ((num_clean == 0) ||
> - (num_clean > (ring->persistent_gnt_c -
> atomic_read(&ring->persistent_gnt_in_use
> - goto out;
> + if (ring->persistent_gnt_c < xen_blkif_max_pgrants ||
> + (ring->persistent_gnt_c == xen_blkif_max_pgrants &&
> + !ring->blkif->vbd.overflow_max_grants)) {
> + num_clean = 0;
> + } else {
> + num_clean = (xen_blkif_max_pgrants / 100) * LRU_PERCENT_CLEAN;
> + num_clean = ring->persistent_gnt_c - xen_blkif_max_pgrants +
> + num_clean;
> + num_clean = min(ring->persistent_gnt_c, num_clean);
> + pr_debug("Going to purge at least %u persistent grants\n",
> + num_clean);
> + }
>
> /*
>* At this point, we can assure that there will be no calls
> @@ -401,9 +421,7 @@ static void purge_persistent_gnt(struct xen_blkif_ring
> *ring)
> * number of grants.
>*/
>
> - total = num_clean;
> -
> - pr_debug("Going to purge %u persistent grants\n", num_clean);
> + total = 0;
>
> BUG_ON(!list_empty(&ring->persistent_purge_list));
> root = &ring->persistent_gnts;
> @@ -419,39 +437,42 @@ static void purge_persistent_gnt(struct xen_blkif_ring
> *ring)
>
> if (test_bit(PERSISTENT_GNT_ACTIVE, persistent_gnt->
Re: [Xen-devel] [PATCH v4 25/32] libxl_exec: Add libxl__spawn_initiate_failure
On Thu, Aug 02, 2018 at 01:34:52PM +0200, Roger Pau Monné wrote: > On Fri, Jul 27, 2018 at 03:06:07PM +0100, Anthony PERARD wrote: > > This function can be use by user libxl__spawn_* when they setup a >^ used and remove user I meant user of libxl__spawn, so I'll s/user/user of/ instead. > > notification other than xenstore. The parent can already called success >^ report > > via libxl__spawn_initiate_detach(), this new function can be used for > > failure instead of waiting for the timeout. > > > > Signed-off-by: Anthony PERARD > > Reviewed-by: Roger Pau Monné > Thanks, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125763: all pass - PUSHED
flight 125763 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125763/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d3bc33731f5b039bf3df76e50cbb1f60ce697e9b baseline version: ovmf cd3a42640acdb4f5ac14ac19f22ede002124920c Last test of basis 125758 2018-08-06 04:40:40 Z0 days Testing same since 125759 2018-08-06 06:40:39 Z0 days3 attempts People who touched revisions under test: Dandan Bi jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git cd3a42640a..d3bc33731f d3bc33731f5b039bf3df76e50cbb1f60ce697e9b -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 125536: regressions - FAIL
flight 125536 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125536/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 broken in 125509 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125175 test-amd64-amd64-xl-pvshim 10 debian-install fail REGR. vs. 125175 test-amd64-amd64-xl-pvhv2-amd 10 debian-install fail REGR. vs. 125175 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125175 test-amd64-i386-xl 10 debian-install fail REGR. vs. 125175 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail in 125509 REGR. vs. 125175 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 4 host-install(4) broken in 125509 pass in 125536 test-arm64-arm64-examine 2 hosts-allocate broken pass in 125509 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail pass in 125509 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-insta
[Xen-devel] [xen-unstable-smoke test] 125744: trouble: blocked/broken/pass
flight 125744 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125744/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 008a8fb249b9d433a64bc59a93075bcb4b01e3d3 baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z5 days Failing since125741 2018-08-02 10:01:09 Z4 days2 attempts Testing same since 125744 2018-08-02 13:00:46 Z4 days1 attempts People who touched revisions under test: Andrew Cooper George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini jobs: build-arm64-xsm broken build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64-xsm broken broken-step build-arm64-xsm hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 400 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 125743: trouble: blocked/broken/fail/pass
flight 125743 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/125743/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-pvopsbroken build-arm64 broken Regressions which are regarded as allowable (not blocking): build-arm64 2 hosts-allocate broken REGR. vs. 125691 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125691 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125691 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a build-arm64-pvops 3 capture-logs broken blocked in 125691 build-arm64 3 capture-logs broken blocked in 125691 build-arm64-xsm 3 capture-logs broken blocked in 125691 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125691 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125691 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125691 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125691 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125691 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125691 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125691 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125691 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125691 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 baseline version: xen 1f7574763cbb2c85825b8cc4d81f386e767a476f Last test of basis 125691 2018-07-30 21:37:12 Z
[Xen-devel] [linux-linus test] 125747: trouble: blocked/broken/fail/pass
flight 125747 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/125747/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64 broken build-arm64-pvopsbroken Regressions which are regarded as allowable (not blocking): build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125702 build-arm64 2 hosts-allocate broken REGR. vs. 125702 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125702 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 125702 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64 3 capture-logs broken blocked in 125702 build-arm64-pvops 3 capture-logs broken blocked in 125702 build-arm64-xsm 3 capture-logs broken blocked in 125702 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125702 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125702 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125702 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125702 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125702 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125702 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125702 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125702 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxef46808b79ebbf48587c556436e5281ec51d09b5 baseline version: linux
Re: [Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle messages from QEMU
On Mon, Aug 06, 2018 at 02:14:51PM +0100, Anthony PERARD wrote:
> On Mon, Aug 06, 2018 at 01:25:22PM +0200, Roger Pau Monné wrote:
> > On Fri, Aug 03, 2018 at 06:25:00PM +0100, Anthony PERARD wrote:
> > > On Thu, Aug 02, 2018 at 01:17:37PM +0200, Roger Pau Monné wrote:
> > > > On Fri, Jul 27, 2018 at 03:06:04PM +0100, Anthony PERARD wrote:
> > > > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > > > > index 4a385801ba..e104fea941 100644
> > > > > --- a/tools/libxl/libxl_types.idl
> > > > > +++ b/tools/libxl/libxl_types.idl
> > > > > @@ -69,6 +69,10 @@ libxl_error = Enumeration("error", [
> > > > > (-23, "NOTFOUND"),
> > > > > (-24, "DOMAIN_DESTROYED"), # Target domain ceased to exist
> > > > > during op
> > > > > (-25, "FEATURE_REMOVED"), # For functionality that has been
> > > > > removed
> > > > > +(-26, "QMP_GENERIC_ERROR"), # unspecified qmp error
> > > > > +(-27, "QMP_COMMAND_NOT_FOUND"), # the requested command has not
> > > > > been found
> > > > > +(-28, "QMP_DEVICE_NOT_ACTIVE"), # a device has failed to be
> > > > > become active
> > > > > +(-29, "QMP_DEVICE_NOT_FOUND"), # the requested device has not
> > > > > been found
> > > >
> > > > Do we really need such granularity for QMP errors? Isn't it enough to
> > > > have a single ERROR_QMP or similar?
> > >
> > > No I don't think so. QMP_COMMAND_NOT_FOUND can be useful when a qmp
> > > command is removed (there is already one that is deprecated and we use).
> > >
> > > The last two could be useful to user of libxl as they could provide
> > > better error messages. xl don't care because whatever error message is
> > > attach to the error, it will be printed.
> >
> > I wonder if this set of errors will change very often, at the end of
> > day it's not controlled by ourselves but QEMU, and then how much
> > chasing will libxl have to do in order to keep up with new types of
> > QMP errors.
>
> libxl doesn't have to know all the possible error code. Whenever there's
> a code that is not known, I simple return ERROR_FAIL to the caller. So
> it doesn't matter how often new error codes are added. (Also, I've
> already left out one error code which is KVM specific.)
>
> > IMO I don't see a lot of value in returning specific QMP error codes
> > from libxl, and I would even consider whether it's worth to have
> > something like ERROR_QMP, because I don't think there's much the
> > caller can do in case of QMP failure. It's an internal libxl QMP
> > error, and it's not like the caller is going to start it's own QMP
> > connection in order to speak with QEMU directly in order to solve
> > whatever QMP issue it got from libxl.
>
> Those error codes aren't "internal libxl QMP error", the QMP connection
> is working perfectly fine. All those error comes from QEMU.
>
> All those error codes are part of possible responses to a command.
>
> Here are the possible way that a caller can solve an issue with each
> error code:
>
> GenericError:
> The command failed, there's a description that a Human can read. Not
> much else can be done.
That seems to me like ERROR_NONSPECIFIC, and you can pass that error
description to the caller.
> CommandNotFound:
> Will, the QMP command that the caller is trying to use is unknown to
> the current QEMU, it's maybe a command introduced in newer version of
> QEMU, or a deprecated command that is now removed.
> Maybe the caller try to use a newer command that replace a deprecated
> one, on error, it could call the older version. And vice versa.
How would the caller do this? It's libxl the one that decides which
QMP commands to use, the caller of libxl has no idea about that.
This likely wants to be ERROR_FAIL.
> DeviceNotActive:
> The device that libxl is trying to add via the command wasn't bring up
> properly, the caller could try again with different parameters or
> inverstigate with "query-*" commands to find out what's missing.
That one seems harder to match to any existing error code, the more
that I'm not sure of it's meaning. If a device isn't brought up
properly, isn't the device simply destroyed? Does QEMU keep around
zombie devices that failed to initialize?
In any case, how is the caller of libxl supposed to use this query-*
commands?
> DeviceNotFound:
> The device that the caller is trying to modify (like a cdrom drive) is
> not found in QEMU, the caller could try to add it or let the user know
> that the device doesn't exist.
That one seems very similar to the current ERROR_NOTFOUND.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 125751: regressions - trouble: blocked/broken/fail/pass
flight 125751 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/125751/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-pvopsbroken build-arm64 broken build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Regressions which are regarded as allowable (not blocking): build-arm64 2 hosts-allocate broken REGR. vs. 123814 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 123814 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64 3 capture-logs broken blocked in 123814 build-arm64-xsm 3 capture-logs broken blocked in 123814 build-arm64-pvops 3 capture-logs broken blocked in 123814 version targeted for testing: libvirt 3ad77f853230f870efa396636e008292c7f2b1c0 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 62 days Failing since123840 2018-06-06 04:19:28 Z 61 days 46 attempts Testing same since 125751 2018-08-03 04:18:38 Z3 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Cole Robinson Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Shi Lei Shichangkuo Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský w00251574 Weilun Zhu jobs: build-amd64-xsm pass build-arm64-xsm broken build-i386-xsm pass build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt blocked build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
Re: [Xen-devel] [PATCH v4 14/32] libxl_qmp: Implement fd callback and read data
On Fri, Aug 03, 2018 at 05:24:52PM +0200, Roger Pau Monné wrote:
> On Fri, Aug 03, 2018 at 03:32:09PM +0100, Anthony PERARD wrote:
> > On Thu, Aug 02, 2018 at 11:56:11AM +0200, Roger Pau Monné wrote:
> > > On Fri, Jul 27, 2018 at 03:05:56PM +0100, Anthony PERARD wrote:
> > > > +/* The -1 is because there is always space for a NUL character
> > > > */
> > > > +r = read(fd, ev->rx_buf + ev->buf_used,
> > > > + ev->buf_size - ev->buf_used - 1);
> > > > +if (r < 0) {
> > > > +if (errno == EINTR) continue;
> > > > +assert(errno);
> > > > +if (errno == EWOULDBLOCK) {
> > > > +return 0;
> > > > +}
> > > > +LOGED(ERROR, ev->domid, "error reading QMP socket");
> > > > +return ERROR_FAIL;
> > >
> > > I think it would be clearer to use:
> > >
> > > assert(errno);
> > > switch (errno) {
> > > case EINTR:
> > > continue;
> > > case EWOULDBLOCK
> > > return 0;
> > > default:
> > > LOGED(...)
> >
> > That's not the same. In the patch, the only errno allowed is EINTR,
> > anything else is consider a programmer's mistake. For users (build with
> > NDEBUG), EWOULDBLOCK is also allowed and not considered an error and
> > other errno will attempt to let libxl generate a usefull error, instead
> > of an abort().
>
> I'm not sure I follow. According to the man page if read returns -1
> errno will always be set to indicate the error, so I'm not sure of the
> usefulness of the assert(errno), apart from checking that libc behaves
> correctly.
>
> > > > +}
> > > > +break;
> > > > +}
> > > > +
> > > > +if (r == 0) {
> > > > +LOGD(ERROR, ev->domid, "No data read on QMP socket");
> > > > +return 0;
> > > > +}
> > > > +
> > > > +LOG_QMP("received %ldB: '%.*s'", r, (int)r, ev->rx_buf +
> > > > ev->buf_used);
> > > > +
> > > > +ev->buf_used += r;
> > >
> > > Hm, don't you need to do this inside of a loop together with the
> > > realloc, in case the data on the fd is bigger than the current space
> > > on the buffer, and you need to keep growing it until you hit
> > > EWOULDBLOCK?
> > >
> > > I think with the current approach you can leave data pending in the fd
> > > if the buffer happens to be smaller than the pending data in the fd?
> >
> > You would think that, but the read loop isn't in this file. The loop is
> > part of the libxl__ev_fd.
>
> Then why do you have a loop here to handle EINTR?
>
> If the loop is somewhere else isn't it capable of handling EINTR like
> it handles partial reads? Adding the loop here just to handle EINTR
> makes it look like this is the complete read loop.
I thought I was following a pattern found elsewhere in libxl
(datacopier_readable), but apparently not. I'm not sure what would be
better to do. I think I'll just remove this loop and simply return on
EINTR.
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 125745: trouble: blocked/broken/fail/pass
flight 125745 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/125745/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-xsm broken build-arm64-pvopsbroken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125640 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125640 build-arm64 2 hosts-allocate broken REGR. vs. 125640 Tests which did not succeed, but are not blocking: build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-pvops 3 capture-logs broken blocked in 125640 build-arm64-xsm 3 capture-logs broken blocked in 125640 build-arm64 3 capture-logs broken blocked in 125640 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125640 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125640 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125640 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125640 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125640 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuuf7502360397d291be04bc040e9f96c92ff2d8030 baseline version: qemuu18a398f6a39df4b08ff86ac0d38384193ca5f4cc Last test of basis 125640 2018-07-27 22:16:44 Z9 days Failing since125675 2018-07-30 09:36:58 Z7 days4 attempts Testing same since 125732 2018-08-01 11:30:00 Z5 days2 attempts People who touched revisions under test: Alex Bennée Christian Borntraeger Cornelia Huck Dr. David Alan Gilbert Fam Zheng Geert Uytterhoeven Jay Zhou Kevin Wolf KONRAD Frederic Laurent Vivier Leonid Bloch liujunjie Marc-André Lureau Markus Armbruster Paolo Bonzini Pavel Dovgalyuk Peter Maydell Philippe Mathieu-Daudé Richard Henderson Shivaprasad G Bhat Thomas Huth jobs: build-amd64-xsm pass build-arm64-x
[Xen-devel] [xen-4.9-testing test] 125742: regressions - trouble: blocked/broken/fail/pass
flight 125742 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125742/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64 4 host-install(4)broken REGR. vs. 124328 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 124328 Regressions which are regarded as allowable (not blocking): build-arm64-pvops 2 hosts-allocate broken REGR. vs. 124328 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 124328 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 124328 build-arm64-pvops 3 capture-logs broken blocked in 124328 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 124328 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail blocked in 124328 test-amd64-amd64-xl-qemut-ws16-amd64 18 guest-start/win.repeat fail blocked in 124328 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 124248 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124328 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 124328 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124328 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen a1b223b756f354895525060bd3f9f1f07899a082 baseline version: xen 238007d6fae9447bf5e8e73d67ae9fb844e7ff2a Last test of basis 124328 2018-06-17 23:39:07 Z 49 days Failing since124807 2018-06-28 17:38:04 Z 38 days 23 attempts Testing same since 125686 2018-07-30 14:25:24 Z6 days3 attempts -
[Xen-devel] [xen-4.7-testing test] 125749: regressions - trouble: blocked/broken/fail/pass
flight 125749 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125749/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm broken build-arm64 broken test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 125057 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 125708 pass in 125749 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 125708 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 125708 Regressions which are regarded as allowable (not blocking): build-arm64 2 hosts-allocate broken REGR. vs. 125057 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125057 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125057 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a build-arm64 3 capture-logs broken blocked in 125057 build-arm64-pvops 3 capture-logs broken blocked in 125057 build-arm64-xsm 3 capture-logs broken blocked in 125057 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 125708 like 125057 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 125708 never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 125708 never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 125708 never pass test-arm64-arm64-xl 13 migrate-support-check fail in 125708 never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 125708 never pass test-arm64-arm64-xl 14 saverestore-support-check fail in 125708 never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 125708 never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 125708 never pass test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 125057 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125057 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125057 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125057 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125057 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 125057 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125057 test-amd64-amd64-xl-rtds 10 debian-install fail like 125057 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125057 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-arm
[Xen-devel] [linux-4.9 test] 125544: regressions - FAIL
flight 125544 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125544/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183 Tests which are failing intermittently (not blocking): test-arm64-arm64-examine 2 hosts-allocate broken pass in 125511 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 125511 pass in 125544 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail pass in 125511 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 14 guest-localmigrate fail pass in 125511 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 125511 like 125156 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125183 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125183 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125183 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125183 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125183 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing
Re: [Xen-devel] [PATCH] xen-blkfront: use true and false for boolean values
On 8/4/18 6:08 PM, Gustavo A. R. Silva wrote: > Return statements in functions returning bool should use true or false > instead of an integer value. > > This code was detected with the help of Coccinelle. Applied, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle messages from QEMU
On Mon, Aug 06, 2018 at 01:25:22PM +0200, Roger Pau Monné wrote:
> On Fri, Aug 03, 2018 at 06:25:00PM +0100, Anthony PERARD wrote:
> > On Thu, Aug 02, 2018 at 01:17:37PM +0200, Roger Pau Monné wrote:
> > > On Fri, Jul 27, 2018 at 03:06:04PM +0100, Anthony PERARD wrote:
> > > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > > > index 4a385801ba..e104fea941 100644
> > > > --- a/tools/libxl/libxl_types.idl
> > > > +++ b/tools/libxl/libxl_types.idl
> > > > @@ -69,6 +69,10 @@ libxl_error = Enumeration("error", [
> > > > (-23, "NOTFOUND"),
> > > > (-24, "DOMAIN_DESTROYED"), # Target domain ceased to exist during
> > > > op
> > > > (-25, "FEATURE_REMOVED"), # For functionality that has been removed
> > > > +(-26, "QMP_GENERIC_ERROR"), # unspecified qmp error
> > > > +(-27, "QMP_COMMAND_NOT_FOUND"), # the requested command has not
> > > > been found
> > > > +(-28, "QMP_DEVICE_NOT_ACTIVE"), # a device has failed to be become
> > > > active
> > > > +(-29, "QMP_DEVICE_NOT_FOUND"), # the requested device has not been
> > > > found
> > >
> > > Do we really need such granularity for QMP errors? Isn't it enough to
> > > have a single ERROR_QMP or similar?
> >
> > No I don't think so. QMP_COMMAND_NOT_FOUND can be useful when a qmp
> > command is removed (there is already one that is deprecated and we use).
> >
> > The last two could be useful to user of libxl as they could provide
> > better error messages. xl don't care because whatever error message is
> > attach to the error, it will be printed.
>
> I wonder if this set of errors will change very often, at the end of
> day it's not controlled by ourselves but QEMU, and then how much
> chasing will libxl have to do in order to keep up with new types of
> QMP errors.
libxl doesn't have to know all the possible error code. Whenever there's
a code that is not known, I simple return ERROR_FAIL to the caller. So
it doesn't matter how often new error codes are added. (Also, I've
already left out one error code which is KVM specific.)
> IMO I don't see a lot of value in returning specific QMP error codes
> from libxl, and I would even consider whether it's worth to have
> something like ERROR_QMP, because I don't think there's much the
> caller can do in case of QMP failure. It's an internal libxl QMP
> error, and it's not like the caller is going to start it's own QMP
> connection in order to speak with QEMU directly in order to solve
> whatever QMP issue it got from libxl.
Those error codes aren't "internal libxl QMP error", the QMP connection
is working perfectly fine. All those error comes from QEMU.
All those error codes are part of possible responses to a command.
Here are the possible way that a caller can solve an issue with each
error code:
GenericError:
The command failed, there's a description that a Human can read. Not
much else can be done.
CommandNotFound:
Will, the QMP command that the caller is trying to use is unknown to
the current QEMU, it's maybe a command introduced in newer version of
QEMU, or a deprecated command that is now removed.
Maybe the caller try to use a newer command that replace a deprecated
one, on error, it could call the older version. And vice versa.
DeviceNotActive:
The device that libxl is trying to add via the command wasn't bring up
properly, the caller could try again with different parameters or
inverstigate with "query-*" commands to find out what's missing.
DeviceNotFound:
The device that the caller is trying to modify (like a cdrom drive) is
not found in QEMU, the caller could try to add it or let the user know
that the device doesn't exist.
None of those error code are QMP issue.
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v20 0/2] guest resource mapping (reprise)
These patches are the patches from my original resource mapping series that did not make it into 4.11. Paul Durrant (2): common: add a new mappable resource type: XENMEM_resource_grant_table tools/libxenctrl: use new xenforeignmemory API to seed grant table tools/libxc/include/xc_dom.h| 8 +-- tools/libxc/xc_dom_boot.c | 114 +--- tools/libxc/xc_sr_restore_x86_hvm.c | 10 ++-- tools/libxc/xc_sr_restore_x86_pv.c | 2 +- tools/libxl/libxl_dom.c | 1 - tools/python/xen/lowlevel/xc/xc.c | 6 +- xen/common/grant_table.c| 74 +++ xen/common/memory.c | 56 +- xen/include/public/memory.h | 9 ++- xen/include/xen/grant_table.h | 4 ++ 10 files changed, 219 insertions(+), 65 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v20 1/2] common: add a new mappable resource type: XENMEM_resource_grant_table
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
v19:
- Add test to prevent PVH/HVM tools domains mapping grant status frames
this way as the mapping infrastructure in Xen does not yet implement the
necessary reference counting to make this safe.
- Make sure grant table version is set before any attempt to grow the table.
v18:
- Non-trivial re-base of grant table code.
- Dropped Jan's R-b because of the grant table changes.
v13:
- Re-work the internals to avoid using the XENMAPIDX_grant_table_status
hack.
v12:
- Dropped limit checks as requested by Jan.
v10:
- Addressed comments from Jan.
v8:
- The functionality was originally incorporated into the earlier patch
"x86/mm: add HYPERVISOR_memory_op to acquire guest resources".
---
xen/common/grant_table.c | 74 +++
xen/common/memory.c | 56 +++-
xen/include/public/memory.h | 9 --
xen/include/xen/grant_table.h | 4 +++
4 files changed, 127 insertions(+), 16 deletions(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index d9ec711c73..9db8e953b3 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3860,6 +3860,38 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt,
grant_ref_t ref,
}
#endif
+/* caller must hold read or write lock */
+static int gnttab_get_status_frame_mfn(struct domain *d,
+ unsigned long idx, mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+
+if ( idx >= nr_status_frames(gt) )
+return -EINVAL;
+
+*mfn = _mfn(virt_to_mfn(gt->status[idx]));
+return 0;
+}
+
+/* caller must hold write lock */
+static int gnttab_get_shared_frame_mfn(struct domain *d,
+ unsigned long idx, mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+
+if ( gt->gt_version == 0 )
+gt->gt_version = 1;
+
+if ( (idx >= nr_grant_frames(gt)) && (idx < gt->max_grant_frames) )
+gnttab_grow_table(d, idx + 1);
+
+if ( idx >= nr_grant_frames(gt) )
+return -EINVAL;
+
+*mfn = _mfn(virt_to_mfn(gt->shared_raw[idx]));
+return 0;
+}
+
int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
mfn_t *mfn)
{
@@ -3877,21 +3909,11 @@ int gnttab_map_frame(struct domain *d, unsigned long
idx, gfn_t gfn,
{
idx &= ~XENMAPIDX_grant_table_status;
status = true;
-if ( idx < nr_status_frames(gt) )
-*mfn = _mfn(virt_to_mfn(gt->status[idx]));
-else
-rc = -EINVAL;
-}
-else
-{
-if ( (idx >= nr_grant_frames(gt)) && (idx < gt->max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-if ( idx < nr_grant_frames(gt) )
-*mfn = _mfn(virt_to_mfn(gt->shared_raw[idx]));
-else
-rc = -EINVAL;
+rc = gnttab_get_status_frame_mfn(d, idx, mfn);
}
+else
+rc = gnttab_get_shared_frame_mfn(d, idx, mfn);
if ( !rc && paging_mode_translate(d) &&
!gfn_eq(gnttab_get_frame_gfn(gt, status, idx), INVALID_GFN) )
@@ -3906,6 +3928,32 @@ int gnttab_map_frame(struct domain *d, unsigned long
idx, gfn_t gfn,
return rc;
}
+int gnttab_get_shared_frame(struct domain *d, unsigned long idx,
+mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+grant_write_lock(gt);
+rc = gnttab_get_shared_frame_mfn(d, idx, mfn);
+grant_write_unlock(gt);
+
+return rc;
+}
+
+int gnttab_get_status_frame(struct domain *d, unsigned long idx,
+mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+grant_read_lock(gt);
+rc = gnttab_get_status_frame_mfn(d, idx, mfn);
+grant_read_unlock(gt);
+
+return rc;
+}
+
static void gnttab_usage_print(struct domain *rd)
{
int first = 1;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index e29d596727..7910bb16cc 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -982,6 +983,54 @@ static long xatp_permission_check(struct domain *d,
unsigned int space)
return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
}
+static int acquire_grant_table(struct domain *d, unsigned int id,
+ unsigned long frame,
+ unsigned int nr_frames,
+ xen_pfn_t mfn_list[])
+{
+unsigned int i = nr_frames;
+
+/*
+
[Xen-devel] [PATCH v20 2/2] tools/libxenctrl: use new xenforeignmemory API to seed grant table
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in which
case the old scheme is used.
NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
actually unnecessary, as the grant table has already been seeded
by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().
Signed-off-by: Paul Durrant
Acked-by: Marek Marczykowski-Górecki
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v18:
- Trivial re-base.
v13:
- Re-base.
v10:
- Use new id constant for grant table.
v4:
- Minor cosmetic fix suggested by Roger.
v3:
- Introduced xc_dom_set_gnttab_entry() to avoid duplicated code.
---
tools/libxc/include/xc_dom.h| 8 +--
tools/libxc/xc_dom_boot.c | 114 +---
tools/libxc/xc_sr_restore_x86_hvm.c | 10 ++--
tools/libxc/xc_sr_restore_x86_pv.c | 2 +-
tools/libxl/libxl_dom.c | 1 -
tools/python/xen/lowlevel/xc/xc.c | 6 +-
6 files changed, 92 insertions(+), 49 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 8a66889c68..a8a0c0da66 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -337,12 +337,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom,
xen_pfn_t pfn,
int xc_dom_boot_image(struct xc_dom_image *dom);
int xc_dom_compat_check(struct xc_dom_image *dom);
int xc_dom_gnttab_init(struct xc_dom_image *dom);
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
- xen_pfn_t console_gmfn,
- xen_pfn_t xenstore_gmfn,
- uint32_t console_domid,
- uint32_t xenstore_domid);
-int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t guest_domid,
+ bool is_hvm,
xen_pfn_t console_gmfn,
xen_pfn_t xenstore_gmfn,
uint32_t console_domid,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 2e5681dc5d..8307ebeaf6 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -256,11 +256,29 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch,
uint32_t domid)
return gmfn;
}
-int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
- xen_pfn_t console_gmfn,
- xen_pfn_t xenstore_gmfn,
- uint32_t console_domid,
- uint32_t xenstore_domid)
+static void xc_dom_set_gnttab_entry(xc_interface *xch,
+grant_entry_v1_t *gnttab,
+unsigned int idx,
+uint32_t guest_domid,
+uint32_t backend_domid,
+xen_pfn_t backend_gmfn)
+{
+if ( guest_domid == backend_domid || backend_gmfn == -1)
+return;
+
+xc_dom_printf(xch, "%s: [%u] -> 0x%"PRI_xen_pfn,
+ __FUNCTION__, idx, backend_gmfn);
+
+gnttab[idx].flags = GTF_permit_access;
+gnttab[idx].domid = backend_domid;
+gnttab[idx].frame = backend_gmfn;
+}
+
+static int compat_gnttab_seed(xc_interface *xch, uint32_t domid,
+ xen_pfn_t console_gmfn,
+ xen_pfn_t xenstore_gmfn,
+ uint32_t console_domid,
+ uint32_t xenstore_domid)
{
xen_pfn_t gnttab_gmfn;
@@ -284,18 +302,10 @@ int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
return -1;
}
-if ( domid != console_domid && console_gmfn != -1)
-{
-gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
-gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
-gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
-}
-if ( domid != xenstore_domid && xenstore_gmfn != -1)
-{
-gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
-gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
-gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
-}
+xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_CONSOLE,
+domid, console_domid, console_gmfn);
+xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_XENSTORE,
+domid, xenstore_domid, xenstore_gmfn);
if ( munmap(gnttab, PAGE_SIZE) == -1 )
{
@@ -313,11 +323,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
return 0;
}
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
- xen_pfn_t console_gpfn,
-
Re: [Xen-devel] [PATCH] xen/biomerge: Use true and false for boolean values
On 08/06/2018 06:42 AM, Juergen Gross wrote: > On 05/08/18 02:50, Gustavo A. R. Silva wrote: >> Return statements in functions returning bool should use true or false >> instead of an integer value. >> >> This code was detected with the help of Coccinelle. >> >> Signed-off-by: Gustavo A. R. Silva > > Reviewed-by: Juergen Gross > Thanks, Juergen. -- Gustavo ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/biomerge: Use true and false for boolean values
On 05/08/18 02:50, Gustavo A. R. Silva wrote: > Return statements in functions returning bool should use true or false > instead of an integer value. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/4] xen/blkfront: reorder tests in xlblk_init()
In case we don't want pv block devices we should not test parameters
for sanity and eventually print out error messages. So test precluding
conditions before checking parameters.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 19feb8835fc4..f72d96384326 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2718,6 +2718,15 @@ static int __init xlblk_init(void)
if (!xen_domain())
return -ENODEV;
+ if (!xen_has_pv_disk_devices())
+ return -ENODEV;
+
+ if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
+ pr_warn("xen_blk: can't get major %d with name %s\n",
+ XENVBD_MAJOR, DEV_NAME);
+ return -ENODEV;
+ }
+
if (xen_blkif_max_segments < BLKIF_MAX_SEGMENTS_PER_REQUEST)
xen_blkif_max_segments = BLKIF_MAX_SEGMENTS_PER_REQUEST;
@@ -2733,15 +2742,6 @@ static int __init xlblk_init(void)
xen_blkif_max_queues = nr_cpus;
}
- if (!xen_has_pv_disk_devices())
- return -ENODEV;
-
- if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
- printk(KERN_WARNING "xen_blk: can't get major %d with name
%s\n",
- XENVBD_MAJOR, DEV_NAME);
- return -ENODEV;
- }
-
INIT_DELAYED_WORK(&blkfront_work, blkfront_delay_work);
ret = xenbus_register_frontend(&blkfront_driver);
--
2.13.7
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/blkfront: remove unused macros
Remove some macros not used anywhere. Signed-off-by: Juergen Gross --- drivers/block/xen-blkfront.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index b5cedccb5d7d..94300dbe358b 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -251,14 +251,9 @@ static DEFINE_SPINLOCK(minor_lock); #define GRANTS_PER_INDIRECT_FRAME \ (XEN_PAGE_SIZE / sizeof(struct blkif_request_segment)) -#define PSEGS_PER_INDIRECT_FRAME \ - (GRANTS_INDIRECT_FRAME / GRANTS_PSEGS) - #define INDIRECT_GREFS(_grants)\ DIV_ROUND_UP(_grants, GRANTS_PER_INDIRECT_FRAME) -#define GREFS(_psegs) ((_psegs) * GRANTS_PER_PSEG) - static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo); static void blkfront_gather_backend_features(struct blkfront_info *info); static int negotiate_mq(struct blkfront_info *info); -- 2.13.7 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] libxl__build_hvm type confusion
On Mon, Aug 06, 2018 at 11:16:49AM +0200, Roger Pau Monné wrote: > On Sat, Aug 04, 2018 at 08:25:18PM +0200, Marek Marczykowski-Górecki wrote: > > Hi, > > > > libxl__domain_build calls libxl__build_hvm for both > > LIBXL_DOMAIN_TYPE_HVM and LIBXL_DOMAIN_TYPE_PVH, but libxl__build_hvm > > uses fields from b_info->u.hvm, which looks like invalid thing to do. > > Should those field be moved out of that union? > > Depends on the fields and whether they are relevant for PVH or not. > Either they are moved out of the HVM struct and shared between PVH and > HVM if they are relevant, or it's usage it's fully limited to domain > type HVM. In this particular case it is about: - u.hvm.mmio_hole_memkb - u.hvm.rdm_mem_boundary_memkb Not sure if those are relevant for PVH > I guess this mostly works because those HVM fields are not aliased to > any of the fields of the PVH struct and they are all 0 which happens > to be the correct value for PVH. Since u.pvh is very small, that's probably the case. > > Additionally I think some asserts in every function using b_info->u > > would be a good idea. > > Sure, I'm all in for adding more checks! > > Thanks, Roger. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: remove unused macros
On 06/08/18 13:34, Juergen Gross wrote: > Remove some macros not used anywhere. Meh, ignore that one, please. Doesn't belong to this series. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/4] xen/blkback: remove unused pers_gnts_lock from struct xen_blkif_ring
pers_gnts_lock isn't being used anywhere. Remove it.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkback/common.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index 26710602d463..4b7747159c38 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -279,7 +279,6 @@ struct xen_blkif_ring {
wait_queue_head_t pending_free_wq;
/* Tree to store persistent grants. */
- spinlock_t pers_gnts_lock;
struct rb_root persistent_gnts;
unsigned intpersistent_gnt_c;
atomic_tpersistent_gnt_in_use;
--
2.13.7
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/4] xen/blkback: don't keep persistent grants too long
Persistent grants are allocated until a threshold per ring is being
reached. Those grants won't be freed until the ring is being destroyed
meaning there will be resources kept busy which might no longer be
used.
Instead of freeing only persistent grants until the threshold is
reached add a timestamp and remove all persistent grants not having
been in use for a minute.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkback/blkback.c | 77 +++--
drivers/block/xen-blkback/common.h | 1 +
2 files changed, 50 insertions(+), 28 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index b55b245e8052..485e3ecab144 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -84,6 +84,18 @@ MODULE_PARM_DESC(max_persistent_grants,
"Maximum number of grants to map persistently");
/*
+ * How long a persistent grant is allowed to remain allocated without being in
+ * use. The time is in seconds, 0 means indefinitely long.
+ */
+
+unsigned int xen_blkif_pgrant_timeout = 60;
+module_param_named(persistent_grant_unused_seconds, xen_blkif_pgrant_timeout,
+ uint, 0644);
+MODULE_PARM_DESC(persistent_grant_unused_seconds,
+"Time in seconds an unused persistent grant is allowed to "
+"remain allocated. Default is 60, 0 means unlimited.");
+
+/*
* Maximum number of rings/queues blkback supports, allow as many queues as
there
* are CPUs if user has not specified a value.
*/
@@ -123,6 +135,13 @@ module_param(log_stats, int, 0644);
/* Number of free pages to remove on each call to gnttab_free_pages */
#define NUM_BATCH_FREE_PAGES 10
+static inline bool persistent_gnt_timeout(struct persistent_gnt
*persistent_gnt)
+{
+ return xen_blkif_pgrant_timeout &&
+ (jiffies - persistent_gnt->last_used >=
+ HZ * xen_blkif_pgrant_timeout);
+}
+
static inline int get_free_page(struct xen_blkif_ring *ring, struct page
**page)
{
unsigned long flags;
@@ -278,6 +297,7 @@ static void put_persistent_gnt(struct xen_blkif_ring *ring,
{
if(!test_bit(PERSISTENT_GNT_ACTIVE, persistent_gnt->flags))
pr_alert_ratelimited("freeing a grant already unused\n");
+ persistent_gnt->last_used = jiffies;
set_bit(PERSISTENT_GNT_WAS_ACTIVE, persistent_gnt->flags);
clear_bit(PERSISTENT_GNT_ACTIVE, persistent_gnt->flags);
atomic_dec(&ring->persistent_gnt_in_use);
@@ -374,23 +394,23 @@ static void purge_persistent_gnt(struct xen_blkif_ring
*ring)
bool scan_used = false, clean_used = false;
struct rb_root *root;
- if (ring->persistent_gnt_c < xen_blkif_max_pgrants ||
- (ring->persistent_gnt_c == xen_blkif_max_pgrants &&
- !ring->blkif->vbd.overflow_max_grants)) {
- goto out;
- }
-
if (work_busy(&ring->persistent_purge_work)) {
pr_alert_ratelimited("Scheduled work from previous purge is
still busy, cannot purge list\n");
goto out;
}
- num_clean = (xen_blkif_max_pgrants / 100) * LRU_PERCENT_CLEAN;
- num_clean = ring->persistent_gnt_c - xen_blkif_max_pgrants + num_clean;
- num_clean = min(ring->persistent_gnt_c, num_clean);
- if ((num_clean == 0) ||
- (num_clean > (ring->persistent_gnt_c -
atomic_read(&ring->persistent_gnt_in_use
- goto out;
+ if (ring->persistent_gnt_c < xen_blkif_max_pgrants ||
+ (ring->persistent_gnt_c == xen_blkif_max_pgrants &&
+ !ring->blkif->vbd.overflow_max_grants)) {
+ num_clean = 0;
+ } else {
+ num_clean = (xen_blkif_max_pgrants / 100) * LRU_PERCENT_CLEAN;
+ num_clean = ring->persistent_gnt_c - xen_blkif_max_pgrants +
+ num_clean;
+ num_clean = min(ring->persistent_gnt_c, num_clean);
+ pr_debug("Going to purge at least %u persistent grants\n",
+num_clean);
+ }
/*
* At this point, we can assure that there will be no calls
@@ -401,9 +421,7 @@ static void purge_persistent_gnt(struct xen_blkif_ring
*ring)
* number of grants.
*/
- total = num_clean;
-
- pr_debug("Going to purge %u persistent grants\n", num_clean);
+ total = 0;
BUG_ON(!list_empty(&ring->persistent_purge_list));
root = &ring->persistent_gnts;
@@ -419,39 +437,42 @@ static void purge_persistent_gnt(struct xen_blkif_ring
*ring)
if (test_bit(PERSISTENT_GNT_ACTIVE, persistent_gnt->flags))
continue;
- if (!scan_used &&
+ if (!scan_used && !persistent_gnt_timeout(persistent_gnt) &&
(test_bit(PERSISTENT_GNT_WAS_ACTIVE,
persistent_gnt->flags)))
continue;
+ if (scan_used && t
[Xen-devel] [PATCH 2/4] xen/blkfront: cleanup stale persistent grants
Add a periodic cleanup function to remove old persistent grants which
are no longer in use on the backend side. This avoids starvation in
case there are lots of persistent grants for a device which no longer
is involved in I/O business.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 99 ++--
1 file changed, 95 insertions(+), 4 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index b5cedccb5d7d..19feb8835fc4 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
@@ -121,6 +122,9 @@ static inline struct blkif_req *blkif_req(struct request
*rq)
static DEFINE_MUTEX(blkfront_mutex);
static const struct block_device_operations xlvbd_block_fops;
+static struct delayed_work blkfront_work;
+static LIST_HEAD(info_list);
+static bool blkfront_work_active;
/*
* Maximum number of segments in indirect requests, the actual value used by
@@ -216,6 +220,7 @@ struct blkfront_info
/* Save uncomplete reqs and bios for migration. */
struct list_head requests;
struct bio_list bio_list;
+ struct list_head info_list;
};
static unsigned int nr_minors;
@@ -1764,6 +1769,12 @@ static int write_per_ring_nodes(struct
xenbus_transaction xbt,
return err;
}
+static void free_info(struct blkfront_info *info)
+{
+ list_del(&info->info_list);
+ kfree(info);
+}
+
/* Common code used when first setting up, and when resuming. */
static int talk_to_blkback(struct xenbus_device *dev,
struct blkfront_info *info)
@@ -1885,7 +1896,10 @@ static int talk_to_blkback(struct xenbus_device *dev,
destroy_blkring:
blkif_free(info, 0);
- kfree(info);
+ mutex_lock(&blkfront_mutex);
+ free_info(info);
+ mutex_unlock(&blkfront_mutex);
+
dev_set_drvdata(&dev->dev, NULL);
return err;
@@ -1996,6 +2010,10 @@ static int blkfront_probe(struct xenbus_device *dev,
info->handle = simple_strtoul(strrchr(dev->nodename, '/')+1, NULL, 0);
dev_set_drvdata(&dev->dev, info);
+ mutex_lock(&blkfront_mutex);
+ list_add(&info->info_list, &info_list);
+ mutex_unlock(&blkfront_mutex);
+
return 0;
}
@@ -2306,6 +2324,15 @@ static void blkfront_gather_backend_features(struct
blkfront_info *info)
if (indirect_segments <= BLKIF_MAX_SEGMENTS_PER_REQUEST)
indirect_segments = 0;
info->max_indirect_segments = indirect_segments;
+
+ if (info->feature_persistent) {
+ mutex_lock(&blkfront_mutex);
+ if (!blkfront_work_active) {
+ blkfront_work_active = true;
+ schedule_delayed_work(&blkfront_work, HZ * 10);
+ }
+ mutex_unlock(&blkfront_mutex);
+ }
}
/*
@@ -2487,7 +2514,9 @@ static int blkfront_remove(struct xenbus_device *xbdev)
mutex_unlock(&info->mutex);
if (!bdev) {
- kfree(info);
+ mutex_lock(&blkfront_mutex);
+ free_info(info);
+ mutex_unlock(&blkfront_mutex);
return 0;
}
@@ -2507,7 +2536,9 @@ static int blkfront_remove(struct xenbus_device *xbdev)
if (info && !bdev->bd_openers) {
xlvbd_release_gendisk(info);
disk->private_data = NULL;
- kfree(info);
+ mutex_lock(&blkfront_mutex);
+ free_info(info);
+ mutex_unlock(&blkfront_mutex);
}
mutex_unlock(&bdev->bd_mutex);
@@ -2590,7 +2621,7 @@ static void blkif_release(struct gendisk *disk, fmode_t
mode)
dev_info(disk_to_dev(bdev->bd_disk), "releasing disk\n");
xlvbd_release_gendisk(info);
disk->private_data = NULL;
- kfree(info);
+ free_info(info);
}
out:
@@ -2623,6 +2654,62 @@ static struct xenbus_driver blkfront_driver = {
.is_ready = blkfront_is_ready,
};
+static void purge_persistent_grants(struct blkfront_info *info)
+{
+ unsigned int i;
+ unsigned long flags;
+
+ for (i = 0; i < info->nr_rings; i++) {
+ struct blkfront_ring_info *rinfo = &info->rinfo[i];
+ struct grant *gnt_list_entry, *tmp;
+
+ spin_lock_irqsave(&rinfo->ring_lock, flags);
+
+ if (rinfo->persistent_gnts_c == 0) {
+ spin_unlock_irqrestore(&rinfo->ring_lock, flags);
+ continue;
+ }
+
+ list_for_each_entry_safe(gnt_list_entry, tmp, &rinfo->grants,
+node) {
+ if (gnt_list_entry->gref == GRANT_INVALID_REF ||
+ gnttab_query_foreign_access(gnt_list_entry->gref))
+ continue;
[Xen-devel] [freebsd-master test] 125762: regressions - trouble: blocked/fail
flight 125762 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125762/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317 Tests which did not succeed, but are not blocking: build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd a0332168f8b425b40d9f2a873caf608b1c57c175 baseline version: freebsd bf65d05707104df94117a293327d797d71a0118d Last test of basis 125317 2018-07-18 09:19:47 Z 19 days Failing since125467 2018-07-20 09:19:59 Z 17 days8 attempts Testing same since 125762 2018-08-06 09:18:36 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> alc allanjude andrew antoine araujo asomers avg bapt bde bdrewery br brd bwidawsk bz cem cperciva cy dab daichi davidcs delphij dim eadler emaste eugen ganbold gavin gjb glebius hselasky ian imp jhb jhibbits jhixson kevans kib kp leitao luporl lwhsu manu marius markj Matthew Ahrens mav mm mmacy mmel np obrien oshogbo pfg pkelsey pstef rmacklem royger rpokala rrs sef shurd sjg trasz truckman tsoome tuexen uqs will woodsb02 wulf zleslie jobs: build-amd64-freebsd-againblocked build-amd64-freebsd fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7476 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/4] xen/blk: persistent grant rework
Persistent grants are used in the Xen's blkfront/blkback drivers to avoid mapping/unmapping of I/O buffers in the backend for each I/O. While this speeds up processing quite a bit there are problems related to persistent grants in some configurations: domains with multiple block devices making use of persistent grants might suffer from a lack of grants if each of the block devices experienced a high I/O load at some time. This is due to the number of persistent grants per device only to be limited by a rather high maximum value, but never being released even in case of longer times without any I/O. This series modifies xen-blkback to unmap any domU page mapped via a persistent grant after a timeout (default: 60 seconds). The timeout is set to its default value again when a persistent grant has been used for an I/O. xen-blkfront is modified to scan every 10 seconds for persistent grants not in use by blkback any more and to remove such grants. The last 2 patches are small cleanups of blkfront and blkback drivers. Juergen Gross (4): xen/blkback: don't keep persistent grants too long xen/blkfront: cleanup stale persistent grants xen/blkfront: reorder tests in xlblk_init() xen/blkback: remove unused pers_gnts_lock from struct xen_blkif_ring drivers/block/xen-blkback/blkback.c | 77 +++- drivers/block/xen-blkback/common.h | 2 +- drivers/block/xen-blkfront.c| 115 3 files changed, 153 insertions(+), 41 deletions(-) -- 2.13.7 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle messages from QEMU
On Fri, Aug 03, 2018 at 06:25:00PM +0100, Anthony PERARD wrote:
> On Thu, Aug 02, 2018 at 01:17:37PM +0200, Roger Pau Monné wrote:
> > On Fri, Jul 27, 2018 at 03:06:04PM +0100, Anthony PERARD wrote:
> > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > > index 4a385801ba..e104fea941 100644
> > > --- a/tools/libxl/libxl_types.idl
> > > +++ b/tools/libxl/libxl_types.idl
> > > @@ -69,6 +69,10 @@ libxl_error = Enumeration("error", [
> > > (-23, "NOTFOUND"),
> > > (-24, "DOMAIN_DESTROYED"), # Target domain ceased to exist during op
> > > (-25, "FEATURE_REMOVED"), # For functionality that has been removed
> > > +(-26, "QMP_GENERIC_ERROR"), # unspecified qmp error
> > > +(-27, "QMP_COMMAND_NOT_FOUND"), # the requested command has not been
> > > found
> > > +(-28, "QMP_DEVICE_NOT_ACTIVE"), # a device has failed to be become
> > > active
> > > +(-29, "QMP_DEVICE_NOT_FOUND"), # the requested device has not been
> > > found
> >
> > Do we really need such granularity for QMP errors? Isn't it enough to
> > have a single ERROR_QMP or similar?
>
> No I don't think so. QMP_COMMAND_NOT_FOUND can be useful when a qmp
> command is removed (there is already one that is deprecated and we use).
>
> The last two could be useful to user of libxl as they could provide
> better error messages. xl don't care because whatever error message is
> attach to the error, it will be printed.
I wonder if this set of errors will change very often, at the end of
day it's not controlled by ourselves but QEMU, and then how much
chasing will libxl have to do in order to keep up with new types of
QMP errors.
IMO I don't see a lot of value in returning specific QMP error codes
from libxl, and I would even consider whether it's worth to have
something like ERROR_QMP, because I don't think there's much the
caller can do in case of QMP failure. It's an internal libxl QMP
error, and it's not like the caller is going to start it's own QMP
connection in order to speak with QEMU directly in order to solve
whatever QMP issue it got from libxl.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 17/32] libxl_qmp: Parse JSON input from QMP
On Fri, Aug 03, 2018 at 04:33:31PM +0100, Anthony PERARD wrote:
> On Thu, Aug 02, 2018 at 12:25:53PM +0200, Roger Pau Monné wrote:
> > On Fri, Jul 27, 2018 at 03:05:59PM +0100, Anthony PERARD wrote:
> > > +/* workaround strstr limitation */
> > > +ev->rx_buf[ev->buf_used] = '\0';
> >
> > Why not use strnstr to limit the size of the rx_buf that's searched? I
> > think that would allow you to get rid of the '-1' that you have to
> > take into account in several places?
>
> Because that's a FreeBSD API, at least on my machine (Arch Linux), to
> attempt to use it, I will need to install a new package, libbsd. So I
> don't think strnstr was an option.
Oh, that's a shame. It would make the code easier IMO.
> > > +
> > > +/*
> > > + * Search for the end of a QMP message: "\r\n" in the newly received
> > > + * bytes + the last byte on the previous read() if any
> > > + *
> > > + * end: This will point to the byte right after \r\n
> > > + */
> > > +end = strstr(ev->rx_buf + ev->buf_used - r
> > > + + (ev->buf_used - r == 0 ? 0 : -1),
> > > + "\r\n");
> > > +if (end)
> > > +end += 2;
> > > +
> > > +while (end) {
> > > +libxl__json_object *o;
> > > +size_t len;
> > > +char *s;
> > > +
> > > +/* Start parsing from s */
> > > +s = ev->rx_buf + ev->buf_consumed;
> > > +/* Findout how much can be parsed */
> > > +len = end - s;
> >
> > You can init both s and len above when defining them.
>
> Would not that looks a bit weird?
>
> +while (end) {
> +libxl__json_object *o;
> +/* Start parsing from s */
> +char *s = ev->rx_buf + ev->buf_consumed;
> +/* Findout how much can be parsed */
> +size_t len = end - s;
>
> But that can be done.
I have a tendency to try to init as much as possible at definition
time in order to make the code shorter, but that's my preference.
There's no rule in coding style that mandates that AFAIK.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125761: regressions - FAIL
flight 125761 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125761/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 6 kernel-build fail REGR. vs. 125758 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d3bc33731f5b039bf3df76e50cbb1f60ce697e9b baseline version: ovmf cd3a42640acdb4f5ac14ac19f22ede002124920c Last test of basis 125758 2018-08-06 04:40:40 Z0 days Testing same since 125759 2018-08-06 06:40:39 Z0 days2 attempts People who touched revisions under test: Dandan Bi jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit d3bc33731f5b039bf3df76e50cbb1f60ce697e9b Author: Dandan Bi Date: Tue Jul 17 10:14:04 2018 +0800 MdeModulePkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. Now the DxeSmmPerformanceLib is not used by any module. So remove it from edk2 code base to avoid being used by mistake. Cc: Liming Gao Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Liming Gao commit 29890da47d18c602c199819b78ae15c08e22cab0 Author: Dandan Bi Date: Tue Jul 17 10:10:49 2018 +0800 ShellPkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: Jaben Carsey Cc: Ruiyu Ni Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Jaben Carsey commit 18219ab369277151d908a4b6a75a8e371c810c3d Author: Dandan Bi Date: Tue Jul 17 10:10:15 2018 +0800 Vlv2TbltDevicePkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: David Wei Cc: Mang Guo Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: David Wei commit 5b292858ba9aa2a7c9fc7e4f99df8fe750399f80 Author: Dandan Bi Date: Tue Jul 17 10:06:34 2018 +0800 QuarkPlatformPkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: Michael D Kinney Cc: Kelly Steele Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Liming Gao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools/kdd: work around gcc 8.1 bug
Gcc 8.1 has a bug that causes kdd fail to build. Rewrite the code to
work around that bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86827
Signed-off-by: Tim Deegan
Signed-off-by: Wei Liu
Tested-by: Wei Liu
---
tools/debugger/kdd/kdd.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
index 5a019a0..fb8c645 100644
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -687,11 +687,10 @@ static void kdd_handle_read_ctrl(kdd_state *s)
}
} else {
/* 32-bit control-register space starts at 0x[2]cc, for 84 bytes */
-uint32_t offset = addr;
-if (offset > 0x200)
-offset -= 0x200;
-offset -= 0xcc;
-if (offset > sizeof ctrl.c32 || offset + len > sizeof ctrl.c32) {
+uint32_t offset = addr - 0xcc;
+if (offset > sizeof ctrl.c32)
+offset -= 0x2cc;
+if (offset > sizeof ctrl.c32 || len > sizeof ctrl.c32 - offset) {
KDD_LOG(s, "Request outside of known control space\n");
len = 0;
} else {
base-commit: e752f28409678ce3ade49986b39309178fb2a6d6
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-sid test] 75048: tolerable FAIL
flight 75048 distros-debian-sid real [real] http://osstest.xensource.com/osstest/logs/75048/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 75026 test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install fail like 75026 test-amd64-i386-amd64-sid-netboot-pygrub 10 debian-di-install fail like 75026 test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 75026 test-amd64-amd64-amd64-sid-netboot-pvgrub 10 debian-di-install fail like 75026 baseline version: flight 75026 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub fail test-amd64-i386-amd64-sid-netboot-pygrub fail test-armhf-armhf-armhf-sid-netboot-pygrubfail test-amd64-amd64-i386-sid-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-blkfront: use true and false for boolean values
On Sat, Aug 04, 2018 at 07:08:59PM -0500, Gustavo A. R. Silva wrote: > Return statements in functions returning bool should use true or false > instead of an integer value. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Acked-by: Roger Pau Monné Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] libxl__build_hvm type confusion
On Sat, Aug 04, 2018 at 08:25:18PM +0200, Marek Marczykowski-Górecki wrote: > Hi, > > libxl__domain_build calls libxl__build_hvm for both > LIBXL_DOMAIN_TYPE_HVM and LIBXL_DOMAIN_TYPE_PVH, but libxl__build_hvm > uses fields from b_info->u.hvm, which looks like invalid thing to do. > Should those field be moved out of that union? Depends on the fields and whether they are relevant for PVH or not. Either they are moved out of the HVM struct and shared between PVH and HVM if they are relevant, or it's usage it's fully limited to domain type HVM. I guess this mostly works because those HVM fields are not aliased to any of the fields of the PVH struct and they are all 0 which happens to be the correct value for PVH. > Additionally I think some asserts in every function using b_info->u > would be a good idea. Sure, I'm all in for adding more checks! Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu option
On Mon, Aug 06, 2018 at 08:51:55AM +0100, Paul Durrant wrote: > > -Original Message- > > From: Tian, Kevin [mailto:kevin.t...@intel.com] > > Sent: 06 August 2018 04:19 > > To: Roger Pau Monne ; Paul Durrant > > > > Cc: Jan Beulich ; Stefano Stabellini > > ; Wei Liu ; George Dunlap > > ; Andrew Cooper > > ; Ian Jackson ; Tim > > (Xen.org) ; Julien Grall ; Suravee > > Suthikulpanit ; xen-devel > de...@lists.xenproject.org>; Brian Woods > > Subject: RE: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu > > option > > > > > From: Roger Pau Monné [mailto:roger@citrix.com] > > > Sent: Friday, August 3, 2018 5:33 PM > > > > > > On Fri, Aug 03, 2018 at 10:14:49AM +0100, Paul Durrant wrote: > > > > > -Original Message- > > > > > From: Roger Pau Monne > > > > > Sent: 03 August 2018 10:09 > > > > > To: Paul Durrant > > > > > Cc: Jan Beulich ; Kevin Tian > > > ; > > > > > Stefano Stabellini ; Wei Liu > > > ; > > > > > George Dunlap ; Andrew Cooper > > > > > ; Ian Jackson ; > > > Tim > > > > > (Xen.org) ; Julien Grall ; Suravee > > > > > Suthikulpanit ; xen-devel > > > > de...@lists.xenproject.org>; Brian Woods > > > > > Subject: Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0- > > iommu > > > > > option > > > > > > > > > > On Fri, Aug 03, 2018 at 10:05:19AM +0100, Paul Durrant wrote: > > > > > > Actually I wonder whether we should rename 'inclusive' to > > > > > > 'reserved'. > > > > > Essentially 'none', 'strict' or 'relaxed' are all about mappings of > > > > > RAM, > > > and then > > > > > we need to decide whether to map the E820 reserved regions. So I > > think > > > the > > > > > inclusive map as it stands today is equivalent to 'relaxed' + > > > > > 'reserved'. > > > > > > > > > > Hm, not exactly. inclusive (iommu_inclusive_mapping) right now maps > > > > > everything except unusable regions. That's way more than just > > mapping > > > > > reserved regions. If we want to keep this behaviour while introducing > > > > > an option to map only reserved regions we need both an inclusive and a > > > > > reserved option. > > > > > > > > > > > > > Ok, how about: > > > > > > > > inclusive -> all E820 ranges except unusable or ram > > > > > > inclusive ATM also maps holes. So it would be all memory ranges except > > > those marked as unusable or in use by Xen. > > > > > > > reserved -> all E820 reserved ranges > > > > > > > > then > > > > > > > > strict -> all ram ranges belonging to dom0 > > > > relaxed -> all ram ranges > > > > none -> no ram ranges > > > > > > > > The problem then is what does, say, reserved + no-inclusive mean? I > > > guess we could have a flag for each non ram E820 range type? > > > > > > reserved + no-inclusive would make sense for a PV Dom0 running on > > > Intel hardware in order to map only the reserved regions instead of > > > mapping almost everything below 4GB by default. > > > > > > What about the following description of the options, do you think it's > > > clear enough? > > > > > > > `= List of [ none | strict | relaxed | inclusive | reserved ]` > > > > > > * `none`: disables DMA remapping for Dom0. > > > > > > The following two options control how RAM regions are mapped in the > > > iommu for > > > Dom0: > > > > > > * `strict`: sets up DMA remapping only for the memory Dom0 actually got > > > assigned. > > > > > > * `relaxed`: sets DMA remapping for all the host RAM except regions in use > > > by > > > Xen. This is the default iommu behaviour. > > > > > > Note that all the above options are mutually exclusive. Specifying more > > > than > > > one on the `dom0-iommu` command line will result in undefined behavior. > > > > > > The following options control whether non-RAM regions are added to the > > > Dom0 > > > iommu tables. Note that they can be prefixed with `no-` to effect the > > > inverse > > > meaning: > > > > > > * `inclusive`: sets up DMA remapping for all the non-RAM memory below > > > 4GB > > > except for unusable ranges. Use this to work around firmware issues > > > providing > > > incorrect RMRR/IVMD entries. Rather than only mapping RAM pages for > > > IOMMU > > > accesses for Dom0, with this option all pages up to 4GB, not marked as > > > unusable in the E820 table, will get a mapping established. Note that > > > this > > > option is only applicable to a PV Dom0 and is enabled by default on > > > Intel > > > hardware. > > > > > > * `reserved`: sets up DMA remapping for all the reserved regions in the > > > memory > > > map for Dom0. Use this to work around firmware issues providing > > > incorrect > > > RMRR or IVMD entries. Rather than only mapping RAM pages for IOMMU > > > accesses > > > for Dom0, all memory regions marked as reserved in the memory map > > > that don't > > > overlap with any MMIO region from emulated devices will be identity > > > mapped. > > > This option maps a subset of the memory that would be mapped when > > > using the > > > `inclusive` option. This option is available to a PVH Dom
[Xen-devel] [ovmf baseline-only test] 75049: tolerable FAIL
This run is configured for baseline tests only. flight 75049 ovmf real [real] http://osstest.xensource.com/osstest/logs/75049/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75047 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75047 version targeted for testing: ovmf cd3a42640acdb4f5ac14ac19f22ede002124920c baseline version: ovmf 81038d50c9c9bbe5756d6ba172d692d0c7b58a62 Last test of basis75047 2018-08-06 04:22:31 Z0 days Testing same since75049 2018-08-06 06:53:29 Z0 days1 attempts People who touched revisions under test: Kinney, Michael D Michael D Kinney jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit cd3a42640acdb4f5ac14ac19f22ede002124920c Author: Kinney, Michael D Date: Sat Aug 4 04:47:33 2018 +0800 BaseTools/BinToPcd: Open output file as text file https://bugzilla.tianocore.org/show_bug.cgi?id=1069 Undo changes from following commit: https://github.com/tianocore/edk2/commit/83964ebc5e74549d6efc7134af19150a0b2079aa Change the open mode for the output file from 'wb' to 'w' so the output file is written as a text file and not a binary file. This resolves the issue where the text file was not writable from Python 3.x and also removes b'' from output file when the string was encoded as a bytearray. Cc: YanYan Sun Cc: Yonghong Zhu Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Tested-by:YanYan Sun Reviewed-by: Yonghong Zhu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125759: regressions - FAIL
flight 125759 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125759/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 6 kernel-build fail REGR. vs. 125758 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf d3bc33731f5b039bf3df76e50cbb1f60ce697e9b baseline version: ovmf cd3a42640acdb4f5ac14ac19f22ede002124920c Last test of basis 125758 2018-08-06 04:40:40 Z0 days Testing same since 125759 2018-08-06 06:40:39 Z0 days1 attempts People who touched revisions under test: Dandan Bi jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit d3bc33731f5b039bf3df76e50cbb1f60ce697e9b Author: Dandan Bi Date: Tue Jul 17 10:14:04 2018 +0800 MdeModulePkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. Now the DxeSmmPerformanceLib is not used by any module. So remove it from edk2 code base to avoid being used by mistake. Cc: Liming Gao Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Liming Gao commit 29890da47d18c602c199819b78ae15c08e22cab0 Author: Dandan Bi Date: Tue Jul 17 10:10:49 2018 +0800 ShellPkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: Jaben Carsey Cc: Ruiyu Ni Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Jaben Carsey commit 18219ab369277151d908a4b6a75a8e371c810c3d Author: Dandan Bi Date: Tue Jul 17 10:10:15 2018 +0800 Vlv2TbltDevicePkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: David Wei Cc: Mang Guo Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: David Wei commit 5b292858ba9aa2a7c9fc7e4f99df8fe750399f80 Author: Dandan Bi Date: Tue Jul 17 10:06:34 2018 +0800 QuarkPlatformPkg: Remove DxeSmmPerformanceLib DxeSmmPerformanceLib previously is used by DP tool. But in new pweformance infrastructure, we have updated Dp tool to get the performance data from firmware performance data table in ACPI. So remove the usage of DxeSmmPerformanceLib here. Cc: Michael D Kinney Cc: Kelly Steele Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Liming Gao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu option
> -Original Message- > From: Tian, Kevin [mailto:kevin.t...@intel.com] > Sent: 06 August 2018 04:19 > To: Roger Pau Monne ; Paul Durrant > > Cc: Jan Beulich ; Stefano Stabellini > ; Wei Liu ; George Dunlap > ; Andrew Cooper > ; Ian Jackson ; Tim > (Xen.org) ; Julien Grall ; Suravee > Suthikulpanit ; xen-devel de...@lists.xenproject.org>; Brian Woods > Subject: RE: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu > option > > > From: Roger Pau Monné [mailto:roger@citrix.com] > > Sent: Friday, August 3, 2018 5:33 PM > > > > On Fri, Aug 03, 2018 at 10:14:49AM +0100, Paul Durrant wrote: > > > > -Original Message- > > > > From: Roger Pau Monne > > > > Sent: 03 August 2018 10:09 > > > > To: Paul Durrant > > > > Cc: Jan Beulich ; Kevin Tian > > ; > > > > Stefano Stabellini ; Wei Liu > > ; > > > > George Dunlap ; Andrew Cooper > > > > ; Ian Jackson ; > > Tim > > > > (Xen.org) ; Julien Grall ; Suravee > > > > Suthikulpanit ; xen-devel > > > de...@lists.xenproject.org>; Brian Woods > > > > Subject: Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0- > iommu > > > > option > > > > > > > > On Fri, Aug 03, 2018 at 10:05:19AM +0100, Paul Durrant wrote: > > > > > Actually I wonder whether we should rename 'inclusive' to 'reserved'. > > > > Essentially 'none', 'strict' or 'relaxed' are all about mappings of RAM, > > and then > > > > we need to decide whether to map the E820 reserved regions. So I > think > > the > > > > inclusive map as it stands today is equivalent to 'relaxed' + > > > > 'reserved'. > > > > > > > > Hm, not exactly. inclusive (iommu_inclusive_mapping) right now maps > > > > everything except unusable regions. That's way more than just > mapping > > > > reserved regions. If we want to keep this behaviour while introducing > > > > an option to map only reserved regions we need both an inclusive and a > > > > reserved option. > > > > > > > > > > Ok, how about: > > > > > > inclusive -> all E820 ranges except unusable or ram > > > > inclusive ATM also maps holes. So it would be all memory ranges except > > those marked as unusable or in use by Xen. > > > > > reserved -> all E820 reserved ranges > > > > > > then > > > > > > strict -> all ram ranges belonging to dom0 > > > relaxed -> all ram ranges > > > none -> no ram ranges > > > > > > The problem then is what does, say, reserved + no-inclusive mean? I > > guess we could have a flag for each non ram E820 range type? > > > > reserved + no-inclusive would make sense for a PV Dom0 running on > > Intel hardware in order to map only the reserved regions instead of > > mapping almost everything below 4GB by default. > > > > What about the following description of the options, do you think it's > > clear enough? > > > > > `= List of [ none | strict | relaxed | inclusive | reserved ]` > > > > * `none`: disables DMA remapping for Dom0. > > > > The following two options control how RAM regions are mapped in the > > iommu for > > Dom0: > > > > * `strict`: sets up DMA remapping only for the memory Dom0 actually got > > assigned. > > > > * `relaxed`: sets DMA remapping for all the host RAM except regions in use > > by > > Xen. This is the default iommu behaviour. > > > > Note that all the above options are mutually exclusive. Specifying more > > than > > one on the `dom0-iommu` command line will result in undefined behavior. > > > > The following options control whether non-RAM regions are added to the > > Dom0 > > iommu tables. Note that they can be prefixed with `no-` to effect the > > inverse > > meaning: > > > > * `inclusive`: sets up DMA remapping for all the non-RAM memory below > > 4GB > > except for unusable ranges. Use this to work around firmware issues > > providing > > incorrect RMRR/IVMD entries. Rather than only mapping RAM pages for > > IOMMU > > accesses for Dom0, with this option all pages up to 4GB, not marked as > > unusable in the E820 table, will get a mapping established. Note that this > > option is only applicable to a PV Dom0 and is enabled by default on Intel > > hardware. > > > > * `reserved`: sets up DMA remapping for all the reserved regions in the > > memory > > map for Dom0. Use this to work around firmware issues providing > > incorrect > > RMRR or IVMD entries. Rather than only mapping RAM pages for IOMMU > > accesses > > for Dom0, all memory regions marked as reserved in the memory map > > that don't > > overlap with any MMIO region from emulated devices will be identity > > mapped. > > This option maps a subset of the memory that would be mapped when > > using the > > `inclusive` option. This option is available to a PVH Dom0 and is enabled > > by > > default on Intel hardware. > > > > above makes it clear now. Just a side question. Is there also value of > applying > 'reserved' option to PV Dom0? Absolutely. I don't think the text implies it's not available for PV dom0, just that (unlike 'inclusive') it is also available to PVH dom0. Paul > > Thanks, > Kevin
