search for: is_private

This patch enables PCI passthrough with stub domain. PCI passthrough with stub domain has failed in the past. The primary reason is that hypercalls from qemu in stub domain are rejected. This patch allows qemu in stub domain to call the hypercalls which is needed for PCI passthrough. For security, if target domain of hypercall is different from that of stub domain, it rejects hypercall. To use

These two patches were originally part of the XSM series that I have posted, and remain prerequisites for that series. However, they are independent of the XSM changes and are a useful simplification regardless of the use of XSM. The Acked-bys on these patches were provided before rebasing them over the copyback changes in 26268:1b72138bddda, which had minor conflicts that I resolved. [PATCH

These two patches provide the neccessary infrastructure changes for the processor-passthru driver [www.spinics.net/lists/linux-acpi/msg34655.html] to properly function. The first one is quite easy - we just modprobe the processor-passthru driver. The second allows it to work under AMD machines by exposing the PM RDMSR to dom0. It has been tested with 2.6.32 kernel as well to make sure it does

With the traditional qemu tree fixed to not use PROT_WRITE anymore in the mmap() call for this region, and with the upstream qemu tree not being capable of handling passthrough, yet, there''s no need to treat Dom specially here anymore. This continues to leave unaddressed the case where PV guests map the MSI-X table page(s) before setting up the first MSI-X interrupt (see the original c/s

...stfs.pc diff --git a/generator/c.ml b/generator/c.ml index f0df5ea..4497c48 100644 --- a/generator/c.ml +++ b/generator/c.ml @@ -39,7 +39,13 @@ let is_public { visibility = v } = match v with | VPublic | VPublicNoFish | VStateTest | VDebug -> true | VBindTest | VInternal -> false -let is_private f = not (is_public f) +let is_private { visibility = v } = match v with + | VBindTest -> true + | VPublic | VPublicNoFish | VStateTest | VDebug | VInternal -> false + +let is_internal { visibility = v } = match v with + | VInternal -> true + | VPublic | VPublicNoFish | VStateTest | VDe...

Move the generate_all_structs and generate_all_headers functions, previously internal within the implementation of generate_guestfs_h, to be usable by other functions in the same "C" module (but not public). Only code motion. --- generator/c.ml | 163 +++++++++++++++++++++++++++++---------------------------- 1 file changed, 82 insertions(+), 81 deletions(-) diff --git a/generator/c.ml

...anged, 18 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/xattr_security.c b/fs/reiserfs/xattr_security.c index 41c0ea84fbf..6bffdf9a4fd 100644 --- a/fs/reiserfs/xattr_security.c +++ b/fs/reiserfs/xattr_security.c @@ -39,6 +39,22 @@ static bool security_list(struct dentry *dentry) return !IS_PRIVATE(d_inode(dentry)); } +static int +reiserfs_initxattrs(struct inode *inode, const struct xattr *xattr_array, + void *fs_info) +{ + struct reiserfs_security_handle *sec = fs_info; + + sec->value = kmemdup(xattr_array->value, xattr_array->value_len, + GFP_KERNEL); + if (!sec-&gt...

This is a fourth cut of the hypervisor patch of the proposed XENMEM_claim_pages hypercall/subop, taking into account feedback from Jan and Keir and IanC, plus some fixes found via runtime debugging (using privcmd only) and some added comments/cleanup. [Logistical note: I will be out tomorrow (Friday) plus US holidays next week so my responsiveness to comments may be slower for awhile. --djm]

Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-09-19/xen/arch/x86/platform_hypercall.c =================================================================== --- 2008-09-19.orig/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:02.000000000 +0200 +++ 2008-09-19/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:56.000000000 +0200 @@ -21,7 +21,7 @@ #include <xen/acpi.h>

Good day - This is my first post to this list , and I''m new to Xen - any help on this issue would be much appreciated . I downloaded, built and installed xen-4.2.1 (hypervisor and tools) on an x86_64 ArchLinux box updated to latest software as of today. I am trying to bring up a Linux guest from a remote iSCSI disk. The iSCSI-initiator (open-iscsi) logs in to the remote target OK and

@@ -491,16 +512,15 @@ int pirq_guest_bind(struct vcpu *v, int int rc = 0; cpumask_t cpumask = CPU_MASK_NONE; + WARN_ON(!spin_is_locked(&v->domain->evtchn_lock)); I find this WARN_ON() is triggered harmlessly when I assign device to HVM guest. The call trace is XEN_DOMCTL_bind_pt_irq -> pt_irq_create_bind_vtd() -> pirq_guest_bind(). Should we

Linux 2.6.19 (x86-64) makes use of this feature if available, but Xen (validly) fails the attempt to write the respective MSR. Hence the feature must be hidden from PV guests. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-01-16/xen/arch/x86/traps.c =================================================================== --- 2007-01-16.orig/xen/arch/x86/traps.c 2007-01-15

The IRQ handling code requires pcidevs_lock to be held only for MSI interrupts. As the handling of which was now fully moved into msi.c (i.e. while applying fine without, the patch needs to be applied after the one titled "x86: split MSI IRQ chip"), io_apic.c now also doesn''t need to include PCI headers anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> ---

...@@ -1132,17 +1132,6 @@ int security_inode_init_security_anon(struct inode *inode, context_inode); } -int security_old_inode_init_security(struct inode *inode, struct inode *dir, - const struct qstr *qstr, const char **name, - void **value, size_t *len) -{ - if (unlikely(IS_PRIVATE(inode))) - return -EOPNOTSUPP; - return call_int_hook(inode_init_security, -EOPNOTSUPP, inode, dir, - qstr, name, value, len); -} -EXPORT_SYMBOL(security_old_inode_init_security); - #ifdef CONFIG_SECURITY_PATH int security_path_mknod(const struct path *dir, struct dentry *dentry, umode_t...

...@@ -1655,17 +1655,6 @@ int security_inode_init_security_anon(struct inode *inode, context_inode); } -int security_old_inode_init_security(struct inode *inode, struct inode *dir, - const struct qstr *qstr, const char **name, - void **value, size_t *len) -{ - if (unlikely(IS_PRIVATE(inode))) - return -EOPNOTSUPP; - return call_int_hook(inode_init_security, -EOPNOTSUPP, inode, dir, - qstr, name, value, len); -} -EXPORT_SYMBOL(security_old_inode_init_security); - #ifdef CONFIG_SECURITY_PATH /** * security_path_mknod() - Check if creating a special file is allowed --...

...ml) --username , -u specify username, taken from config otherwise --password , -p specify password, taken from config otherwise --cookie_jar , -C specify cookie storage file (default /home/ahoward/.rubyforge/cookie.dat) add_release : --is_private , -P if true, release is not public --release_date , -r specify time of release (default ''now'') --type_id , -t specify filetype code (default determined by ext) --processor_id , -o specify processor (default ''A...

...et; > > > > + struct security_hook_list *P; > > > > + struct xattr *new_xattrs; > > > > + struct xattr *xattr; > > > > + int ret = -EOPNOTSUPP, num_filled_xattrs = 0; > > > > > > > > if (unlikely(IS_PRIVATE(inode))) > > > > return 0; > > > > > > > > + if (!blob_sizes.lbs_xattr) > > > > + return 0; > > > > + > > > > if (!initxattrs) > > > > return call_int_hook...

...struct security_hook_list *P; > > > > > + struct xattr *new_xattrs; > > > > > + struct xattr *xattr; > > > > > + int ret = -EOPNOTSUPP, num_filled_xattrs = 0; > > > > > > > > > > if (unlikely(IS_PRIVATE(inode))) > > > > > return 0; > > > > > > > > > > + if (!blob_sizes.lbs_xattr) > > > > > + return 0; > > > > > + > > > > > if (!initxattrs) > > > > >...

...; > > > - int ret; > > > + struct security_hook_list *P; > > > + struct xattr *new_xattrs; > > > + struct xattr *xattr; > > > + int ret = -EOPNOTSUPP, num_filled_xattrs = 0; > > > > > > if (unlikely(IS_PRIVATE(inode))) > > > return 0; > > > > > > + if (!blob_sizes.lbs_xattr) > > > + return 0; > > > + > > > if (!initxattrs) > > > return call_int_hook(inode_init_security, -EOPNOTSUPP,...

From: Roberto Sassu <roberto.sassu at huawei.com> One of the major goals of LSM stacking is to run multiple LSMs side by side without interfering with each other. The ultimate decision will depend on individual LSM decision. Several changes need to be made to the LSM infrastructure to be able to support that. This patch set tackles one of them: gives to each LSM the ability to specify one