(32-bit, non-prefetchable) [size=4K]
Capabilities:
Kernel modules: parport_serial
The chip package reads:
Moschip MCS9901CV-CC
QK1W3-000
1102
FZC0AA095
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| R
fecta.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |__
ights v3.11-rc3 build.
It's been suggested perhaps:
http://www.spinics.net/lists/stable/msg16022.html
is the culprit, but I haven't tried it yet.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\
* Dr. David Alan Gilbert (d...@treblig.org) wrote:
> * Vern Clark (vmcl...@verizon.net) wrote:
> >
> > Plugging in any USB flash stick takes 5-6 minutes before its mounted.
> >
> > ===
> > Using the current kernel-3.8.0-28-generic, the USB fails to load in p
> address at any given time.
A compiler could decide to dereference it using a non-faulting load,
do the calculations or whatever on the returned value of the non-faulting
load, and then check whether the load actually faulted, and whether the
address matched the prediction before it did a st
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> On Sat, Aug 04, 2012 at 11:59:10PM +0100, Dr. David Alan Gilbert wrote:
> > A compiler could decide to dereference it using a non-faulting load,
> > do the calculations or whatever on the returned value of the non-faultin
ugh (unless it provided an index into your buffer?). So that
shouldn't break an existing libc, but a new one would have a chance
at a better errno.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert|
extension to the existing 32-bit ARM Architecture, it is a new (inspired
> by ARM) architecture. Implementations will also run in AArch32 state
> (A32 and T32), but it's not like x86->x86_64.
It's one advantage is that it won't trigger the infinite number
of brok
nly ever one process writing.
I'm open for all suggestions.
Dave
--
-----Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\
* Sander ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote (ao):
> > I was using rsync, but the problem with rsync is that I have
> > a back up server then filled with lots and lots of small files
> > - I want larger files for spooling to tape.
> > (Other sugg
your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.treblig.org |___/
-
To unsubscribe from this list: send the line "unsubscrib
sdf (which seems to be the slowest and fastest drives respectively).
I guess if everyone was running at sdf's speed you would be pretty happy.
If you physically swap f and g does the performance follow the drive
or the letter?
Dave
--
-Open up your eyes, open up your mind, open up your
run? I mean if I am the unlucky
admin who decides to setup a crypto/raid/stripe/thing setup
which runs out of stack somewhere how easy will it be
for someone who doesn't know the innards to know what
happened as opposed to running into a random oops?
Dave
--
-Open up your eyes, open up your
stating that the 3.xGB limit is a 32bit OS issue on these machines
and it'll all just work fine on 64bit OSs.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treb
y to be faster than old
> ISA, right?
In the opposite direction I'm sure I've heard of things that port 80
information down i2c - could this be slower?
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux o
make sense to differentiate that from a bug that is
just closed, just so people can know there is an issue with
a configuration.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.treblig.org |___/
-
To unsubscribe
* Lee Revell ([EMAIL PROTECTED]) wrote:
>
> Stupid question: what the heck does OO use DRI for? I googled and came
> up empty.
It does pointless 3D objects in its drawing package.
Dave
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Ala
Gilbert <[EMAIL PROTECTED]>
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.tre
ivers for
this type of thing public.
Of course the poster could just go and use one of the BSDs
which is probably his safest bet.
Dave
-Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ tre
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> > >> * Manipulating AppArmor policy requires being both root privileged
> >> and not being confined by AppArmor, thus there is expli
ments so that there is no way that a fault in parsing
external data could edit the config (e.g. change home page or
proxy in a browser or default document in an editor).
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >
> >> I don't get the problem: if you want your web browser to be able to
> >> access where you commonly store your documents,
says they want to store their
> documents in /etc?
I was assuming that in a system where the user can add stuff to
the profile the administrator would be able to either grant or exclude
paths that the user was able to add.
Dave
--
-Open up your eyes, open up your mind, open up your code
* J. Bruce Fields ([EMAIL PROTECTED]) wrote:
> On Sat, Aug 25, 2007 at 04:09:27PM +0100, Dr. David Alan Gilbert wrote:
> > This patch adds the address of the client that caused an
> > error in sunrpc/svc.c so that you get errors that look like:
> >
> > svc: 192.1
* J. Bruce Fields ([EMAIL PROTECTED]) wrote:
> On Tue, Aug 28, 2007 at 07:03:06PM +0100, Dr. David Alan Gilbert wrote:
> > I'm not going to be able to recut the patch until the weekend;
> > do you just want to remove the 'err' in your copy and feed this
> &g
FIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
--
-
* Trond Myklebust ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-08-06 at 11:01 -0700, Andrew Morton wrote:
> > On Mon, 6 Aug 2007 11:08:13 +0100 "Dr. David Alan Gilbert" <[EMAIL
> > PROTECTED]> wrote:
> >
> > > The oops below is from one of a pair of
s port back into a usable state in
> the forseeable future he should speak up now.
As was being discussed a few weeks ago; the drivers/acorn/block
should go at the same time since they are only in ARM 26 machines.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
(LVM), and encrypt hibernation.
But can you do what my original question was; find a way to lose a luks
encrypted device key and cleanly unmount the filesystem that was
using it? (and preferably put it all back together after resume).
Dave
--
-Open up your eyes, open up your mind, open up
st/mask
could cope with 90%+ of the cases.
There are probably lots of people reinventing the wheel for simple IO
boards and the hardware guys will be making it up each time as well.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert
er everything.
Dave
--
-----Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.treblig.o
there aren't such drives/controllers, but
> it just happen that I haven't seen any.)
Yes you have - the random writes with large blocks and 2 or 4 threads
is significantly better for your non-NCQ drive; and getting more
significant as you add more threads - I'm curious what happens
o
any references to *them* could
> also be deleted:
Ah those are blasts from the past; I've got to wonder how many
MFM drives that still work are out there.
I should take the 5.25" FH 64MB drive I tested that on to the tip
sometime.
Dave
--
-Open up your eyes, open up your mind, ope
plications using the luks device is.
2) Some level of debugging needs to be available so that users can
provide something so you can see why something hasn't hibernated
or why (as in the case of this tosh laptop) it still takes power
during hibernation.
Dave
--
-Open up
system 'forget' the keys when it does the
> hinbernate and prompt for it again during the wake-up phase.
Indeed - although as I say I really don't know what you would do with
apps using the mounts at that point. Still it seems like a
sensible requrest from the security sid
haviour was consistent accross
architectures.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\
rent architectures
not to mention kernel versions.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _
if (mlxcpld_led->profile[i].brightness)
> + mlxcpld_led_brightness(&cpld->pled[i].cdev,
> + mlxcpld_led->profile[i].brightness);
> + }
> +
> + return 0;
> +}
> +
> +static int __init mlxcpld_led_probe(struct platform_device *pdev)
> +{
> + enum mlxcpld_led_platform_types mlxcpld_led_plat =
> + mlxcpld_led_platform_check_sys_type();
> +
> + mlxcpld_led = devm_kzalloc(&pdev->dev, sizeof(*mlxcpld_led),
> +GFP_KERNEL);
> + if (!mlxcpld_led)
> + return -ENOMEM;
> +
> + mlxcpld_led->pdev = pdev;
> +
> + switch (mlxcpld_led_plat) {
> + case MLXCPLD_LED_PLATFORM_MSN2100:
> + mlxcpld_led->profile = mlxcpld_led_msn2100_profile;
> + mlxcpld_led->num_led_instances =
> + ARRAY_SIZE(mlxcpld_led_msn2100_profile);
> + break;
> +
> + default:
> + mlxcpld_led->profile = mlxcpld_led_default_profile;
> + mlxcpld_led->num_led_instances =
> + ARRAY_SIZE(mlxcpld_led_default_profile);
> + break;
> + }
> +
> + spin_lock_init(&mlxcpld_led->lock);
> +
> + return mlxcpld_led_config(&pdev->dev, mlxcpld_led);
> +}
> +
> +static struct platform_driver mlxcpld_led_driver = {
> + .driver = {
> + .name = KBUILD_MODNAME,
> + },
> +};
> +
> +static int __init mlxcpld_led_init(void)
> +{
> + struct platform_device *pdev;
> + int err;
> +
> + pdev = platform_device_register_simple(KBUILD_MODNAME, -1, NULL, 0);
> + if (!pdev) {
> + pr_err("Device allocation failed\n");
> + return -ENOMEM;
> + }
> +
> + err = platform_driver_probe(&mlxcpld_led_driver, mlxcpld_led_probe);
> + if (err) {
> + pr_err("Probe platform driver failed\n");
> + platform_device_unregister(pdev);
> + }
> +
> + return err;
> +}
> +
> +static void __exit mlxcpld_led_exit(void)
> +{
> + platform_device_unregister(mlxcpld_led->pdev);
> + platform_driver_unregister(&mlxcpld_led_driver);
> +}
> +
> +module_init(mlxcpld_led_init);
> +module_exit(mlxcpld_led_exit);
> +
> +MODULE_AUTHOR("Vadim Pasternak (vad...@mellanox.com)");
> +MODULE_DESCRIPTION("Mellanox board LED driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:leds_mlxcpld");
> --
> 2.1.4
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
kernel/git/andrea/aa.git
>
> #uname -a
> Linux 4.1.0-rc8+ #1 SMP Tue Aug 11 11:33:50 IST 2015 ppc64le ppc64le ppc64le
> GNU/Linux
>
> In fact I had successfully done postcopy migration of sPAPR guest with
> this setup.
Interesting - I'd not got that far myself on power; I was
testing mainline with the same setup to see if the selftest
> > passes.
>
> Ah, I just tried it on big endian and it works. So it seems to not work on
> little endian for some reason, /probably/ a test case bug?
Hmm; I think we're missing a test-case fix that Andrea made me for
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Tue, Sep 08, 2015 at 09:59:47AM +0100, Dr. David Alan Gilbert wrote:
> > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > > In fact I had successfully done postcopy migration of sPAPR guest with
> > > this
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Tue, Sep 08, 2015 at 01:46:52PM +0100, Dr. David Alan Gilbert wrote:
> > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > > On Tue, Sep 08, 2015 at 09:59:47AM +0100, Dr. David Alan Gilbert wrote:
> > &
hould be checking flags, but that's a separate story).
Dave
> Maybe that mystification comes from me missing something.
>
>Linus
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
at the guest keeps _ALL_
> sorts of mitigation mechanisms enabled and does not decide to disable
> retpolines because IBRS/IBPB are "available".
This is what's different with this set; it's all coming down to sets
of heuristics which include CPU model etc, rather than just a 'we've got
a feature, use it'.
Dave
> Good luck with making all that work.
>
> Thanks,
>
> tglx
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Borislav Petkov (b...@suse.de) wrote:
> On Wed, Jan 31, 2018 at 11:04:07AM +0000, Dr. David Alan Gilbert wrote:
> > That half is the easy bit, we've already got that (thanks to Eduardo),
> > QEMU has -IBRS variants of CPU types, so if you start a VM with
> > -cpu Broa
* Borislav Petkov (b...@suse.de) wrote:
> On Wed, Jan 31, 2018 at 12:30:36PM +0000, Dr. David Alan Gilbert wrote:
> > Indeed, it's only for this weird case where you suddenly need to change
> > it.
>
> No, there's more:
>
> .name = "Broadw
the host CPU model can change under
> your feet at any time. We force guest vendor == host vendor just
> because otherwise too much stuff breaks, but that's it.
In some ways we've been luckiest on x86; my understanding is ARM have a
similar set of architecture-specific errata and aren't really sure
how to expose this to guests either.
Dave
> Paolo
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
I was worried about (theoretically) whether
userspace in a guest could read privileged data from the guest kernel by
attacking the qemu process rather than by attacking the kernels.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
serialized? I'll have to do a rdmsr_safe() and only set the flag(s) if I
> > can successfully read the MSR back and validate the bit.
>
> If your hypervisor is lying to you about the primary family, then all
> bets are off. I don't expect there will be any production systems doing
> this.
It's not that an unusual thing to do on qemu/kvm - to specify the lowest
common denominator of the set of CPUs in your data centre (for any one
vendor); it does tend to get some weird combinations.
Dave
> The user can get to keep both pieces if they've decided that this was a
> good thing to try.
>
> ~Andrew
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
that starts off on an older host
and then gets live migrated to a new Skylake.
For Intel CPUs we've historically been safe to live migrate
to any newer host based on having all the features that the old one had;
with the guest still seeing the flags etc for the old CPU.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* David Hildenbrand (da...@redhat.com) wrote:
> On 10.12.18 18:12, Vivek Goyal wrote:
> > Instead of assuming we had the fixed bar for the cache, use the
> > value from the capabilities.
> >
> > Signed-off-by: Dr. David Alan Gilbert
> >
* David Hildenbrand (da...@redhat.com) wrote:
> On 13.12.18 10:13, Dr. David Alan Gilbert wrote:
> > * David Hildenbrand (da...@redhat.com) wrote:
> >> On 10.12.18 18:12, Vivek Goyal wrote:
> >>> Instead of assuming we had the fixed bar for the cache, use the
>
* David Hildenbrand (da...@redhat.com) wrote:
> On 13.12.18 11:00, Dr. David Alan Gilbert wrote:
> > * David Hildenbrand (da...@redhat.com) wrote:
> >> On 13.12.18 10:13, Dr. David Alan Gilbert wrote:
> >>> * David Hildenbrand (da...@redhat.com) wrote:
> >>
cache coherent,
Note that no real PCI infrastructure is involved - this is all emulated
devices, backed by mmap'd files on the host qemu process.
Dave
> what prevents these pages from
> being used in paths that would do:
>
>object = page_address(pfn_to_page(virtio_fs_pfn));
>
> ...?
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Vivek Goyal (vgo...@redhat.com) wrote:
> On Thu, Dec 13, 2018 at 03:40:52PM -0500, Vivek Goyal wrote:
> > On Thu, Dec 13, 2018 at 12:15:51PM -0800, Dan Williams wrote:
> > > On Thu, Dec 13, 2018 at 12:09 PM Dr. David Alan Gilbert
> > > wrote:
> > > &
t;
> > > > On 13.12.18 13:15, Dr. David Alan Gilbert wrote:
> > > > > * David Hildenbrand (da...@redhat.com) wrote:
> > > > >> On 13.12.18 11:00, Dr. David Alan Gilbert wrote:
> > > > >>> * David Hildenbrand (da...@re
:
>
> /proc/2821/net/dev_snmp6/eth0
>
> This looks exactly like something coming from userspace and making it
> into /proc, so the filter function doesn't belong to kernel/module/internal.h
You mean like:
[24180.292204] tuxthe: renamed from tuxthe🐧
root@dalek:/home/dg# ls /sys/class/net/
enp5s0 lo tuxthe tuxthe🐧 tuxthe🖊 virbr0 virbr1
?
Dave
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> Commit 8788ca164eb4b ("ftrace: Remove the legacy _ftrace_direct API")
> stopped setting the 'ftrace_direct_func_count' variable, but left
> it around. Clean it u
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> It doesn't look like this was ever used.
>
> Build tested only.
>
> Signed-off-by: Dr. David Alan Gilbert
Ping
> ---
> drivers/virt/acrn/irqfd.c | 2 --
> 1 f
* Fei Li (fei1...@intel.com) wrote:
> On 2024-05-18 at 00:12:46 +0000, Dr. David Alan Gilbert wrote:
> > * li...@treblig.org (li...@treblig.org) wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > It doesn't look like this was ever used.
* Li, Fei1 (fei1...@intel.com) wrote:
> > -Original Message-
> > From: Dr. David Alan Gilbert
> > Sent: Friday, July 19, 2024 1:44 AM
> > To: Li, Fei1
> > Cc: linux-kernel@vger.kernel.org; virtualizat...@lists.linux.dev
> > Subject: Re: [PA
ate according to the IA-32 ordering model.' which I think means
that all those loads are in order relative to all the other acquire
loads?
Dave
--
-----Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy
* Rafael J. Wysocki ([EMAIL PROTECTED]) wrote:
> On Sunday, 12 August 2007 01:43, Dr. David Alan Gilbert wrote:
> > * Pavel Machek ([EMAIL PROTECTED]) wrote:
> > > Hi!
> > >
> > > > > > Two things which I think would be nice to consider are:
> >
* Dr. David Alan Gilbert ([EMAIL PROTECTED]) wrote:
> * Trond Myklebust ([EMAIL PROTECTED]) wrote:
> > On Mon, 2007-08-06 at 11:01 -0700, Andrew Morton wrote:
> > > On Mon, 6 Aug 2007 11:08:13 +0100 "Dr. David Alan Gilbert" <[EMAIL
> > > PROTECTED]> wro
family but only currently
has IPV4; I wonder how many other places are similar.
Dave
Signed-off-by: Dave Gilbert <[EMAIL PROTECTED]>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.
le.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\
or VMs. I plan to implement shmem support
> in
> a follow-up patch series.
>
> Axel Rasmussen (2):
> userfaultfd: add minor fault registration mode
> userfaultfd: add UFFDIO_CONTINUE ioctl
>
> fs/proc/task_mmu.c | 1 +
> fs/userfaultfd.c
@@ struct uffdio_register {
> struct uffdio_range range;
> #define UFFDIO_REGISTER_MODE_MISSING ((__u64)1<<0)
> #define UFFDIO_REGISTER_MODE_WP ((__u64)1<<1)
> +#define UFFDIO_REGISTER_MODE_MINOR ((__u64)1<<2)
> __u64 mode;
>
> /*
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index a2602969873d..0ba8f2f5a4ae 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4377,6 +4377,37 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
> }
> }
>
> + /* Check for page in userfault range. */
> + if (!new_page && userfaultfd_minor(vma)) {
> + u32 hash;
> + struct vm_fault vmf = {
> + .vma = vma,
> + .address = haddr,
> + .flags = flags,
> + /*
> + * Hard to debug if it ends up being used by a callee
> + * that assumes something about the other uninitialized
> + * fields... same as in memory.c
> + */
> + };
> +
> + unlock_page(page);
> +
> + /*
> + * hugetlb_fault_mutex and i_mmap_rwsem must be dropped before
> + * handling userfault. Reacquire after handling fault to make
> + * calling code simpler.
> + */
> +
> + hash = hugetlb_fault_mutex_hash(mapping, idx);
> + mutex_unlock(&hugetlb_fault_mutex_table[hash]);
> + i_mmap_unlock_read(mapping);
> + ret = handle_userfault(&vmf, VM_UFFD_MINOR);
> + i_mmap_lock_read(mapping);
> + mutex_lock(&hugetlb_fault_mutex_table[hash]);
> + goto out;
> + }
> +
> /*
>* If we are going to COW a private mapping later, we examine the
>* pending reservations for this page now. This will ensure that
> --
> 2.29.2.729.g45daf8777d-goog
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Axel Rasmussen (axelrasmus...@google.com) wrote:
> On Mon, Jan 11, 2021 at 3:58 AM Dr. David Alan Gilbert
> wrote:
> >
> > * Axel Rasmussen (axelrasmus...@google.com) wrote:
> > > This feature allows userspace to intercept "minor" faults. By "minor&qu
ware equivalents.
Dave
> The part I'm unsure on is how easy it is for QEMU to deal with (3) without
> the overhead of bounce buffers. Ideally there'd already be a wrapper for
> guest memory accesses and that could just be wrapped with setting TCO during
> the access. I suspect the actual situation is more complex though, and I'm
> hoping Haibo's investigations will help us understand this.
>
> Thanks,
>
> Steve
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Mon, 7 Dec 2020 at 16:44, Dr. David Alan Gilbert
> wrote:
> > * Steven Price (steven.pr...@arm.com) wrote:
> > > Sorry, I know I simplified it rather by saying it's similar to protected
> > > VM.
> >
map the guest memory
> PROT_MTE unless somebody's done at least a sketch of the design
> for how this would work on the QEMU side. Currently QEMU just
> assumes the guest memory is guest memory and it can access it
> without special precautions...
Although that is also changing
136] page_enc_status_hc invoked, gpa = 1f007000, npages = 1, enc =
> 1
> [ 56.197148] page_enc_status_hc invoked, gpa = 1f005000, npages = 1, enc =
> 1
> [ 56.222679] page_enc_status_hc invoked, gpa = 1e83b000, npages = 1, enc = > 0
> [ 56.222691] page_enc_status_hc invoked, gpa = 1e839000, npages = 1, enc = > 0
> [ 56.222707] page_enc_status_hc invoked, gpa = 1e83b000, npages = 1, enc =
> 1
> [ 56.222720] page_enc_status_hc invoked, gpa = 1e839000, npages = 1, enc =
> 1
> [ 56.313747] page_enc_status_hc invoked, gpa = 1e5eb000, npages = 1, enc = > 0
> [ 56.313771] page_enc_status_hc invoked, gpa = 1e5e9000, npages = 1, enc = > 0
> [ 56.313789] page_enc_status_hc invoked, gpa = 1e5eb000, npages = 1, enc =
> 1
> [ 56.313803] page_enc_status_hc invoked, gpa = 1e5e9000, npages = 1, enc =
> 1
> [ 56.459276] page_enc_status_hc invoked, gpa = 1d767000, npages = 100, enc
> = 0
> [ 56.459428] page_enc_status_hc invoked, gpa = 1e501000, npages = 1, enc =
> 1
> [ 56.460037] page_enc_status_hc invoked, gpa = 1d767000, npages = 100, enc
> = 1
> [ 56.460216] page_enc_status_hc invoked, gpa = 1e501000, npages = 1, enc = > 0
> [ 56.460299] page_enc_status_hc invoked, gpa = 1d767000, npages = 100, enc
> = 0
> [ 56.460448] page_enc_status_hc invoked, gpa = 1e501000, npages = 1, enc =
> 1
> As can be observed here, all guest MMIO ranges are initially setup as
> shared, and those are all contigious guest page ranges.
>
> After that the encryption status hypercalls are invoked when DMA gets
> triggered during disk i/o while booting the guest ... here again the
> guest page ranges are contigious, though mostly single page is touched
> and a lot of page re-use is observed.
>
> So a range-based list/structure will be a "good" fit for such usage
> scenarios.
It seems surprisingly common to flick the same pages back and forth between
encrypted and clear for quite a while; why is this?
Dave
> Thanks,
> Ashish
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Kalra, Ashish (ashish.ka...@amd.com) wrote:
> Hello Dave,
>
> On Dec 18, 2020, at 1:40 PM, Dr. David Alan Gilbert
> wrote:
>
> * Ashish Kalra (ashish.ka...@amd.com) wrote:
> On Fri, Dec 11, 2020 at 10:55:42PM +, Ashish Kalra wrote:
> Hello All,
>
> On T
ret = 0;
> break;
> + case KVM_HC_PAGE_ENC_STATUS:
> + ret = -KVM_ENOSYS;
> + if (kvm_x86_ops.page_enc_status_hc)
> + ret = kvm_x86_ops.page_enc_status_hc(vcpu->kvm,
> + a0, a1, a2);
> + break;
> default:
> ret = -KVM_ENOSYS;
> break;
> diff --git a/include/uapi/linux/kvm_para.h b/include/uapi/linux/kvm_para.h
> index 8b86609849b9..847b83b75dc8 100644
> --- a/include/uapi/linux/kvm_para.h
> +++ b/include/uapi/linux/kvm_para.h
> @@ -29,6 +29,7 @@
> #define KVM_HC_CLOCK_PAIRING 9
> #define KVM_HC_SEND_IPI 10
> #define KVM_HC_SCHED_YIELD 11
> +#define KVM_HC_PAGE_ENC_STATUS 12
>
> /*
> * hypercalls use architecture specific
> --
> 2.17.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
again if INVPCID interception if required */
> svm_check_invpcid(svm);
>
> + if (nested && guest_cpuid_has(vcpu, X86_FEATURE_SVM)) {
> + best = kvm_find_cpuid_entry(vcpu, 0x800A, 0);
> + best->edx |= (1 << 28);
> + }
> +
mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
--
To unsubscribe from this list: send the line "
force contiguity'
seem to stop the GPF's/crashes, although there's still something else
going on with a corruption I'm seeing every so often.
Dave
--
-----Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux
* Dr. David Alan Gilbert (d...@treblig.org) wrote:
> * Marcin Gibula (m.gib...@gmail.com) wrote:
>
> Hi Marcin,
>
> > Hi,
> >
> > I've been playing with 3.16 kernel on my test machine as a KVM
> > hypervisor and encountered the following cra
egister into the same range, I
> > wouldn't even know who to deliver the userfault to. It is an erratic
> > behavior. Currently it'd return -EBUSY if the app has a bug and does
> > that, but maybe later this can be relaxed to allow higher
> > scalability with
ither
1) get caught by userfault etc or
2) must succeed in it's access
and we'll have that happening somewhere between thousands and millions of times
to pages in no particular order, so we need to avoid creating millions of
mappings.
Dave
>
> Linus
--
Dr.
emory.
Aren't DONTNEED and DONTDUMP similar cases of madvise operations that are
expected to do what they say ?
> I would suggest to consider to use some other interface for the
> functionality: a new syscall or, perhaps, mprotect().
Dave
> --
> Kirill A. Shutemov
--
Dr. David
* Kirill A. Shutemov (kir...@shutemov.name) wrote:
> On Tue, Oct 07, 2014 at 11:46:04AM +0100, Dr. David Alan Gilbert wrote:
> > * Kirill A. Shutemov (kir...@shutemov.name) wrote:
> > > On Fri, Oct 03, 2014 at 07:07:58PM +0200, Andrea Arcangeli wrote:
> > > > MADV_U
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> Il 07/10/2014 19:07, Dr. David Alan Gilbert ha scritto:
> >> >
> >> > So I'd *much* rather have a "write()" style interface (ie _copying_
> >> > bytes from user space into a newly allocated p
lt is less general.
Dave
> remapping anonymous pages involves page table games that really aren't
> necessarily a good idea, and tlb invalidates for the old page etc.
> Just don't do it.
>
>Linus
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manche
's got a good self test, that's survived heavy testing.
e) I think Andrea has addressed all previous comments on it.
Dave
>
> Thanks,
>
> Ingo
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
To unsubscribe from this list: send the line &qu
* Marc Haber (mh+linux-ker...@zugschlus.de) wrote:
> Hi David,
>
> On Sat, Apr 23, 2016 at 07:52:46PM +0100, Dr. David Alan Gilbert wrote:
> > Hmm, your problem does sound like bad hardware, but
> > If you've got a nice reliable crash, can you try turning transpare
. Then we can look at ways
> to quiesce device faster which really means step 5 is replaced
> with "host tells guest to quiesce device and dirty (or just unmap!)
> all memory mapped for write by device".
Doing a hot-unplug is going to upset the guests network sta
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Tue, Jan 05, 2016 at 10:01:04AM +0000, Dr. David Alan Gilbert wrote:
> > * Michael S. Tsirkin (m...@redhat.com) wrote:
> > > On Mon, Jan 04, 2016 at 07:11:25PM -0800, Alexander Duyck wrote:
> > > > >> The t
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Tue, Jan 05, 2016 at 10:45:25AM +0000, Dr. David Alan Gilbert wrote:
> > * Michael S. Tsirkin (m...@redhat.com) wrote:
> > > On Tue, Jan 05, 2016 at 10:01:04AM +0000, Dr. David Alan Gilbert wrote:
> > > > * Micha
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Tue, Jan 05, 2016 at 10:45:25AM +0000, Dr. David Alan Gilbert wrote:
> > * Michael S. Tsirkin (m...@redhat.com) wrote:
> > > On Tue, Jan 05, 2016 at 10:01:04AM +0000, Dr. David Alan Gilbert wrote:
> > > > * Micha
ubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majord...@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> To
ese
> pages MADV_DONTNEED or MADV_FREE.
> Otherwise it's all too tied up to a specific usecase -
> you aren't telling host that a page is free, you are telling it
> that a page was free in the past.
But doing it under lock sounds pretty expensive, especially given
how long the userspace side is going to take to work through the bitmap
and device what to do.
Dave
>
> --
> MST
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
for the guest
to update it's bitmap; HPe's solution is to migrate it's balloon
bitmap along with the migration data.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Li, Liang Z (liang.z...@intel.com) wrote:
> > On Mon, Mar 14, 2016 at 05:03:34PM +0000, Dr. David Alan Gilbert wrote:
> > > * Li, Liang Z (liang.z...@intel.com) wrote:
> > > > >
> > > > > Hi,
> > > > > I'm just catching back up
t;
> --
> -------------
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
n in this context? This seems to imply some kind of
> security concern. Is guest likely to need all of its memory or a
> specific portion of it? Is it likely to be a static configuration or a
> dynamic one? If dynamic, does guest also want to avoid deflating the
> balloon or only inflating it?
The semantics we want here are subtly different from ballooning;
a) In ballooning the host is asking for the guest to give up some ram;
that's not quite the case here - although if the guest dropped some
caches that *might* be helpful.
b) In ballooning we're interested in just amounts of free memory; here
we care about _which_ pages are free.
c) We don't want to make it hard for the guest to start using some of the
memory again; if it was hard then we suddenly get back into a balancing
act of needing to quantatively talk about how much free RAM we have,
and worry about whether we shouldn't tell the host about a small pot
we keep back etc.
Dave
> --
> MST
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
ly thing that can stall a kernel thread when accessing a memory location,
it's one of the few that never needs priviledge.
Add a flag, allowing userfaultfd to be restricted, so that in general
it won't be useable by arbitrary user programs, but in environments that
require userf
* Liu Bo (obuil.li...@gmail.com) wrote:
> On Mon, Dec 10, 2018 at 9:57 AM Vivek Goyal wrote:
> >
> > Instead of assuming we had the fixed bar for the cache, use the
> > value from the capabilities.
> >
> > Signed-off-by: Dr. David Alan Gilbert
>
1 - 100 of 134 matches
Mail list logo
