* Re: [Qemu-devel] [PATCH] nbd: Don't inf-loop on early EOF
From: Paolo Bonzini @ 2016-11-09 13:05 UTC (permalink / raw)
To: Eric Blake, Max Reitz, qemu-devel; +Cc: qemu-block
In-Reply-To: <5e7c4a2a-d2d4-7174-471a-d0a5232d2023@redhat.com>
On 07/11/2016 23:45, Eric Blake wrote:
> On 11/07/2016 04:22 PM, Max Reitz wrote:
>> On 07.11.2016 21:38, Eric Blake wrote:
>>> Commit 7d3123e converted a single read_sync() into a while loop
>>> that assumed that read_sync() would either make progress or give
>>> an error. But when the server hangs up early, the client sees
>>> EOF (a read_sync() of 0) and never makes progress, which in turn
>>> caused qemu-iotest './check -nbd 83' to go into an infinite loop.
>>>
>>> Rework the loop to accomodate reads cut short by EOF.
>>>
>>> Reported-by: Max Reitz <mreitz@redhat.com>
>>> Signed-off-by: Eric Blake <eblake@redhat.com>
>>> ---
>>> nbd/client.c | 13 +++++++------
>>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> Reviewed-by: Max Reitz <mreitz@redhat.com>
>>
>> But what about the server's nbd_negotiate_drop_sync()? It uses pretty
>> much the same code, so it seems susceptible to the same issue (only that
>> we don't have a test for that side).
>
> If so, that's an older bug (pre-existing back to at least 2.6?), so it
> should be a separate fix, if anything.
>
> I guess it's time to figure out how to test the server against
> ill-behaved clients...
Using afl perhaps?
Paolo
^ permalink raw reply
* Re: btrfs scrub with unexpected results
From: Austin S. Hemmelgarn @ 2016-11-09 13:04 UTC (permalink / raw)
To: Tom Arild Naess, linux-btrfs
In-Reply-To: <e3827c98-3817-81d4-e77b-e2daf00bb3c8@gmail.com>
On 2016-11-09 07:40, Tom Arild Naess wrote:
> Thanks for your lengthy answer. Just after posting my question I
> realized that the last reboot I did resulted in the filesystem being
> mounted RO. I started a "btrfs check --repair" but terminated it after
> six days, since I really need to get the backup up and running again. I
> have decided to start with a fresh btrfs to rule out any errors created
> by old kernels.
Even with other filesystems, doing this on occasion is generally a good
idea. It goes double for BTRFS though, I'd say right now every year or
so you should be re-creating the filesystem if your using BTRFS.
>
> I find it unlikely that my problems are caused by any hardware faults,
> as the server has been running 24/7 for six months with nightly backups
> every day without any problems. Also the system has been scrubbed once a
> month without issues in the same timespan. Every time there have been
> scrubbing errors, these have all occurred in the the same old snapshots
> that I created from my hard link backups. These were the first snapshots
> I ever took, and back then I ran a quite old kernel.
Just to clarify, most of the reason I'm thinking it's a hardware issue
is that a reboot fixed things. In most cases I've seen, that generally
means you either have hardware problems (even failing hardware usually
works correctly for a little while after being power cycled), or that
you got hit with a memory error somewhere (not everything has ECC memory
on a server system, the on-device caches on most disks and some storage
controllers often don't for example). It could just as easily be the
result of a bug somewhere as well, but I usually tend to blame the
hardware first because I find that it's a lot easier to debug most of
the time (I might also be a bit biased because BTRFS has helped me ID a
whole lot of marginal hardware in the past 2 years).
>
> If a fresh btrfs does not solve my problems, I will go through the list
> you provided. Some have already been handled earlier, like memtest (did
> a long run before the system was put into service). I am also running
> smartctl as a service, and nothing is reported there either.
>
> One last thing: The CPU on the server is a really low end AMD C-70, and
> I wonder if it's a little too weak for a storage server? Not in the day
> to day, but when a repair is needed. Seems like more than six days for a
> repair on 4x 3TB system is way too long?
For something like a storage server, what you really want to look at is
memory bandwidth, as that tends to directly impact pretty much
everything the system is supposed to be doing. In your case, the
limiting factor probably is the CPU, as a C-70 runs at 1GHz and only
supports up to DDR3-1066 RAM. This works fine for just serving files of
course, but it gets problematic when you have to move lots of data
around or process a filesystem for repairs. As a general rule for a
file-server, I wouldn't use anything running at less than 2GHz with at
least 2 (preferably 4) cores which supports at minimum DDR3-1333
(preferably DDR3-1600) RAM.
In fact, with some very specific exceptions, memory bandwidth is
actually one of the most important metrics for almost any computer
(provided the CPU isn't running slower than the RAM or limiting it's max
operation speed, I'd upgrade RAM before upgrading the CPU most of the
time for most systems).
>
>
> --
> Tom Arild Naess
>
> On 03. nov. 2016 12:51, Austin S. Hemmelgarn wrote:
>> On 2016-11-02 17:55, Tom Arild Naess wrote:
>>> Hello,
>>>
>>> I have been running btrfs on a file server and backup server for a
>>> couple of years now, both set up as RAID 10. The file server has been
>>> running along without any problems since day one. My problems has been
>>> with the backup server.
>>>
>>> A little background about the backup server before I dive into the
>>> problems. The server was a new build that was set to replace an aging
>>> machine, and my intention was to start using btrfs send/receive instead
>>> of hard links for the backups. Since I had 8x the space on the new
>>> server, I just rsynced the whole lot of old backups to the new server. I
>>> then made some scripts that created snapshots from the old file
>>> hierarchy. As I started rewriting my backup scripts (on file server and
>>> backup server) to use send/receive, I also tested scrubbing to see that
>>> everything was OK. After doing this a few times, scrub found
>>> unrecoverable files. This, I thought, should not be possible on new
>>> disks. I tried to get some help on this list, but no answers were found,
>>> and since I was unable to find what triggered this, I just stopped using
>>> send/receive, and let my old backup regime live on on this new backup
>>> server as well. I don't remember how I fixed the errors, but I guess I
>>> just replaced the offending files with fresh ones, and scrub ran without
>>> any more problems. I decided to let things just run like this, and set
>>> up scrubbing on a monthly schedule.
>>>
>>> Last night I got the unpleasant mail from cron telling me that scrub had
>>> failed (for the first time in over a year). Since I was running on an
>>> older kernel (4.2.x), I decided to upgrade, and went for the latest of
>>> the longterm branches, namely 4.4.30. After rebooting I did (for
>>> whatever reason) check one of the offending files, and I could read the
>>> file just fine! I checked the rest of the bunch, and all files read
>>> fine, and had the same md5 sum as the originals! All these files were
>>> located in those old snapshots. I thought that maybe this was because of
>>> a bug resolved since my last kernel. Then I ran a new scrub, and this
>>> one also reported unrecoverable errors. This time on two other files but
>>> also in some of the old snapshots. I tried reading the files, and got
>>> the expected I/O errors. One reboot later, these files reads just fine
>>> again!
>> So, based on what your saying, this sounds like you have hardware
>> problems. The fact that a reboot is fixing I/O errors caused by
>> checksum mismatches tells me that either (in relative order of
>> likelihood):
>> 1. You have some bad RAM (probably not much given the small number of
>> errors).
>> 2. You have some bad hardware in the storage path other than the
>> physical media in your storage devices. Any of the storage
>> controller, the cabling/back-plane, or the on-disk cache having issues
>> can cause things like this to happen.
>> 3. Some other component is having issues. A PSU that's not providing
>> clean power could cause this also, but is not likely unless you've got
>> a really cheap PSU.
>> 4. You've found an odd corner case in BTRFS that nobody's reported
>> before (this is pretty much certain if you rule out the hardware).
>>
>> Based on this, what I would suggest doing (in order):
>> 1. Run self-tests on the storage devices using smartctl (and see if
>> they think they're healthy or not). I doubt that this will show
>> anything, but it's quick and easy to test and doesn't require taking
>> the system off-line, so it's one of the first things to check.
>> 2. Check your cabling. This is really easy to verify, just disconnect
>> and reconnect everything and see if you still have problems. If you
>> do still have problems, try switching out one data (SATA/SAS/whatever
>> you use) cable at a time and see if you still have problems (it takes
>> longer than using a cable tester, but finding a working cable tester
>> for internal computer cables is hard).
>> 3. Check your RAM. Memtest86 and Memtest86+ are the best options for
>> general testing, but I doubt that those will turn up anything. If you
>> have spare RAM, I'd actually suggest just swapping out one DIMM at a
>> time and seeing if you still get the behavior your seeing.
>> 4. Check your PSU. I list this before the storage controller and
>> disks because it's pretty easy to test (you just need a PSU tester,
>> which are about 15 USD on Amazon, or a good multi-meter, some wire,
>> and some basic knowledge of the wiring), but after the RAM because
>> it's significantly less likely to be the problem than your RAM unless
>> you've got a really cheap PSU.
>> 5. Check your storage controller. This is _hard_ to do unless you
>> have a spare known working storage controller.
>> 6. If you have any extra expansion cards your not using (NIC's, HBA's,
>> etc), try pulling them out. This sounds odd, but I've seen cases
>> where the driver for something I wasn't using at all was causing
>> problems elsewhere.
>>
>> Now, assuming none of that turns anything up, then you probably have
>> found a bug in BTRFS, but I have no idea in this case how we would go
>> about debugging it as it seems to be some kind of in-memory data
>> corruption (maybe a buffer overflow?).
>>
>>>
>>> Some system info:
>>>
>>> $ uname -a
>>> Linux backup 4.4.30-1-lts #1 SMP Tue Nov 1 22:09:20 CET 2016 x86_64
>>> GNU/Linux
>>>
>>> $ btrfs --version
>>> btrfs-progs v4.8.2
>>>
>>> $ btrfs fi show /backup
>>> Label: none uuid: 8825ce78-d620-48f5-9f03-8c4568d3719d
>>> Total devices 4 FS bytes used 2.81TiB
>>> devid 1 size 2.73TiB used 1.41TiB path /dev/sdb
>>> devid 2 size 2.73TiB used 1.41TiB path /dev/sda
>>> devid 3 size 2.73TiB used 1.41TiB path /dev/sdd
>>> devid 4 size 2.73TiB used 1.41TiB path /dev/sdc
>>
>
^ permalink raw reply
* Re: [PATCH v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure
From: Jani Nikula @ 2016-11-09 13:04 UTC (permalink / raw)
To: Manasi Navare, intel-gfx; +Cc: Daniel Vetter
In-Reply-To: <1478120139-10763-1-git-send-email-manasi.d.navare@intel.com>
On Wed, 02 Nov 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
> to "BAD" and use a lower link rate to prune the modes. It will redo
> the modeset on the current mode at lower link rate or if the current
> mode gets pruned due to lower link constraints then, it will send a
> hotplug uevent for userspace to handle it.
>
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
>
> v3:
> * Set link status property to BAd unconditionally (Jani Nikula)
> * Dont use two separate variables link_train_failed and link_status
> to indicate same thing (Jani Nikula)
> v2:
> * Squashed a few patches (Jani Nikula)
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> drivers/gpu/drm/i915/intel_ddi.c | 22 ++++++++-
> drivers/gpu/drm/i915/intel_dp.c | 70 ++++++++++++++++++++++++---
> drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> drivers/gpu/drm/i915/intel_drv.h | 6 ++-
> 5 files changed, 105 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 75ad01d..94b0b3a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> connector_state);
> if (ret)
> return ret;
> +
> + if (connector->state->crtc) {
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> + connector->state->crtc);
> + if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> + crtc_state->connectors_changed = true;
> + }
> }
Could this be a separate patch? Anyway needs to be posted on dri-devel.
>
> /*
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> index 938ac4d..a59f8d2 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum port port = intel_ddi_get_encoder_port(encoder);
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_connector *connector = &intel_connector->base;
>
> intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> link_mst);
> @@ -1694,7 +1696,25 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> intel_prepare_dp_ddi_buffers(encoder);
> intel_ddi_init_dp_buf_reg(encoder);
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> - intel_dp_start_link_train(intel_dp);
> + if (!intel_dp_start_link_train(intel_dp)) {
> + DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
> + link_rate, lane_count);
> + connector->link_status = DRM_MODE_LINK_STATUS_BAD;
Why does this not use intel_dp_set_link_status_property()?
> + intel_dp_get_link_train_fallback_values(intel_dp, link_rate,
> + lane_count);
> + /* Schedule a Hotplug Uevent to userspace to start modeset */
> + schedule_work(&intel_connector->modeset_retry_work);
> + } else {
> + DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
> + link_rate, lane_count);
> + intel_dp->fallback_link_rate_index = -1;
> + intel_dp->fallback_link_rate = 0;
> + intel_dp->fallback_lane_count = 0;
> + connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
> + intel_dp_set_link_status_property(connector,
> + DRM_MODE_LINK_STATUS_GOOD);
> + }
> +
> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> intel_dp_stop_link_train(intel_dp);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fb4fcdd..659b17f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -310,9 +310,6 @@ void intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> int common_len;
> int link_rate_index = -1;
>
> - if (!intel_dp->link_train_failed)
> - return;
> -
You add this in an earlier patch and now remove it?
> common_len = intel_dp_common_rates(intel_dp, common_rates);
> link_rate_index = intel_dp_link_rate_index(intel_dp,
> common_rates,
> @@ -327,7 +324,6 @@ void intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> intel_dp->fallback_lane_count = lane_count >> 1;
> } else {
> DRM_ERROR("Link Training Unsuccessful\n");
> - intel_dp->link_train_failed = false;
> }
> }
>
> @@ -354,8 +350,14 @@ void intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> target_clock = fixed_mode->clock;
> }
>
> - max_link_clock = intel_dp_max_link_rate(intel_dp);
> - max_lanes = intel_dp_max_lane_count(intel_dp);
> + /* Prune the modes using the fallback link rate/lane count */
> + if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
> + max_link_clock = intel_dp->fallback_link_rate;
> + max_lanes = intel_dp->fallback_lane_count;
> + } else {
> + max_link_clock = intel_dp_max_link_rate(intel_dp);
> + max_lanes = intel_dp_max_lane_count(intel_dp);
> + }
>
> max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> mode_rate = intel_dp_link_required(target_clock, 18);
> @@ -1593,6 +1595,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
> enum port port = dp_to_dig_port(intel_dp)->port;
> struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
> struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_connector *connector = &intel_connector->base;
> int lane_count, clock;
> int min_lane_count = 1;
> int max_lane_count = intel_dp_max_lane_count(intel_dp);
> @@ -1640,6 +1643,12 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> return false;
>
> + /* Fall back to lower link rate in case of failure in previous modeset */
> + if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
> + min_lane_count = max_lane_count = intel_dp->fallback_lane_count;
> + min_clock = max_clock = intel_dp->fallback_link_rate_index;
> + }
> +
> DRM_DEBUG_KMS("DP link computation with max lane count %i "
> "max bw %d pixel clock %iKHz\n",
> max_lane_count, common_rates[max_clock],
> @@ -4423,6 +4432,12 @@ static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> intel_dp->compliance_test_active = 0;
> intel_dp->compliance_test_type = 0;
> intel_dp->compliance_test_data = 0;
> + intel_dp->fallback_link_rate_index = -1;
> + intel_dp->fallback_link_rate = 0;
> + intel_dp->fallback_lane_count = 0;
> + connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
> + intel_dp_set_link_status_property(connector,
> + DRM_MODE_LINK_STATUS_GOOD);
Seems like it would be a good idea to have this
intel_dp_set_link_status_property() helper set connector->link_status
too.
>
> if (intel_dp->is_mst) {
> DRM_DEBUG_KMS("MST device may have disappeared %d vs %d\n",
> @@ -4514,6 +4529,11 @@ static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
>
> + /* If this is a retry due to link trianing failure */
> + if (status == connector_status_connected &&
> + connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> + return status;
> +
> /* If full detect is not performed yet, do a full detect */
> if (!intel_dp->detect_done)
> status = intel_dp_long_pulse(intel_dp->attached_connector);
> @@ -5692,6 +5712,40 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
> return false;
> }
>
> +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> +{
> + struct intel_connector *intel_connector;
> + struct drm_connector *connector;
> + struct drm_display_mode *mode;
> + bool verbose_prune = true;
> +
> + intel_connector = container_of(work, typeof(*intel_connector),
> + modeset_retry_work);
> + connector = &intel_connector->base;
> +
> + /* Grab the locks before changing connector property*/
> + mutex_lock(&connector->dev->mode_config.mutex);
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> + connector->name);
> + list_for_each_entry(mode, &connector->modes, head) {
> + mode->status = intel_dp_mode_valid(connector,
> + mode);
> + }
> + drm_mode_prune_invalid(connector->dev, &connector->modes,
> + verbose_prune);
> +
> + /* Set connector link status to BAD and send a Uevent to notify
> + * userspace to do a modeset.
> + */
> + connector->link_status = DRM_MODE_LINK_STATUS_BAD;
> + intel_dp_set_link_status_property(connector,
> + DRM_MODE_LINK_STATUS_BAD);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> +
> + /* Send Hotplug uevent so userspace can reprobe */
> + drm_kms_helper_hotplug_event(connector->dev);
> +}
> +
> bool
> intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> struct intel_connector *intel_connector)
> @@ -5704,6 +5758,10 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
> enum port port = intel_dig_port->port;
> int type;
>
> + /* Initialize the work for modeset in case of link train failure */
> + INIT_WORK(&intel_connector->modeset_retry_work,
> + intel_dp_modeset_retry_work_fn);
> +
> if (WARN(intel_dig_port->max_lanes < 1,
> "Not enough lanes (%d) for DP on port %c\n",
> intel_dig_port->max_lanes, port_name(port)))
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 0048b52..10f81ab 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -310,9 +310,15 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
> DP_TRAINING_PATTERN_DISABLE);
> }
>
> -void
> +bool
> intel_dp_start_link_train(struct intel_dp *intel_dp)
> {
> - intel_dp_link_training_clock_recovery(intel_dp);
> - intel_dp_link_training_channel_equalization(intel_dp);
> + bool ret;
> +
> + if (intel_dp_link_training_clock_recovery(intel_dp)) {
> + ret = intel_dp_link_training_channel_equalization(intel_dp);
> + if (ret)
> + return true;
> + }
> + return false;
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index bc25b2b..c0378a9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -312,6 +312,9 @@ struct intel_connector {
> void *port; /* store this opaque as its illegal to dereference it */
>
> struct intel_dp *mst_port;
> +
> + /* Work struct to schedule a uevent on link train failure */
> + struct work_struct modeset_retry_work;
> };
>
> struct dpll {
> @@ -900,7 +903,6 @@ struct intel_dp {
> int fallback_link_rate;
> uint8_t fallback_lane_count;
> int fallback_link_rate_index;
> - bool link_train_failed;
> uint8_t sink_count;
> bool link_mst;
> bool has_audio;
> @@ -1402,7 +1404,7 @@ void intel_dp_set_link_params(struct intel_dp *intel_dp,
> bool link_mst);
> void intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> int link_rate, uint8_t lane_count);
> -void intel_dp_start_link_train(struct intel_dp *intel_dp);
> +bool intel_dp_start_link_train(struct intel_dp *intel_dp);
> void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> void intel_dp_encoder_reset(struct drm_encoder *encoder);
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [RFC] [PATCH] Mounting "degraded,rw" should allow for any number of devices missing
From: Roman Mamedov @ 2016-11-09 13:03 UTC (permalink / raw)
To: linux-btrfs@vger.kernel.org
Hello,
Mounting "degraded,rw" should allow for any number of devices missing, as in
many cases the current check seems overly strict and not helpful during what
is already a manual recovery scenario. Let's assume the user applying the
"degraded" option knows best what condition their FS is in and what are the
next steps required to recover from the degraded state.
Specifically this would allow salvaging "JBOD-style" arrays of data=single
metadata=RAID1, if the user is ready to accept loss of data portions which
were on the removed drive. Currently if one of the disks got removed it is not
possible for such array to be mounted rw at all -- hence not possible to
"dev delete missing" and the only solution is to recreate the FS.
Besides, I am currently testing a concept of SSD+HDD array with data=single
and metadata=RAID1, where the SSD is used for RAID1 metadata chunks only.
E.g. my 13 TB FS only has about 14 GB of metadata at the moment, so I could
comfortably use a spare 60GB SSD as a metadata-only device for it.
(Making all metadata reads prefer SSD could be the next step.)
It would be nice to be able to just lose/fail/forget that SSD, without having
to redo the entire FS. But again, since the remaining device has data=single,
currently it won't be write-mountable in the degraded state, even though the
missing device had only ever contained RAID1 chunks.
Maybe someone has other ideas how to solve the above scenarios?
Thanks
--- linux-amd64-4.4/fs/btrfs/disk-io.c.orig 2016-11-09 16:19:50.431117913 +0500
+++ linux-amd64-4.4/fs/btrfs/disk-io.c 2016-11-09 16:20:31.567117874 +0500
@@ -2992,7 +2992,8 @@
btrfs_calc_num_tolerated_disk_barrier_failures(fs_info);
if (fs_info->fs_devices->missing_devices >
fs_info->num_tolerated_disk_barrier_failures &&
- !(sb->s_flags & MS_RDONLY)) {
+ !(sb->s_flags & MS_RDONLY) &&
+ !btrfs_raw_test_opt(fs_info->mount_opt, DEGRADED)) {
pr_warn("BTRFS: missing devices(%llu) exceeds the limit(%d), writeable mount is not allowed\n",
fs_info->fs_devices->missing_devices,
fs_info->num_tolerated_disk_barrier_failures);
^ permalink raw reply
* Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level
From: Sebastian Frias @ 2016-11-09 13:02 UTC (permalink / raw)
To: Måns Rullgård, Florian Fainelli
Cc: David S. Miller, netdev, LKML, Mason, Andrew Lunn
In-Reply-To: <yw1x1syrjil8.fsf@unicorn.mansr.com>
On 11/04/2016 05:49 PM, Måns Rullgård wrote:
>>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers
>>> will apply the delay.
>>>
>>> I think a better way of dealing with this is that both, PHY and MAC
>>> drivers exchange information so that the delay is applied only once.
>>
>> Exchange what information? The PHY device interface (phydev->interface)
>> conveys the needed information for both entities.
>
> There doesn't seem to be any consensus among the drivers regarding where
> the delay should be applied. Since only a few drivers, MAC or PHY, act
> on this property, most combinations still work by chance. It is common
> for boards to set the delay at the PHY using external config pins so no
> software setup is required (although I have one Sigma based board that
> gets this wrong). I suspect if drivers/net/ethernet/broadcom/genet were
> used with one of the four PHY drivers that also set the delay based on
> this DT property, things would go wrong.
>
Exactly, what about a patch like (I can make a formal submission, even
merge it with the patch discussed in this thread, consider this a RFC):
diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
index fba2699..4217ff4 100644
--- a/drivers/net/ethernet/aurora/nb8800.c
+++ b/drivers/net/ethernet/aurora/nb8800.c
@@ -1283,6 +1283,10 @@ static int nb8800_tangox_init(struct net_device *dev)
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
pad_mode = PAD_MODE_RGMII;
+
+ if ((dev->phydev->flags & PHY_SUPPORTS_TXID) == 0)
+ pad_mode |= PAD_MODE_GTX_CLK_DELAY;
+
break;
default:
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 2e0c759..5eddb04 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -426,7 +426,9 @@ static int at803x_aneg_done(struct phy_device *phydev)
.suspend = at803x_suspend,
.resume = at803x_resume,
.features = PHY_GBIT_FEATURES,
- .flags = PHY_HAS_INTERRUPT,
+ .flags = PHY_HAS_INTERRUPT |
+ PHY_SUPPORTS_RXID |
+ PHY_SUPPORTS_TXID,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = at803x_ack_interrupt,
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e7e1fd3..0f0b17e 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -61,6 +61,8 @@
#define PHY_HAS_INTERRUPT 0x00000001
#define PHY_HAS_MAGICANEG 0x00000002
#define PHY_IS_INTERNAL 0x00000004
+#define PHY_SUPPORTS_RXID 0x00000008
+#define PHY_SUPPORTS_TXID 0x00000010
#define MDIO_DEVICE_IS_PHY 0x80000000
/* Interface Mode definitions */
^ permalink raw reply related
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Zhang, Helin @ 2016-11-09 13:01 UTC (permalink / raw)
To: Topel, Bjorn, Ananyev, Konstantin, dev@dpdk.org
Cc: Xu, Qian Q, Yao, Lei A, Wu, Jingjing, thomas.monjalon@6wind.com
In-Reply-To: <b2592ded-badc-5445-526c-d0203b48f592@intel.com>
> -----Original Message-----
> From: Topel, Bjorn
> Sent: Wednesday, November 9, 2016 7:28 PM
> To: Ananyev, Konstantin; dev@dpdk.org; Zhang, Helin
> Cc: Xu, Qian Q; Yao, Lei A; Wu, Jingjing; thomas.monjalon@6wind.com
> Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: force CRC stripping for
> i40evf
>
> >> Correct, so the broader question would be "what is the correct
> >> behavior for an example application, when a port configuration isn't
> >> supported by the hardware?".
> >>
> >> My stand, FWIW, is that igb and ixgbe should have the same semantics
> >> as i40e currently has, i.e. return an error to the user if the port
> >> is mis-configured, NOT changing the setting behind the users back.
> >>
> >
> > Fine by me, but then it means that the fix haw to include changes for
> > all apps plus ixgbe and igb PMDs, correct? :)
>
> Ugh. Correct, I guess. :-)
>
> As for ixgbe and igb - they need a patch changing from silent ignore to
> explicit error. Regarding the apps, I guess all the apps that rely on that
> disabling CRC stripping always work, need some work. Or should all the
> example applications have CRC stripping *enabled* by default? I'd assume
> that all DPDK supported NICs has support for CRC stripping and I guess this is
> the rational for having it on by default for Intel VFs.
>
> In general, for the example applications, if an application relies on a property
> for a port, that the hardware doesn't support -- what would be the desired
> behavior? Or is it implied that the example applications only use a common,
> minimal set of features that are know to be supported by all DPDK supported
> hardware?
>
> Isn't it perfectly valid that some example applications wont run for all
> hardware?
>
> Finally, why doesn't l3fwd have the CRC stripped?
>
>
> Björn
Yes, i40e driver changed a little bit on that according to the review comments
during implementation, comparing to igb and ixgbe.
I'd suggest to re-invesitgate if we can do the similar thing in igb and ixgbe driver.
Any critical issue now? Or just an improvement comments?
Thanks,
Helin
^ permalink raw reply
* Re: [PATCH 0/4] cputime: some optimizations and cleanups
From: Frederic Weisbecker @ 2016-11-09 13:01 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: LKML, Ingo Molnar, Peter Zijlstra, Paul Mackerras,
Benjamin Herrenschmidt, Michael Neuling, ppc-dev,
Martin Schwidefsky, Heiko Carstens, linux-s390
In-Reply-To: <1477917389-11341-1-git-send-email-sgruszka@redhat.com>
2016-10-31 12:36 GMT+00:00 Stanislaw Gruszka <sgruszka@redhat.com>:
> Patches remove accounting of utimescaled/stimescaled on architectures
> that do not provide those values (scaled cputimes are equal to normal
> cputimes) what is every architecture except powerpc and s390.
>
> Patches do not change user visible behaviour.
>
> There is very little documentation how scaled cputimes should be
> interpreted and what useful information they provide (at least
> I could not find that). Moreover they are exported to user-space
> only via not commonly used taskstats and delayacct interfaces (i.e.
> interfaces that are not used by standard linux tools AFICT). However
> I assume they can not be removed by whole (i.e. replaced by normal
> utimes/stimes on powerpc and s390).
>
> Stanislaw Gruszka (4):
> cputime/powerpc: remove cputime_last_delta global variable
> cputime/powerpc: remove cputime_to_scaled()
> cputime/powerpc/s390: make scaled cputime arch specific
> cputime: simplify task_cputime()
>
> arch/ia64/kernel/time.c | 4 +-
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/cputime.h | 14 ----
> arch/powerpc/kernel/time.c | 8 +-
> arch/s390/Kconfig | 1 +
> arch/s390/kernel/vtime.c | 9 ++-
> arch/x86/kernel/apm_32.c | 4 +-
> include/asm-generic/cputime_jiffies.h | 1 -
> include/asm-generic/cputime_nsecs.h | 1 -
> include/linux/kernel_stat.h | 4 +-
> include/linux/sched.h | 29 +++++---
> kernel/fork.c | 2 +
> kernel/sched/cputime.c | 124 +++++++++------------------------
> kernel/time/posix-cpu-timers.c | 4 +-
> 14 files changed, 73 insertions(+), 133 deletions(-)
>
Excellent patchset!
Thanks a lot Stanislaw!
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
^ permalink raw reply
* error: package X is already installed
From: Yannick Kiekens @ 2016-11-09 12:57 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
Hi all,
I am porting several projects from Jethro to Morty.
Some of those projects give several hundreds of "error: package X is
already installed" during do_populate_sdk stage in Morty.
These projects compiled fine in Jethro.
What can cause these errors?
Mvg
Yannick Kiekens
[-- Attachment #2: Type: text/html, Size: 601 bytes --]
^ permalink raw reply
* [PATCH 1/2] skd: fix msix error handling
From: Arnd Bergmann @ 2016-11-09 12:55 UTC (permalink / raw)
To: Jens Axboe
Cc: Christoph Hellwig, Arnd Bergmann, Mike Christie, Hannes Reinecke,
Ming Lin, linux-kernel
As reported by gcc -Wmaybe-uninitialized, the cleanup path for
skd_acquire_msix tries to free the already allocated msi-x vectors
in reverse order, but the index variable may not have been
used yet:
drivers/block/skd_main.c: In function ‘skd_acquire_irq’:
drivers/block/skd_main.c:3890:8: error: ‘i’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
This changes the failure path to skip releasing the interrupts
if we have not started requesting them yet.
Fixes: 180b0ae77d49 ("skd: use pci_alloc_irq_vectors")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/block/skd_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index a58256cd94d7..66146b349229 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -3849,7 +3849,7 @@ static int skd_acquire_msix(struct skd_device *skdev)
if (rc < 0) {
pr_err("(%s): failed to enable MSI-X %d\n",
skd_name(skdev), rc);
- goto msix_out;
+ goto out;
}
skdev->msix_entries = kcalloc(SKD_MAX_MSIX_COUNT,
@@ -3858,7 +3858,7 @@ static int skd_acquire_msix(struct skd_device *skdev)
rc = -ENOMEM;
pr_err("(%s): msix table allocation error\n",
skd_name(skdev));
- goto msix_out;
+ goto out;
}
/* Enable MSI-X vectors for the base queue */
@@ -3889,6 +3889,7 @@ static int skd_acquire_msix(struct skd_device *skdev)
msix_out:
while (--i >= 0)
devm_free_irq(&pdev->dev, pci_irq_vector(pdev, i), skdev);
+out:
kfree(skdev->msix_entries);
skdev->msix_entries = NULL;
return rc;
--
2.9.0
^ permalink raw reply related
* [PATCH 2/2] skd: fix function prototype
From: Arnd Bergmann @ 2016-11-09 12:55 UTC (permalink / raw)
To: Jens Axboe
Cc: Christoph Hellwig, Arnd Bergmann, Johannes Thumshirn, Ming Lin,
linux-kernel
In-Reply-To: <20161109125555.1440353-1-arnd@arndb.de>
Building with W=1 shows a harmless warning for the skd driver:
drivers/block/skd_main.c:2959:1: error: ‘static’ is not at beginning of declaration [-Werror=old-style-declaration]
This changes the prototype to the expected formatting.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/block/skd_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index 66146b349229..1e536b97f802 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -2945,8 +2945,8 @@ static void skd_completion_worker(struct work_struct *work)
static void skd_isr_msg_from_dev(struct skd_device *skdev);
-irqreturn_t
-static skd_isr(int irq, void *ptr)
+static irqreturn_t
+skd_isr(int irq, void *ptr)
{
struct skd_device *skdev;
u32 intstat;
--
2.9.0
^ permalink raw reply related
* [PATCH 2/2] net: mvpp2: simplify MAC address set code
From: Baruch Siach @ 2016-11-09 12:56 UTC (permalink / raw)
To: Marcin Wojtas; +Cc: netdev, Thomas Petazzoni, Gregory Clement, Baruch Siach
In-Reply-To: <ff17831771f3575f351c134703d3f153485b01c0.1478696194.git.baruch@tkos.co.il>
Remove duplicated code for handling the !netif_running() case.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Build tested only.
---
drivers/net/ethernet/marvell/mvpp2.c | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index e427b4706726..64b7f985d517 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5674,32 +5674,28 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
{
struct mvpp2_port *port = netdev_priv(dev);
const struct sockaddr *addr = p;
- int err;
+ int err, restart_dev = 0;
if (!is_valid_ether_addr(addr->sa_data)) {
err = -EADDRNOTAVAIL;
goto error;
}
- if (!netif_running(dev)) {
- err = mvpp2_prs_update_mac_da(dev, addr->sa_data);
- if (!err)
- return 0;
- /* Reconfigure parser to accept the original MAC address */
+ if (netif_running(dev)) {
+ mvpp2_stop_dev(port);
+ restart_dev = 1;
+ }
+
+ err = mvpp2_prs_update_mac_da(dev, addr->sa_data);
+ if (err) {
+ /* Reconfigure parser accept the original MAC address */
mvpp2_prs_update_mac_da(dev, dev->dev_addr);
goto error;
}
- mvpp2_stop_dev(port);
-
- err = mvpp2_prs_update_mac_da(dev, addr->sa_data);
- if (!err)
- goto out_start;
+ if (!restart_dev)
+ return 0;
- /* Reconfigure parser accept the original MAC address */
- mvpp2_prs_update_mac_da(dev, dev->dev_addr);
- goto error;
-out_start:
mvpp2_start_dev(port);
mvpp2_egress_enable(port);
mvpp2_ingress_enable(port);
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] net: mvpp2: don't bring up on MAC address set
From: Baruch Siach @ 2016-11-09 12:56 UTC (permalink / raw)
To: Marcin Wojtas; +Cc: netdev, Thomas Petazzoni, Gregory Clement, Baruch Siach
Current .ndo_set_mac_address implementation brings up the interface when revert
to original address after failure succeeds. Fix this.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Untested; I don't have the hardware.
---
drivers/net/ethernet/marvell/mvpp2.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 60227a3452a4..e427b4706726 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5686,9 +5686,8 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
if (!err)
return 0;
/* Reconfigure parser to accept the original MAC address */
- err = mvpp2_prs_update_mac_da(dev, dev->dev_addr);
- if (err)
- goto error;
+ mvpp2_prs_update_mac_da(dev, dev->dev_addr);
+ goto error;
}
mvpp2_stop_dev(port);
@@ -5698,9 +5697,8 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
goto out_start;
/* Reconfigure parser accept the original MAC address */
- err = mvpp2_prs_update_mac_da(dev, dev->dev_addr);
- if (err)
- goto error;
+ mvpp2_prs_update_mac_da(dev, dev->dev_addr);
+ goto error;
out_start:
mvpp2_start_dev(port);
mvpp2_egress_enable(port);
--
2.10.2
^ permalink raw reply related
* disable hugepages
From: Keren Hochman @ 2016-11-09 12:55 UTC (permalink / raw)
To: dev
Hi,
how can I create mempool without hugepages?My application is running on a
pcap file so no huge pages is needed ?
Thanks.
^ permalink raw reply
* [Qemu-devel] [Bug 881637] Re: QEMU fails to build on OpenBSD/hppa
From: Thomas Huth @ 2016-11-09 12:44 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20111025194609.17756.53947.malonedeb@gac.canonical.com>
Do you still have this problem with the latest version of QEMU and a
more recent version of GCC?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/881637
Title:
QEMU fails to build on OpenBSD/hppa
Status in QEMU:
Incomplete
Bug description:
Trying to build previous QEMU releases as well as git code fails on
OpenBSD/hppa...
cc -I/home/hack/jasper/qemu/slirp -I. -I/home/hack/jasper/qemu -I/home/hack/jasper/qemu/fpu -I/home/hack/jasper/qemu/tcg -I/home/hack/jasper/qemu/tcg/hppa -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wno-redundant-decls -I/usr/local/include -I/usr/X11R6/include -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/hack/jasper/qemu/target-i386 -DNEED_CPU_H -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -MMD -MP -MT translate.o -MF ./translate.d -O2 -g -c -o translate.o /home/hack/jasper/qemu/target-i386/translate.c
/tmp//ccvNbj1U.s: Assembler messages:
/tmp//ccvNbj1U.s:258792: Error: Field out of range [-262144..262143] (-262776).
/tmp//ccvNbj1U.s:261989: Error: Field out of range [-262144..262143] (-267096).
/tmp//ccvNbj1U.s:262006: Error: Field out of range [-262144..262143] (-267136).
/tmp//ccvNbj1U.s:264184: Error: Field out of range [-262144..262143] (-270612).
/tmp//ccvNbj1U.s:271893: Error: Field out of range [-262144..262143] (-281260).
/tmp//ccvNbj1U.s:276623: Error: Field out of range [-262144..262143] (-288784).
/tmp//ccvNbj1U.s:276906: Error: Field out of range [-262144..262143] (-289636).
/tmp//ccvNbj1U.s:277122: Error: Field out of range [-262144..262143] (-290280).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/881637/+subscriptions
^ permalink raw reply
* hppa qemu and string functions
From: Richard Henderson @ 2016-11-09 12:53 UTC (permalink / raw)
To: linux-parisc; +Cc: GNU C Library
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
Off and on, I've been working on a user-only target of hppa to qemu. It's now
about 95% working. If anyone would like to try it out, it's available at
git://github.com/rth7680/qemu.git tgt-hppa
While implementing the unit-type instructions, I wondered why no one (outside
hp?) had written a version of the string routines utilizing the UXOR insn, with
the SomeByteZero and NoByteZero conditions.
Attached are versions of strlen, strchr and strrchr. They pass simple tests
within my emulator; I'd be interested to know if they pass full glibc testing
on real hardware.
Thanks,
r~
[-- Attachment #2: strlen.S --]
[-- Type: text/plain, Size: 1258 bytes --]
;! HP-PA strlen
;! Copyright (C) 2016 Free Software Foundation, Inc.
.text
.export strlen
.balign 16
strlen:
.proc
.callinfo frame=0,no_calls
.entry
;! Compute the number of bytes required to align the pointer.
;! Shifting by 1 gets us 4 insns to play with per entry.
ldo -1(%r26), %r20
depw,z %r20, 30, 2, %r20
blr %r20, %r0
copy %r26, %r28
;! ptr % 4 == 1
ldb 0(%r26), %r20
cmpiclr,= 0, %r20, %r0
b,n 9f
ldo 1(%r26), %r26
;! ptr % 4 == 2
ldb 0(%r26), %r20
cmpiclr,= 0, %r20, %r0
b,n 9f
ldo 1(%r26), %r26
;! ptr % 4 == 3
ldb 0(%r26), %r20
cmpiclr,= 0, %r20, %r0
b,n 9f
ldo 1(%r26), %r26
;! ptr % 4 == 0
;! Main loop. Use the Some Byte Zero unit condition to find
;; a word containing the string terminator.
0: ldw,ma 4(%r26), %r20
uxor,sbz %r0, %r20, %r0
b,n 0b
;! Found, somewhere in with word in %r20. Test each byte in
;! sequence, computing the appopriate offset from %r26 into %r21.
ldo -1(%r26), %r21
extrw,u,<> %r20, 23, 8, %r0
ldo -2(%r26), %r21
extrw,u,<> %r20, 15, 8, %r0
ldo -3(%r26), %r21
extrw,u,<> %r20, 7, 8, %r0
ldo -4(%r26), %r21
bv 0(%r2)
sub %r21, %r28, %r28
;! Found, with no displacement off %r26.
9: bv 0(%r2)
sub %r26, %r28, %r28
.exit
.procend
[-- Attachment #3: strchr.S --]
[-- Type: text/plain, Size: 1791 bytes --]
;! HP-PA strchr
;! Copyright (C) 2016 Free Software Foundation, Inc.
.text
.export strchr
.balign 16
strchr:
.proc
.callinfo frame=0,no_calls
.entry
;! Compute the number of bytes required to align the pointer.
;! Multiply by 3, giving us 6 insns per entry to work with.
ldo -1(%r26), %r20
extrw,u %r25, 31, 8, %r25
extrw,u %r20, 31, 2, %r20
shladd,l %r20, 1, %r20, %r20
blr %r20, %r0
copy %r26, %r28
;! ptr % 4 == 1
ldb 0(%r28), %r20
cmpclr,<> %r25, %r20, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r20, %r0
b,n 9f
ldo 1(%r28), %r28
;! ptr % 4 == 2
ldb 0(%r28), %r20
cmpclr,<> %r25, %r20, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r20, %r0
b,n 9f
ldo 1(%r28), %r28
;! ptr % 4 == 3
ldb 0(%r28), %r20
cmpclr,<> %r25, %r20, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r20, %r0
b,n 9f
ldo 1(%r28), %r28
;! ptr % 4 == 0
ldw,ma 4(%r28), %r20
depw %r25, 23, 8, %r25
depw %r25, 15, 16, %r25
;! Main loop. Use the No Byte Zero unit condition to find
;; a word containing C or 0.
0: uxor,nbz %r25, %r20, %r0
b,n 1f
uxor,nbz %r0, %r20, %r0
b,n 1f
b 0b
ldw,ma 4(%r28), %r20
;! Found, somewhere in with word in %r20.
;! Test each byte in sequence.
1: extrw,u %r25, 31, 8, %r25
extrw,u %r20, 7, 8, %r21
ldo -4(%r28), %r28
cmpclr,<> %r25, %r21, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r21, %r0
b,n 9f
extrw,u %r20, 15, 8, %r21
ldo 1(%r28), %r28
cmpclr,<> %r25, %r21, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r21, %r0
b,n 9f
extrw,u %r20, 23, 8, %r21
ldo 1(%r28), %r28
cmpclr,<> %r25, %r21, %r0
bv,n 0(%r2)
cmpclr,<> %r0, %r21, %r0
b,n 9f
extrw,u %r20, 31, 8, %r21
ldo 1(%r28), %r28
cmpclr,<> %r25, %r21, %r0
bv,n 0(%r2)
;! String terminator found before the search character.
9: bv 0(%r2)
ldi 0, %r28
.exit
.procend
[-- Attachment #4: strrchr.S --]
[-- Type: text/plain, Size: 2554 bytes --]
;! HP-PA strrchr
;! Copyright (C) 2016 Free Software Foundation, Inc.
.text
.export strrchr
.balign 16
strrchr:
.proc
.callinfo frame=0,no_calls
.entry
;! Compute the number of bytes required to align the pointer.
;! Multiply by 3, giving us 6 insns per entry to work with.
ldo -1(%r26), %r20
extrw,u %r25, 31, 8, %r25
extrw,u %r20, 31, 2, %r20
shladd,l %r20, 1, %r20, %r20
blr %r20, %r0
;! Begin by assuming that C is not present.
ldi 0, %r28
;! ptr % 4 == 1
ldb 0(%r26), %r20
cmpclr,<> %r25, %r20, %r0
copy %r26, %r28
cmpclr,<> %r0, %r20, %r0
bv,n 0(%r2)
ldo 1(%r26), %r26
;! ptr % 4 == 2
ldb 0(%r26), %r20
cmpclr,<> %r25, %r20, %r0
copy %r26, %r28
cmpclr,<> %r0, %r20, %r0
bv,n 0(%r2)
ldo 1(%r26), %r26
;! ptr % 4 == 3
ldb 0(%r26), %r20
cmpclr,<> %r25, %r20, %r0
copy %r26, %r28
cmpclr,<> %r0, %r20, %r0
bv,n 0(%r2)
ldo 1(%r26), %r26
;! ptr % 4 == 0
ldw,ma 4(%r26), %r20
copy %r25, %r24
depw %r24, 23, 8, %r24
depw %r24, 15, 16, %r24
;! Main loop.
0: ;; Test for a NUL terminator within the word and exit if found.
uxor,nbz %r0, %r20, %r0
b,n 1f
;; Test for C within the word. If not found, loop and load the
;; next word in the delay slot. If found, load the next word
;; now anyway, since we know that we havn't seen end-of-string.
copy %r20, %r21
uxor,sbz %r24, %r20, %r0
b 0b
ldw,ma 4(%r26), %r20
;; Found C within the "current" word. Note that it is now in %r21,
;; and the address for the beginning of that word is now -8(%r26),
;; since we have incremented the pointer twice since the load.
extrw,u %r21, 7, 8, %r22
cmpclr,<> %r25, %r22, %r0
ldo -8(%r26), %r28
extrw,u %r21, 15, 8, %r22
cmpclr,<> %r25, %r22, %r0
ldo -7(%r26), %r28
extrw,u %r21, 23, 8, %r22
cmpclr,<> %r25, %r22, %r0
ldo -6(%r26), %r28
extrw,u %r21, 31, 8, %r22
cmpclr,<> %r25, %r22, %r0
ldo -5(%r26), %r28
b,n 0b
;! Found NUL somewhere in with word in %r20, loaded from -4(%r26).
;! Test each byte in sequence.
1: extrw,u %r20, 7, 8, %r21
cmpclr,<> %r25, %r21, %r0
ldo -4(%r26), %r28
cmpclr,<> %r0, %r21, %r0
bv,n 0(%r2)
extrw,u %r20, 15, 8, %r21
cmpclr,<> %r25, %r21, %r0
ldo -3(%r26), %r28
cmpclr,<> %r0, %r21, %r0
bv,n 0(%r2)
extrw,u %r20, 23, 8, %r21
cmpclr,<> %r25, %r21, %r0
ldo -2(%r26), %r28
cmpclr,<> %r0, %r21, %r0
bv,n 0(%r2)
;; Having checked the others, the last byte must be NUL.
;; Do check for the unusual case of C == NUL.
cmpclr,<> %r25, %r0, %r0
ldo -1(%r26), %r28
bv,n 0(%r2)
.exit
.procend
^ permalink raw reply
* [xen-unstable test] 102045: tolerable FAIL - PUSHED
From: osstest service owner @ 2016-11-09 12:53 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 16480 bytes --]
flight 102045 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102045/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 102008
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 102008
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 102008
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102008
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 102008
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 102008
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 102008
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 102008
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102008
test-amd64-amd64-xl-rtds 9 debian-install fail like 102008
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a
test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
build-amd64-rumprun 7 xen-build fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
build-i386-rumprun 7 xen-build fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
version targeted for testing:
xen bcb13635fa503113c981c6ea7423f930c1548452
baseline version:
xen 8a35a95615b1a64c98c30195f343bc2c58054d9d
Last test of basis 102008 2016-11-07 16:52:13 Z 1 days
Testing same since 102027 2016-11-08 04:30:42 Z 1 days 2 attempts
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@suse.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun fail
build-i386-rumprun fail
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 blocked
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 blocked
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 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 :
+ branch=xen-unstable
+ revision=bcb13635fa503113c981c6ea7423f930c1548452
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable bcb13635fa503113c981c6ea7423f930c1548452
+ branch=xen-unstable
+ revision=bcb13635fa503113c981c6ea7423f930c1548452
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xbcb13635fa503113c981c6ea7423f930c1548452 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.xen-unstable
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/xen
+ git push osstest@xenbits.xen.org:/home/xen/git/xen.git bcb13635fa503113c981c6ea7423f930c1548452:refs/heads/master
To osstest@xenbits.xen.org:/home/xen/git/xen.git
8a35a95..bcb1363 bcb13635fa503113c981c6ea7423f930c1548452 -> master
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group
From: Jike Song @ 2016-11-09 12:49 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alex Williamson, guangrong.xiao, kwankhede, cjia, kevin.tian, kvm
In-Reply-To: <9e83a26f-e5dc-ed91-a1b5-c6f165eed7ed@redhat.com>
On 11/08/2016 04:45 AM, Paolo Bonzini wrote:
> On 07/11/2016 19:28, Alex Williamson wrote:
>>>> Can the reference become invalid?
>>>
>>> No, this is guaranteed by virt/kvm/vfio.c + the udata.lock mutex (which
>>> probably should be renamed...).
>>
>> The caller gets a reference to kvm, but there's no guarantee that the
>> association of that kvm reference to the group stays valid. Once we're
>> outside of that mutex, we might as well consider that kvm:group
>> association stale.
>>
>>>> The caller may still hold
>>>> a kvm references, but couldn't the group be detached from one kvm
>>>> instance and re-attached to another?
>>>
>>> Can this be handled by the vendor driver? Does it get a callback when
>>> it's detached from a KVM instance?
>>
>> The only release callback through vfio is when the user closes the
>> device, the code in this series is the full extent of vfio awareness of
>> kvm. Thanks,
>
> Maybe there should be an mdev callback at the point of association and
> deassociation between VFIO and KVM. Then the vendor driver can just use
> the same mutex for association, deassociation and usage. I'm not even
> sure that these patches are necessary once you have that callback.
Hi Alex & Paolo,
So I cooked another draft version of this, there is no kvm pointer saved
in vfio_group in this version, and notifier will be called on attach/detach,
please kindly have a look :-)
--
Thanks,
Jike
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index ed2361e4..20b5da9 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -34,6 +34,7 @@
#include <linux/uaccess.h>
#include <linux/vfio.h>
#include <linux/wait.h>
+#include <linux/kvm_host.h>
#define DRIVER_VERSION "0.3"
#define DRIVER_AUTHOR "Alex Williamson <alex.williamson@redhat.com>"
@@ -86,6 +87,10 @@ struct vfio_group {
struct mutex unbound_lock;
atomic_t opened;
bool noiommu;
+ struct {
+ struct mutex lock;
+ struct blocking_notifier_head notifier;
+ } udata;
};
struct vfio_device {
@@ -333,6 +338,7 @@ static struct vfio_group *vfio_create_group(struct iommu_group *iommu_group)
mutex_init(&group->device_lock);
INIT_LIST_HEAD(&group->unbound_list);
mutex_init(&group->unbound_lock);
+ mutex_init(&group->udata.lock);
atomic_set(&group->container_users, 0);
atomic_set(&group->opened, 0);
group->iommu_group = iommu_group;
@@ -414,10 +420,11 @@ static void vfio_group_release(struct kref *kref)
iommu_group_put(iommu_group);
}
-static void vfio_group_put(struct vfio_group *group)
+void vfio_group_put(struct vfio_group *group)
{
kref_put_mutex(&group->kref, vfio_group_release, &vfio.group_lock);
}
+EXPORT_SYMBOL_GPL(vfio_group_put);
/* Assume group_lock or group reference is held */
static void vfio_group_get(struct vfio_group *group)
@@ -480,7 +487,7 @@ static struct vfio_group *vfio_group_get_from_minor(int minor)
return group;
}
-static struct vfio_group *vfio_group_get_from_dev(struct device *dev)
+struct vfio_group *vfio_group_get_from_dev(struct device *dev)
{
struct iommu_group *iommu_group;
struct vfio_group *group;
@@ -494,6 +501,7 @@ static struct vfio_group *vfio_group_get_from_dev(struct device *dev)
return group;
}
+EXPORT_SYMBOL_GPL(vfio_group_get_from_dev);
/**
* Device objects - create, release, get, put, search
@@ -1745,6 +1753,44 @@ long vfio_external_check_extension(struct vfio_group *group, unsigned long arg)
}
EXPORT_SYMBOL_GPL(vfio_external_check_extension);
+int vfio_group_register_notifier(struct vfio_group *group, struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&group->udata.notifier, nb);
+}
+EXPORT_SYMBOL_GPL(vfio_group_register_notifier);
+
+int vfio_group_unregister_notifier(struct vfio_group *group, struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&group->udata.notifier, nb);
+}
+EXPORT_SYMBOL_GPL(vfio_group_unregister_notifier);
+
+void vfio_group_attach_kvm(struct vfio_group *group, struct kvm *kvm,
+ void (*fn)(struct kvm *))
+{
+ mutex_lock(&group->udata.lock);
+
+ fn(kvm);
+ blocking_notifier_call_chain(&group->udata.notifier,
+ VFIO_GROUP_NOTIFY_ATTACH_KVM, kvm);
+
+ mutex_unlock(&group->udata.lock);
+}
+EXPORT_SYMBOL_GPL(vfio_group_attach_kvm);
+
+void vfio_group_detach_kvm(struct vfio_group *group, struct kvm *kvm,
+ void (*fn)(struct kvm *))
+{
+ mutex_lock(&group->udata.lock);
+
+ blocking_notifier_call_chain(&group->udata.notifier,
+ VFIO_GROUP_NOTIFY_DETACH_KVM, kvm);
+ fn(kvm);
+
+ mutex_unlock(&group->udata.lock);
+}
+EXPORT_SYMBOL_GPL(vfio_group_detach_kvm);
+
/**
* Sub-module support
*/
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 87c9afe..4819a45 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -102,6 +102,21 @@ extern void vfio_unregister_iommu_driver(
extern long vfio_external_check_extension(struct vfio_group *group,
unsigned long arg);
+extern struct vfio_group *vfio_group_get_from_dev(struct device *dev);
+extern void vfio_group_put(struct vfio_group *group);
+
+#define VFIO_GROUP_NOTIFY_ATTACH_KVM 1
+#define VFIO_GROUP_NOTIFY_DETACH_KVM 2
+struct kvm;
+extern void vfio_group_attach_kvm(struct vfio_group *group, struct kvm *kvm,
+ void (*fn)(struct kvm *));
+extern void vfio_group_detach_kvm(struct vfio_group *group, struct kvm *kvm,
+ void (*fn)(struct kvm *));
+extern int vfio_group_register_notifier(struct vfio_group *group,
+ struct notifier_block *nb);
+extern int vfio_group_unregister_notifier(struct vfio_group *group,
+ struct notifier_block *nb);
+
/*
* Sub-module helpers
*/
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 1dd087d..d889b56 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -60,6 +60,32 @@ static void kvm_vfio_group_put_external_user(struct vfio_group *vfio_group)
symbol_put(vfio_group_put_external_user);
}
+static void kvm_vfio_group_attach_kvm(struct vfio_group *group, struct kvm_device *dev)
+{
+ void (*fn)(struct vfio_group *, struct kvm *, void (*fn)(struct kvm *));
+
+ fn = symbol_get(vfio_group_attach_kvm);
+ if (!fn)
+ return;
+
+ fn(group, dev->kvm, kvm_get_kvm);
+
+ symbol_put(vfio_group_attach_kvm);
+}
+
+static void kvm_vfio_group_detach_kvm(struct vfio_group *group, struct kvm *kvm)
+{
+ void (*fn)(struct vfio_group *, struct kvm *, void (*fn)(struct kvm *));
+
+ fn = symbol_get(vfio_group_detach_kvm);
+ if (!fn)
+ return;
+
+ fn(group, kvm, kvm_put_kvm);
+
+ symbol_put(vfio_group_detach_kvm);
+}
+
static bool kvm_vfio_group_is_coherent(struct vfio_group *vfio_group)
{
long (*fn)(struct vfio_group *, unsigned long);
@@ -155,6 +181,8 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
list_add_tail(&kvg->node, &kv->group_list);
kvg->vfio_group = vfio_group;
+ kvm_vfio_group_attach_kvm(vfio_group, dev);
+
kvm_arch_start_assignment(dev->kvm);
mutex_unlock(&kv->lock);
@@ -196,6 +224,8 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
mutex_unlock(&kv->lock);
+ kvm_vfio_group_detach_kvm(vfio_group, dev->kvm);
+
kvm_vfio_group_put_external_user(vfio_group);
kvm_vfio_update_coherency(dev);
@@ -240,6 +270,7 @@ static void kvm_vfio_destroy(struct kvm_device *dev)
struct kvm_vfio_group *kvg, *tmp;
list_for_each_entry_safe(kvg, tmp, &kv->group_list, node) {
+ kvm_vfio_group_detach_kvm(kvg->vfio_group, dev->kvm);
kvm_vfio_group_put_external_user(kvg->vfio_group);
list_del(&kvg->node);
kfree(kvg);
^ permalink raw reply related
* [Qemu-devel] [Bug 772275] Re: qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging
From: Thomas Huth @ 2016-11-09 12:36 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20110428104838.18779.37169.malonedeb@soybean.canonical.com>
Triaging old bug tickets ... can you still reproduce this problem with
the latest version of QEMU and the latest version of the virtio-net
drivers?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/772275
Title:
qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging
Status in QEMU:
Incomplete
Bug description:
Hi,
I'm a proxmox distrib user,
I have network error with virtio nic cards in win2008r2sp1 server,
only with qemu 0.14 and 2.6.35 kernel combination.
after some network transferts (can be 2mb or 500mb), nic doesn't
respond anymore. only way is to reboot.
e1000 driver working fine.
revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 +
2.6.32 kernel is working fine too.
i'm using virtio nic drivers 1.1.16 from
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from
https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26
i'm not the only proxmox user ,more users reports here :
http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio-
drivers-for-Windows-and-latest-PVE-1.8
i've also see that a slackware user with winxp guest has the same
problem
http://www.spinics.net/lists/kvm/msg51089.html
I can help to debug if it's possible to have logs somewhere .....
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/772275/+subscriptions
^ permalink raw reply
* [Qemu-devel] [Bug 721793] Re: QEMU freezes on startup (100% CPU utilization)
From: Thomas Huth @ 2016-11-09 12:40 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20110219143658.9055.78373.malonedeb@gandwana.canonical.com>
Closing as "Fix released" according to comment #3
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721793
Title:
QEMU freezes on startup (100% CPU utilization)
Status in QEMU:
Fix Released
Bug description:
0.12.5 was the last version of QEMU that runs ok and boots any os
image.
0.13.0-0.14.0 just freeze, and the only thing I see is a black screen and both of them make it use 100% of CPU also.
Both kernels 2.6.35.11 and 2.6.37.1 with and without PAE support.
tested commands:
W2000:
$ qemu -m 256 -localtime -net nic,model=rtl8139 -net tap -usbdevice host:0e21:0750 /var/opt/vm/w2000.img
W2000:
$ qemu /var/opt/vm/w2000.img
OpenBSD 4.8:
$ qemu -cdrom ~/cd48.iso -boot d empty-qcow2.img
tried to use `-M pc-0.12` selector, different audio cards (I've found it caused infinite loop on startup once) -- no luck.
tried to use recent seabios from git -- still no luck.
attached strace log of 0.14.0.
everything was tested on HP mini 311C with Intel Atom N270.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/721793/+subscriptions
^ permalink raw reply
* Re: NVAC "No Signal"
From: Pierre Moreau @ 2016-11-09 12:48 UTC (permalink / raw)
To: poma; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Ben Skeggs
In-Reply-To: <43b17bb3-7b12-b1be-c608-702ebdfd8522-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1932 bytes --]
I retested with both 4.8.4, Ben’s linux-4.9 and linux-4.10 branches (so only
the linux-4.10 branch had the atomic+MST patches).
For all branches, if I bootplug the external screen, I get nothing on the
external screen, and the laptop screen is frozen with some mix of images (but
the laptop itself is not locked up), nothing in dmesg. If I hotplug the screen,
the laptop screen is not frozen, but starting with linux-4.10, I get an EVO
timeout when turning off the external monitor. Adding your patch did not change
anything for me.
Looks like I’ll need to spend some more time testing and bisecting those
issues…
Pierre
On 06:12 am - Nov 08 2016, poma wrote:
> On 21.10.2016 10:56, Pierre Moreau wrote:
> > On 01:15 am - Oct 21 2016, Lukas Wunner wrote:
> >> On Thu, Oct 20, 2016 at 10:08:28AM +0200, Lukas Wunner wrote:
> >>> On Wed, Oct 19, 2016 at 07:58:06PM +0200, Pierre Moreau wrote:
> >>>> For example, my laptop (which also has an NVAC) has been triggering the
> >>>> no-signal message on external monitors way before Ben???s patch landed,
> >>>> but only for some adapters. I haven???t tried Ben???s patch yet, nor
> >>>> yours, but I will certainly do it, and see what effect each of them has.
> >>>
> >>> The external DP port on your MBP5,3 is switchable between GPUs and
> >>> the apple-gmux driver switches it in unison with the panel. Thus
> >>> the NVAC cannot drive external displays when gmux is switched to
> >>> the MCP79. (You probably were aware of this, just wanted to mention
> >> ^^^^^
> >> I meant G96, sorry I mixed it up.
> >>
> >> Lukas
> >
> > Yes, that bit had stayed in my memory, that switching between the two GPUs
> > would not only switch them for the laptop screen, but for the external ones as
> > well. IIRC, I am getting the no signal in both cases, but I need to retest.
> >
> > Pierre
>
> Any news related on your side?
>
>
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Saint Germain @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-btrfs; +Cc: Niccolò Belli
In-Reply-To: <8f0cf023-7189-4de1-a72c-38a4deb8a049@linuxsystems.it>
On Wed, 09 Nov 2016 12:24:51 +0100, Niccolò Belli
<darkbasic@linuxsystems.it> wrote :
>
> On martedì 8 novembre 2016 23:36:25 CET, Saint Germain wrote:
> > Please be aware of these other similar softwares:
> > - jdupes: https://github.com/jbruchon/jdupes
> > - rmlint: https://github.com/sahib/rmlint
> > And of course fdupes.
> >
> > Some intesting points I have seen in them:
> > - use xxhash to identify potential duplicates (huge speedup)
> > - ability to deduplicate read-only snapshots
> > - identify potential reflinked files (see also my email here:
> > https://www.spinics.net/lists/linux-btrfs/msg60081.html)
> > - ability to filter out hardlinks
> > - triangle problem: see jdupes readme
> > - jdupes has started the process to be included in Debian
> >
> > I hope that will help and that you can share some codes with them !
> >
> Hi,
> What do you think about jdupes? I'm searching an alternative to
> duperemove and rmlint doesn't seem to support btrfs deduplication, so
> I would like to try jdupes. My main problem with duperemove is a
> memory leak, also it seems to lead to greater disk usage:
> https://github.com/markfasheh/duperemove/issues/163
rmlint is supporting btrfs deduplication:
rmlint --algorithm=xxhash --types="duplicates" --hidden --config=sh:handler=clone --no-hardlinked
I've used jdupes and rmlint to deduplicate 2TB with 4GB RAM and it took
a few hours. So it is acceptable from a performance point of view.
The problems I found have been corrected by both.
Jdupes author is really kind and reactive !
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
From: Paolo Bonzini @ 2016-11-09 12:47 UTC (permalink / raw)
To: Stefan Hajnoczi, Ketan Nilangekar
Cc: Ashish Mittal, qemu-devel@nongnu.org, kwolf@redhat.com,
armbru@redhat.com, berrange@redhat.com, jcody@redhat.com,
famz@redhat.com, Ashish Mittal, Abhijit Dey
In-Reply-To: <20161108153915.GA11274@stefanha-x1.localdomain>
On 08/11/2016 16:39, Stefan Hajnoczi wrote:
> The current status is:
>
> 1. virtio-blk and virtio-scsi support multiple queues but these queues
> are processed from a single thread today.
>
> 2. MemoryRegions can be marked with !global_locking so its handler
> functions are dispatched without taking the QEMU global mutex. This
> allows device emulation to run in multiple threads.
Alternatively, virtio-blk and virtio-scsi can already use ioeventfd and
"-object iothread,id=FOO -device virtio-blk-pci,iothread=FOO" to let
device emulation run in a separate thread that doesn't take the QEMU
global mutex.
> 3. Paolo Bonzini (CCed) is currently working on make the block layer
> (BlockDriverState and co) support access from multiple threads and
> multiqueue. This is work in progress.
>
> If you are interested in this work keep an eye out for patch series from
> Paolo Bonzini and Fam Zheng.
The first part (drop RFifoLock) was committed for 2.8. It's a
relatively long road, but these are the currently ready parts of the work:
- take AioContext acquire/release in small critical sections
- push AioContext down to individual callbacks
- make BlockDriverState thread-safe
The latter needs rebasing after the last changes to dirty bitmaps, but I
think these patches should be ready for 2.9.
These are the planned bits:
- replace AioContext with fine-grained mutex in bdrv_aio_*
- protect everything with CoMutex in bdrv_co_*
- remove aio_context_acquire/release
For now I was not planning to make network backends support multiqueue,
only files.
Paolo
^ permalink raw reply
* [PATCH 5/5] iommu/mediatek: Fix M4Uv1 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu_v1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..1b736990373f 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -502,6 +502,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 5/5] iommu/mediatek: Fix M4Uv1 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: joro-zLv9SwRftAIdnm+yROfE0A
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---
drivers/iommu/mtk_iommu_v1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..1b736990373f 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -502,6 +502,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 4/5] iommu/mediatek: Fix M4Uv2 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b12c12d74c33..f5591f6aef49 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -410,6 +410,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.