[Spice-devel] Usbredirect HP-printer leads to Windows blue screen
Recently , I encounter a problem , I use my Windows 7 with virt-viewer-6.0 and UsbDk-1.0.19 as client, then connect to a Ubuntu-16.04 guest , and i can select my U-disk to usbredirect successfully , but when i select the HP Color LaserJet M552 printer to redirect , the Windows blue screen occurs at once . I can use this printer in Win7 normally , and after i check a 4G memory bank then redirect printer , blue screen again . Where is the problem ? Hope for help , thanks !___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-server 2/2] docs: Add some notes on event scheduling and threading
> On Thu, Mar 28, 2019 at 10:27:46AM -0400, Frediano Ziglio wrote: > > > On Thu, Mar 28, 2019 at 04:25:31AM -0400, Frediano Ziglio wrote: > > > > > > > > > > On Mon, Mar 11, 2019 at 02:03:33PM +, Frediano Ziglio wrote: > > > > > > Signed-off-by: Frediano Ziglio > > > > > > --- > > > > > > docs/spice_threading_model.txt | 8 > > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > > > diff --git a/docs/spice_threading_model.txt > > > > > > b/docs/spice_threading_model.txt > > > > > > index 9351141c8..25a3a030c 100644 > > > > > > --- a/docs/spice_threading_model.txt > > > > > > +++ b/docs/spice_threading_model.txt > > > > > > @@ -39,6 +39,14 @@ connect, disconnect and migrate. Connect and > > > > > > migrate > > > > > > are > > > > > > asynchronous (the job > > > > > > is done while the current thread is doing something else) while > > > > > > disconnect > > > > > > is > > > > > > synchronous (the main thread will wait for termination). > > > > > > > > > > > > +One aspect to take into consideration is the event scheduling. > > > > > > SPICE > > > > > > uses > > > > > > some > > > > > > +`SpiceCoreInterface` to handle events. As the events will be > > > > > > handled > > > > > > from > > > > > > a > > > > > > +thread based on the core interface you have to use the correct > > > > > > core. > > > > > > Each > > > > > > +channel has an associated core interface which can be retrieved > > > > > > using > > > > > > +`red_channel_get_core_interface`. There's also a main core > > > > > > interface > > > > > > you > > > > > > can get > > > > > > +using `reds_get_core_interface`. `reds_core_timer_*` and > > > > > > `reds_core_watch_*` > > > > > > +functions use the main core interface. > > > > > > > > > > Do we need a few words as to when to use the main core interface? > > > > > Apart from this, looks good to me. > > > > > > > > > > Christophe > > > > > > > > > > > > > It sounds a nice idea. > > > > > > > > But honestly I cannot came with an easy rule beside "If code runs on > > > > main thread like Qemu character devices or everything not running in > > > > a channel you can use the main core interface." > > > > > > Yes, something like your rule would work "Code running in the QEMU > > > thread should use the main core interface. Code running in the cursor or > > > display channel (through RedWorker) should use xxx interface.. Code > > > running in other channels should use yyy. Be aware that a channel's > > > > IMHO all code running in channels should use channel core, no matter > > if they run on main or not (in the past I adjusted this). > > Note that cursor channel code can run in both main and not main > > for instance, not all cursor channels runs under RedWorker. > > I think it's easier to avoid too much exceptions. > > > > > ClientCbs run in a different thread context than the rest of the > > > channel" (though the last sentence may no longer be accurate with the > > > work you are doing in that area). > > > > ClientCbs will be removed, one less thing to know, and new callbacks/vfunc > > will work on the channel thread so not different from other channel code. > > > > > > > > Christophe > > > > > > > Taking into account that ClientCbs part will be soon (I hope) obsolete > > and that part of "channel core for channel core" part is partially there > > I would update to > > > > +One aspect to take into consideration is the event scheduling. SPICE uses > > some > > +`SpiceCoreInterface` to handle events. As the events will be handled from > > a > > +thread based on the core interface you have to use the correct core. Each > > +channel has an associated core interface which can be retrieved using > > +`red_channel_get_core_interface`. There's also a main core interface you > > can get > > +using `reds_get_core_interface`. `reds_core_timer_*` and > > `reds_core_watch_*` > > +functions use the main core interface. > > > > +Even though multiple channel types run in the main thread and so could use > > +directly the main code interface, for coherence, rule simplicity and to > > allows > > +the code to be moved in a separate thread easily if needed, it's advisable > > to > > +use the channel core interface (that will be the main core interface in > > this > > +case). > > I'm not sure if this paragraph makes things clearer or more confusing > (because too many details). Maybe remove it? > I added just because you asked. I don't mind removing, if you could suggest something to replace even better. > > +Currently character devices and not channel code runs in the main thread. > > Is this here to mean character device code should be using reds_core_*? > Not necessarily, reds_core_* are mainly utilities for the main core, so if they are useful you can use them, or you can get the main core and use it instead. > Overall looks good to me. > > > OT: I though QEMU moved to GLib to handle events (so the main core > > interface > > was using GLib) but for performance
Re: [Spice-devel] [spice-common v3] log: Let gcc know about the logging macros which abort
>
> This commit adds a SPICE_UNREACHABLE macro (courtesy of Frediano)
> so that gcc does not think that code control can go past
> spice_return_{val_,}if_fail(), spice_critical() and spice_error()
>
> This avoids this kind of warnings:
>
> fallthrough.c:
>
> #include "log.h"
>
> int main(int argc, char **argv)
> {
> switch(argc) {
> case 1:
> spice_critical("foo");
>default:
> return 0;
> }
> }
>
> $ gcc -c$(pkg-config --cflags --libs glib-2.0 spice-protocol)
>-I common -Wimplicit-fallthrough=5 ./fallthrough.c
> In file included from ./fallthrough.c:1:
> ./fallthrough.c: In function 'main':
> common/log.h:73:5: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
>73 | spice_log(G_LOG_LEVEL_CRITICAL, SPICE_STRLOC, __FUNCTION__, ""
>format, ## __VA_ARGS__); \
> |
> ^~
> ./fallthrough.c:8:25: note: in expansion of macro 'spice_critical'
> 8 | spice_critical("foo");
> | ^~
> ./fallthrough.c:9:17: note: here
> 9 | default:
> | ^~~
>
> Signed-off-by: Christophe Fergeau
> ---
> Maybe a bit too much for a single commit, I can split :)
>
Acked-by: Frediano Ziglio
> common/log.h| 8 ++--
> common/macros.h | 8
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/common/log.h b/common/log.h
> index 7c67e7a..201c87a 100644
> --- a/common/log.h
> +++ b/common/log.h
> @@ -39,16 +39,18 @@ void spice_log(GLogLevelFlags log_level,
> const char *format,
> ...) G_GNUC_PRINTF(4, 5);
>
> +/* FIXME: name is misleading, this aborts.. */
> #define spice_return_if_fail(x) G_STMT_START { \
> if G_LIKELY(x) { } else { \
> -spice_log(G_LOG_LEVEL_CRITICAL, SPICE_STRLOC, G_STRFUNC, "condition
> `%s' failed", #x); \
> +spice_critical("condition `%s' failed", #x);\
> return; \
> } \
> } G_STMT_END
>
> +/* FIXME: name is misleading, this aborts.. */
> #define spice_return_val_if_fail(x, val) G_STMT_START { \
> if G_LIKELY(x) { } else { \
> -spice_log(G_LOG_LEVEL_CRITICAL, SPICE_STRLOC, __FUNCTION__,
> "condition `%s' failed", #x); \
> +spice_critical("condition `%s' failed", #x);\
> return (val); \
> } \
> } G_STMT_END
> @@ -71,10 +73,12 @@ void spice_log(GLogLevelFlags log_level,
>
> #define spice_critical(format, ...) G_STMT_START {
> \
> spice_log(G_LOG_LEVEL_CRITICAL, SPICE_STRLOC, __FUNCTION__, "" format,
> ## __VA_ARGS__); \
> +SPICE_UNREACHABLE;
> \
> } G_STMT_END
>
> #define spice_error(format, ...) G_STMT_START { \
> spice_log(G_LOG_LEVEL_ERROR, SPICE_STRLOC, __FUNCTION__, "" format, ##
> __VA_ARGS__); \
> +SPICE_UNREACHABLE;
> \
> } G_STMT_END
>
> #define spice_warn_if_fail(x) G_STMT_START {\
> diff --git a/common/macros.h b/common/macros.h
> index 2f24ada..92cd82c 100644
> --- a/common/macros.h
> +++ b/common/macros.h
> @@ -55,4 +55,12 @@
>
> #define SPICE_VERIFY(cond) verify_expr(cond, (void)1)
>
> +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5)
> +#define SPICE_UNREACHABLE __builtin_unreachable()
> +#elif defined(_MSC_VER)
> +#define SPICE_UNREACHABLE __assume(0)
> +#else
> +#define SPICE_UNREACHABLE for(;;) continue
> +#endif
> +
> #endif // H_SPICE_COMMON_MACROS
Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
