search for: set_bits

Hi, testing for bounce mails. suddenly xen-devel started bouncing my mails back saying somebody forged by email to them ... :-( uh... if anybody gets this , please hit a reply privately. Thanks a ton ~psr -- --- pradeep singh rautela "Genius is 1% inspiration, and 99% perspiration" - not me :) _______________________________________________ Xen-devel mailing list

From: Matt Fleming <matt.fleming at linux.intel.com> Partially revert "com32: add a centralized bitops header" This reverts part of commit db74cf6c4182f40ecf7fad1f04799d09d82f896d. The usage of the centralized bitops in com32/lib/vsscanf.c is not correct because the bitmap that we're accessing is too large for the 'bt', 'bts' and 'btc' instructions to

The "APIC-register virtualization" and "virtual-interrupt deliver" VM-execution control has no effect on the behavior of RDMSR/WRMSR if the "virtualize x2APIC mode" VM-execution control is 0. When guest uses x2APIC mode, we should enable "virtualize x2APIC mode" for APICV first. Signed-off-by: Jiongxi Li <jiongxi.li@intel.com> diff --git

>From /xen-unstable.hg/xen/arch/x86/cpu/intel.c if ((c->x86 == 0xf && c->x86_model >= 0x03) || (c->x86 == 0x6 && c->x86_model >= 0x0e)) set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); if (cpuid_edx(0x80000007) & (1u<<8)) { set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); set_bit(X86_FEATURE_NONSTOP_TSC,

...calling cleanup routines 27 8512519 [main] rsync 5052 socket_cleanup: si 0x773B38 si->thread 0x6114E700 163 8512682 [main] rsync 5052 socket_cleanup: returning 31 8512713 [main] rsync 5052 peek_socket: read_ready: 0, write_ready: 1, except_ready: 0 26 8512739 [main] rsync 5052 set_bits: me 0x773B08, testing fd 4 () 29 8512768 [main] rsync 5052 set_bits: ready 1 26 8512794 [main] rsync 5052 select_stuff::poll: returning 1 26 8512820 [main] rsync 5052 select_stuff::cleanup: calling cleanup routines 27 8512847 [main] rsync 5052 select_stuff::~select_stuff: deleting...

> + vpmem->vdev = vdev; > + vdev->priv = vpmem; > + err = init_vq(vpmem); > + if (err) { > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n"); > + goto out_err; > + } > + > + virtio_cread(vpmem->vdev, struct virtio_pmem_config, > + start, &vpmem->start); > + virtio_cread(vpmem->vdev, struct

> + vpmem->vdev = vdev; > + vdev->priv = vpmem; > + err = init_vq(vpmem); > + if (err) { > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n"); > + goto out_err; > + } > + > + virtio_cread(vpmem->vdev, struct virtio_pmem_config, > + start, &vpmem->start); > + virtio_cread(vpmem->vdev, struct

Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI names. This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the range FIRST-LAST_HIPRIORITY_VECTORs are free once again. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 +++

These commands can be used by the introspection tool to check what introspection commands and events are supported (by KVMi) and allowed (by userspace). The introspection tool will get one of the following error codes: * -KVM_ENOSYS (unsupported command/event) * -KVM_PERM (disallowed command/event) * -KVM_EINVAL (the padding space, used for future extensions, is not zero)

I am getting cc1: warnings being treated as errors strspn.c: In function 'strxspn': strspn.c:14:20: error: inlining failed in call to 'set_bit': optimizing for size and code size would grow strspn.c:32:9: error: called from here strspn.c:14:20: error: inlining failed in call to 'set_bit': optimizing for size and code size would grow strspn.c:36:9: error: called from here

This allows the called fdb_create to detect that the entry was added by the user early in the process. This is in preparation to adding limits in fdb_create that should not apply to user created fdb entries. Signed-off-by: Johannes Nixdorf <jnixdorf-oss at avm.de> --- Changes since v1: - Added this change to ensure user added entries are not limited. net/bridge/br_fdb.c | 6 +++--- 1

....h> #include<errno.h> #include<stdlib.h> #include<unistd.h> #include<stdio.h> #include<signal.h> #include "lpswitch.h" /* Main program. */ int main(int argc, char **argv) { struct termios port_config; int fd; int set_bits = 2; /* Open monitor device. */ if ((fd = open(SWDEV, O_RDWR | O_NDELAY))< 0) { fprintf(stderr, "lpswtich: %s: %d\n", SWDEV, strerror(errno)); exit(1);} cfmakeraw(&port_config ); port_config.c_iflag=port_config.c_iflag|IXON; port_config.c_o...

From: Nicu?or C??u <ncitu at bitdefender.com> This event is sent after each instruction when the singlestep has been enabled for a vCPU. Signed-off-by: Nicu?or C??u <ncitu at bitdefender.com> Co-developed-by: Adalbert Laz?r <alazar at bitdefender.com> Signed-off-by: Adalbert Laz?r <alazar at bitdefender.com> --- Documentation/virt/kvm/kvmi.rst | 31

A malicious actor behind one bridge port may spam the kernel with packets with a random source MAC address, each of which will create an FDB entry, each of which is a dynamic allocation in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big.

From: Nicu?or C??u <ncitu at bitdefender.com> This is a preparatory patch in order to use a common interface to enable/disable the MSR interception. Signed-off-by: Nicu?or C??u <ncitu at bitdefender.com> Signed-off-by: Adalbert Laz?r <alazar at bitdefender.com> --- arch/x86/include/asm/kvm_host.h | 4 +++ arch/x86/kvm/svm/svm.c | 43 ++++++++++++++++++++++-----------

From: Nicu?or C??u <ncitu at bitdefender.com> These changes prepare the patch that adds .control_msr_intercept(). Signed-off-by: Nicu?or C??u <ncitu at bitdefender.com> Signed-off-by: Adalbert Laz?r <alazar at bitdefender.com> --- arch/x86/include/asm/kvm_host.h | 4 ++++ arch/x86/kvm/svm.c | 42 ++++++++++++++++++++++----------- arch/x86/kvm/vmx/vmx.h |

From: Mihai Don?u <mdontu at bitdefender.com> This command is used to enable/disable introspection for a specific MSR. The KVMI_EVENT_MSR event is sent when the tracked MSR is going to be changed. The introspection tool can respond by allowing the guest to continue with normal execution or by discarding the change. This is meant to prevent malicious changes to MSRs such as

These are known to not support the feature, so we can save ourselves from emitting the resulting #GP fault recovery related message (which might worry people looking at the logs). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -204,7 +204,7 @@ static void __devinit init_intel(struct detect_ht(c); } - if

Well, I regret I mentioned the lack of barrier after enter_slowpath ;) On 02/15, Raghavendra K T wrote: > > @@ -46,7 +46,8 @@ static __always_inline bool static_key_false(struct static_key *key); > > static inline void __ticket_enter_slowpath(arch_spinlock_t *lock) > { > - set_bit(0, (volatile unsigned long *)&lock->tickets.tail); > + set_bit(0, (volatile unsigned

Well, I regret I mentioned the lack of barrier after enter_slowpath ;) On 02/15, Raghavendra K T wrote: > > @@ -46,7 +46,8 @@ static __always_inline bool static_key_false(struct static_key *key); > > static inline void __ticket_enter_slowpath(arch_spinlock_t *lock) > { > - set_bit(0, (volatile unsigned long *)&lock->tickets.tail); > + set_bit(0, (volatile unsigned