 All right, good morning, everybody. So today we're just going to do a little bit more of the semester, almost to the end. But I want to talk today and potentially a little bit Monday morning about virtualization, because it's kind of like the trap door at the end of the class that leads some of you in kind of a new direction, because this is cool. And to some degree, I mean, this is a little bit more modern than some of the classical operating systems material that we've been talking about so far. So we'll see how far we get today, and then probably wrap up this on Monday morning before we do some exam review. And as a reminder, so on Monday we will meet at 8 AM. We will finish virtualization or the material I want to get through, and then we'll do some exam review. So there's a practice exam that's been posted. That's not a practice, it's the exam from last year. And that's what we'll go through on Monday together. So if you have some time beforehand, take a look at that, both the exam and the solutions are online, and that will give you a sense of how this year's exam will look. And the exam will cover everything we get through Monday. Last year, I didn't tape the exam review this year because I'm going to do some material while I tape it. So that'll be online as well. Just in case, you don't get here at 8 AM. But it's good practice, because if you don't get here at 8 AM a week from Monday, you'll be sad. All right, so the response rate on the course feedback forum jumped quite dramatically overnight, but it's still not over 70%. So you guys are still, it's about 50% right now. So if you keep going at that rate, then it will be like 200% in a couple of days. But yeah, so the incentives are outlined on the website. 70% gets you a medium answer question. What did I say? 70% gives you a short answer question, sorry. Don't refer to me, refer to the website, because the website is great. So 70 is short answer, 80 is medium answer, and the 90% the gold standard would be a long answer question. And yeah, Paul. Yep, these are cumulative, right? So you could potentially expose yourself to a great deal of the exam before you. OK, so, any questions? So last time we finished talking about the last step of performance improvement, which was actually what to do. So any questions about this before we just do a little bit of review? I just want to cover the high points. I know we talked about performance for a while. May have started to all blend together. So the first thing we had to do was measure our system. That was the first step in the process of doing performance analysis. What other choices do we have to make at this point? We're starting the process of performance improvement. And we want to take some measurements, we want to use those measurements to decide what to do, what were some of the challenges or some of the decisions we had to make at this stage. Mukta, do you remember any of the things we talked about when we started talking about measurement? Govina, you want to help us? Yeah, so we decide kind of like what are we going to actually measure, right? We're going to try to measure the real system, or are we going to try to produce an analytical model for the system that we can use to make predictions, or are we going to build a simulator, right? And then we needed to figure out what the system is going to be doing while we measured it, right? So decide what benchmarks we're going to run. And then also what instrumentation are we going to use to actually take the measurements, right? What was the next step? After we take measurements, what do we do next? Yeah, so I'm going to actually analyze the results, right? And what were some of the challenges here, Paul? Yeah, so this is where we ended up maybe being challenged by our relationship with statistics or lack thereof, right? And we needed to make sure that we used the appropriate statistics techniques and be careful of summarizing the data too soon and also really try to understand the outliers in your data, right? Don't try to make them go away. Make sure you understand what they are. And then Robert, what was the next step? Yeah, so actually we're going to do something now, right? So we're going to improve the slow parts of the system. Or really what we're going to try to do is improve the overall system, right? So we talked about something that's how improving the slowest parts may not even really be the right thing to do, right? What were some of the other challenges here, Dan? Yeah, so there's a couple of things all mixed in there, right? So I may not be able to improve the performance of a particular part of the system. It may be very difficult, right? And the longer I work on a part of the system, the less likely it is to be the problem, right? So that was kind of our last serving of Amdahl's Law, right? So who can give me the least colloquial version of Amdahl's Law that we presented, Sam? No, the most computer science. The least colloquial. Yeah, so that's kind of my Amdahl's Law corollary. That's what Dan got at. Someone else want to, it includes the word, try to think what it actually is. Bounded, maybe? Sarah, I want to try and answer with bounded. Look at that energy drink sitting right there. That Kickstarter is not. You still want to draw something there. Yeah, I know, I know. You can cheat, right? The impact of any constrain, sorry, I didn't include the word bounded, so I fed you a red herring. The impact of any effort to improve system performance is constrained by the performance of the parts of the system not targeted by the improvement, right? You can only make a system faster to the degree that the parts that you're not working on are still there and still going to be part of the problem, right? And this was kind of like the how to explain it to your statistically challenged boss, right? I'm going to work on the part of the system that's hurting us, right? I'm going to find the part of the system that's hurting us and that's what I'm going to improve. And then as both Daniel and Sam pointed out, the more you improve one part of your system, the more time you invest in a certain aspect of system performance, the less likely it is that that performance is your problem. So this argues for sort of a continual reevaluation. Don't get stuck down there in the last part. I mean, that's the fun part, right? I mean, to some degree, the computer scientists, like the fun part is the hacking part. So there's this tendency to think, oh, wow, I found the problem and then you work on it for six months, right? But in the meantime, A, maybe things have changed and B, now you've got other problems to work on. All right, any questions about this before we talk about virtualization? All right. So virtualization is, to some degree, some of my thematic thinking about this class, at least last year had the matrix in mind, right? Some of the old assignments on the old website had like little matrix quotes on them, right? Because I think there's something matrix-esque about operating systems, right? I mean, as an application programmer, you've been exposed to these illusions, right? And this is not the way the real world is. And so you go through this process, you take the red pill, you pop out down in the operating system and you realize that memory is not contiguous and there isn't an infinite amount of it and the machinists aren't actually doing 16 things at once. And so that's kind of fun, right? Virtualization, I mean, if you want to continue to extend that metaphor, virtualization is like, how many people have seen the matrix movies? Oh, thank God. OK, good. Because they're good and also because we have something in common, you and I. So the virtualization is like the point in that movie, I don't know, it's like in the third movie when the architect explains to Neo that this is like what, the third or fourth time that Zion has been destroyed, right? And suddenly he realizes that there's this whole other lack of reality to his own world, right? There's this whole thing that he hasn't even noticed that he thought he knew the truth, right? But now there's someone who's presented him with the bigger truth of which he's only a part, right? So up until this point, we've been talking about operating systems that run on real physical machines, right? And the thing is that this is less and less common, right? I mean, it's still common to some degree. I mean, most people here are still running an operating system that runs on a real physical machine, right? But increasingly, what we've seen, especially with the move to sort of cloud computing and commuting as a service and commodity computing is this idea that what we do is we know how many people have used EC2, right? How many people have done assignments for this class, right? So you guys have, I hope everyone's hand goes up, you guys have used virtualization technologies, right? And we'll talk a little bit about today about some of the problems with the operating system that the virtualization is intended to get around. But a lot of the computing resources you use today are increasingly not run on bare metal, right? They are run inside what's called a virtual machine monitor, right? And they're run inside what's called a virtual machine. And a virtual machine is really kind of exactly what we think about. Actually, this is just some terminology, so let's get through this. When we start talking about virtual machines, we start having to distinguish between different operating systems, because there's an operating system that is potentially operating the physical machine, and then there's an operating system that is running inside the virtual machine. So we usually call the operating system that runs inside the virtual machine the guest OS, right? What do we call the operating system that runs the physical machine? Yeah, Jeff? The host OS, right? So if you guys have been googling around on virtual box forms when you've run into problems, you may see answers where people identify like I'm running a Ubuntu guest on a Windows 7 host, right? Or I'm running a Windows 7 guest on a Ubuntu host or whatever, right? So we start to have to distinguish between the operating system that's running on this virtual hardware and the operating system that's actually managing the physical hardware, right? And really, virtual machines is a term that we've heard a lot, but when I started thinking about this, it really struck me. It's very apt, right? So what we're really trying to do here is trying to virtualize hardware, right? And virtual machines are designed to differ from physical machines in some important ways in order to allow an operating system. So the goal here is really to allow the guest OS to think that it is running on real hardware, on a sort of classically virtualized system. What we want is for the guest operating system to not know that, unbeknownst to it, there's this other operating system or many other operating systems that are sharing the same physical machine. Why is this hard? You have to go back to the very beginning of the semester, I mean, why is this difficult to do with operating systems on or on? Well, that's how we do it, right? But what about operating systems? What about the classical design of operating systems makes this difficult on it? Yeah, we're getting closer to the right answer. I mean, this is not a trick question, right? I mean, the answer is for the operating systems aren't, we're never designed to do this, right? Operating systems were designed to manage physical machines, right? It's like, you gave me a machine. This is my machine to manage, right? Now suddenly we're telling it, no, no, no. You've got to share with this other machine, there's this other machine, and now actually, you know, I need to put somebody else in charge of you, right? So operating systems, you know, at least in the dawn of operating systems were designed to manage collections of physical hardware, and they're not used to sharing, right, these hardware resources. They're used to being the people who manage the sharing, right? That's the job of the operating system is to, you know, divide the physical resources between the applications that are running on top of it, right? But it's used to having this exclusive access, and yes, to using the privileged features of the machine in order to multiplex resources, right? That was why, you know, remember back, you know, three months ago, why do we give operating systems, why did you give the operating system this privilege? It's because you want it to make these decisions about resource allocation, right? That's why you granted it this privilege, and now we have to start watering that privilege down and make the operating system play nice with other things, right? So the goal of a virtual machine is we don't want to give the guest to us exclusive access to the underlying physical machine, right? And we'll talk a little bit about why this is. And the way that we do that, as somebody hinted, right, is that we have to deprivilege in some way the operating system. Because if I take an operating system that's designed to control a set of physical resources, and I try to run it alongside other operating systems, in the worst case, if I give it full privilege, it still has access to the whole machine, right? And so it can affect other virtual machines or the host OS, right? Which is what we don't want to have, right? We think, people sometimes talk about this as, you know, a way that the guest OS could pierce the virtual machine, right, and kind of get out and do things I don't want it to do, right? So what we do here is we've created a separate piece of software. So we're going to design, and this is essentially what companies like VirtualBox and VMware are selling, right? They're selling virtual machine monitors, right? A virtual machine monitor is a piece of software that's designed to create a virtualized hardware environment, right? And really the goal, the ultimate goal of these is to be able to run an unmodified or potentially lightly modified operating system inside of it, right? And to be able to present that operating system with the illusion of running inside a virtual machine that has access to a subset of the physical resources that are present on the machine. And if you do this well, you know, it's really pretty amazing how well it can work, right? Like I frequently have, you know, two or three different virtual machines running at the same time upstairs on my machine because I like to use them to kind of keep things organized, right? And again, the ultimate goal is to allow the guest OS to be run as an application, right? We're talking about, this is really, this lecture is really more focused on consumer virtualization. So the type of stuff you guys have been doing this semester, right? You have an application that you installed called VirtualBox that allows you to run another operating system, in this case Ubuntu or Linux inside on your machine and you can essentially run that anywhere, right? And this is kind of funny, right? Because we said at one point, you know, the operating system was just another program, right? That's, you know, this is kind of like the fullest extension of that, right? The operating system is a program. The program requires certain privileges to run, but if I'm careful about how I manage those privileges, I can actually get that program to run alongside other instances of itself or other programs running on the same machine, right? So this is kind of fun. So we'll come back to how, you know, later today and maybe on Monday morning, right? But let's talk about operating system problems with operating systems, cool. Yeah, okay, so there is, yes and no, right? So one of the things that's happened, right? So Guru is asking about how many people remember x86 privilege rings? I'm not really gonna talk about x86 privilege rings, but one of the things that's happened over time is that as hardware virtualization started to catch on, it became a popular way to, for a variety of reasons which we're about to discuss, right? It sort of weaknesses with traditional operating systems and the isolation of the operating system and some other issues, so we're gonna get to this in terms of why we wanna virtualize. But once people started to create virtual machines and become interested in virtualization, hardware makers started to improve their architectures in ways that facilitated this. So I think that x86 privilege rings were originally designed in a way that helped make this possible, but the problem is that if you take an operating system that's used to running in the lowest ring and try to run it with less privilege, it doesn't work. And so there are some changes you have to make regardless. So that's a technique that we'll come back to as well. So there are two potential goals. One is that I could take an operating system and I wanna run it completely unmodified and that's what people sometimes call full hardware virtualization. I don't want the operating system to know it all. And then another approach that started to happen also is that operating systems started to realize that this was a popular thing to do and they started to modify their behavior in order to facilitate virtualization. So I can get a version of Linux that's been designed to run in a virtualized environment. We'll come back to this, but that's a very good question. So there have been both hardware changes and operating system changes that have occurred to facilitate virtualization over particularly over the last couple of decades since it started to become more popular. All right, so again, I hope by this point we can agree that operating systems are pretty cool and that they do a really nice job of providing some of these nice abstractions as well as managing the resources of the system. But let's talk about some problems with operating system design. So what's one potential problem with operating systems that, so it's kind of this question of like why would we actually want to virtualize in the first place? Got operating systems, they work well on real machines. What are some of the things that might have driven us to this length? Let's try to, after three months of loving them, let's try to be critical of our operating system friends. Yeah, okay, yeah, so you can potentially have these couplings between operating systems and applications. So not only do some applications are some applications not good at running other operating systems, what else is potentially true? Do, does every application you've ever used run on every operating system ever created? No, right, maybe you're trying to run some old game that stopped working after Windows fixed problems with their memory management system, right? Or maybe you're trying to run a software toolkit that only runs on Mac, right? Or runs something that runs only on Linux, right? So yeah, there are these kind of separate pools of software that developed because, because people targeted certain platforms, right? If you're someone like me who avoids installing Microsoft applications like the Plague, that sometimes people send you a Word document that you for some reason have to use, then you have a virtual machine sitting there that runs Windows 7 and has Word installed and you fire it up for five minutes. Or when you come across that increasingly rare website that only works on Internet Explorer, right? There's like five or six of them loved out there, right? But they still do exist, I found a few. Okay, so that's one problem, what else? What are other problems with our brand, Sarah? Yeah, so people, yeah, so it's a geeky people, like I think including Sarah herself, have done this thing where they like, will take their computer and allow it to like, boot several different operating systems, right? So this is kind of like, I don't know, it's like a committee approach to managing resources, like okay, I'm running Windows for on, I got tired of Windows, I'm gonna depose Windows and I'm gonna put Ubuntu in charge for a while. But what's annoying about that? What do you have to do in order to do that on it? You have to restart the system and that's kind of a pain, right? And then also you lose all the state that you had and whatever, so yeah, so I might wanna run multiple operating systems on the same machine at the same time, right? And not, I think, well, that's still probably a pretty geeky thing to do though, right? So it's not like a common use case. Varun, what about other problems with operating systems? I wanna throw something. Shaker, I keep calling you Varun, I'm sorry. Yeah, you do, Windows actually does have a command line, it's just terrible to you, yeah, yeah. Yeah, so this is one of the things, so one of the groups of problems that we can talk about is this idea of sort of what's called hardware coupling, right? So once I load a particular operating system, I've kind of coupled whatever resources are on that machine to be managed by that operating system, right? So this provides a couple of problems. First of all, I can't, as Sarah wants to do, I can't run multiple versions of Windows on the same machine at the same time, right? But that's, again, that's a little geeky. It can also be very difficult to transfer software setups from machine to machine, right? So if I've gotten a particular, let's say I've got a web server and I've got it up and running and I've got it running on this machine and then someone says, actually, no, we need to move that to a new machine or we need to upgrade the operating system and suddenly all my components break, right? And then it can also be very messy or annoying to adjust hardware resources to meet the system's needs, right? So how do you add RAM to a system? How do you actually do that? How many people have done this before, right? This is my, if you take anything, well, hopefully it'll take other things away from the class, but if you ever have to help a family member with their computer, this is my number one suggestion, right? It's just install more RAM. It always works, right? It is the number one thing to do and it'll get you at least two or three years of peace and quiet from that person before the machine starts, before all the malware that they've installed starts to take over that new RAM that you've installed, right? But how do you do it? Like, what's the process of installing RAM on one of your machines? Andrew, like, how would you, let's say you got a laptop, looks like a nice laptop, starts to go a little slow. How do you put new RAM in there? Yeah, yeah, so require sticking your hand in the box and mucking around, right? Like, I gotta like, you know, shut the machine down. Well, I don't know. You probably should shut the machine down. People will probably try this with the machine running. It'd be kind of interesting to see what would happen. But anyway, I mean, it requires stopping the machine, putting in new RAM, and then what I've done is I've got a machine that has RAM, but that machine now has the RAM that I just bought, right? So later I decide, well, I want this other, this other machine's running slow and it needs more RAM and I stopped working on this one machine. It's very difficult. So essentially what I'm doing is I'm coupling between the operating system and whatever the operating system is doing and the hardware resources that I've allocated to it, right? I mean, it might be nice to be able to be more flexible, to be able to say, okay, well, this machine's running slow, I'm gonna give it some more RAM, right? Or, you know, this machine is heavily loaded right now and so I'm gonna devote more of the physical resources to it, right? And yeah, so this requires this sort of static, upfront provision of machine resources, right? Which can be very difficult, especially given the fact that, you know, particularly on server setups, a lot of servers see very, very, you know, very, very sporadic and variable load, right? So isolating applications from each other is also a problem, right? And you think to some degree that operating, and so operating systems provide a form of isolation, right? And in general operating systems provide kind of some contract applications that says, here's the things that other applications shouldn't be able to do to you, right? It's kind of this like non-molestation agreement, right? But operating systems also still leak a lot of information between applications, which might be a security problem if you're really worried about your data, right? So for example, if you're running some sort of very sensitive application and you go to some cloud hosting provider and they say, oh yeah, sure, I'll run your application on the same physical machine with a bunch of other stuff, right, including stuff written by your competitor and maybe applications written by unknown bad guys or whatever, you may not be super happy about that, right? Because operating systems do sometimes leak information and there are various, if you look in the security community, there are all sorts of interesting sort of side channel attacks in different ways that you can use some visibility you have in the operating system to gain information about what other applications on the same machine are doing, right? Also, I mean, this has gotten a little bit better maybe, but if you grew up when I did, you remember these incredible headaches that you would go through trying to get like two useful applications to install at the same time on Linux, right? It was like almost impossible, right? You'd spend like a day getting cool thing A to work and then you'd start trying to get cool thing B to work and cool thing B would require you to install half the things you installed for cool thing A, which then wouldn't work anymore, require a new version of this library, which is completely the old one. So this could be kind of ugly, right? And this is another way that applications are not isolated from each other, right? Because applications require usually some configuration of the machine, some sort of library, some sort of tools to work, right? And as we talked about before, in certain cases, the environment that's required by a particular application may be so specific that the vendors aren't even willing to support it if you put it on a machine and try to run it next to anything else, right? So again, I mean, do not try to run your internet server, your web server, and your database server on the same machine because you will not get support from either of the companies that you spent thousands of dollars to buy these applications for. So back before virtualization, what did this mean, right? Let's say I'm a company and I've got a little web application I wanna run. I need a file server, I need a web server and I need a database server to run my application. What do I have to do? Robert, buy three machines. Yep, buy three machines, install potentially three different versions of an operating system that's the exact version that that system likes and then hire three separate people who are experts at those operating systems to maintain, right? And then what's the problem with that? I mean, that doesn't sound that bad, right? We've created some jobs, right? What becomes a problem other than the fact that you have three system administrators, right? Who have to get along and that's very difficult because you know how system administrators are. What's the other problem with that? What's being wasted here, potentially, Tao? What's that? I still can't hear you. Yeah, I mean, it could be expensive to buy three machines, but what am I willing to bet about at least one of those three machines, Sam? Yeah, I'm gonna bet you that one of those three machines is gonna be underutilized most of the time, right? Whatever part of the system that's not the bottleneck is gonna be underutilizing. The other two machines are gonna be sitting there and there's nothing I can do about it, right? I've got two machines that are the bottleneck. They're completely red-lined and one machine is just sitting there. Once the system administrator is taking three hour lunches and the other two are working overtime. So yeah, so this is kind of an issue. So these are some of the reasons for this, right? And these are some of the, along with trying to address some of those problems, there are also just these nice, cool things that we can now do, right? So for example, how many people have ever, other than for this class, ever sort of downloaded a whole prepackaged software environment to fool around with something online before, right? So this is now starting to become a little bit more common and I think it's really cool, right? So you'll go, for example, and there's some company that's trying to sell you some new software tool and rather than having a webpage that's this long with all the instructions that you need to follow in order to get their tool to install, they just say, hey, here's a virtual box appliance, right? You can download it, you run it at virtual box, it boots up, everything's installed, you can play around when you're done, you can delete it. You didn't have to make a single change to your system, right? Or any system that you care about to experiment with their software, so that's kinda neat, right? We can also, again, we can do this provisioning, right? So we can take these big servers, right? And we can try to pack those servers with smaller machines in a way that maximizes the usage of the server resources, right? So rather than having three servers that are all lightly loaded, I can put all those machines onto one big machine and I can potentially divide the larger machine's resources at runtime between the smaller machines in a way that tries to maximize performance, right? So that's kinda cool. And also, again, I mean, I can take this entire machine, right, an entire server with all sorts of state, you know, applications that are installed, all the scripts that I need to run, and I can just put it somewhere else, right? I can package it up, I can take it offline, I can move it to another machine, right? So these things just are, you know, this kind of a system administrator's dream, right? Like, I need to take a machine offline, I migrate all the resources off it, I do some stuff with it, I move everything back, right? So this stuff gives us some really, really nice powers. It's really, again, it's almost like being able to take an entire machine, right? It's like, you know, if Andrew wanted to reinstall his laptop, right? Or he needed to, you know, he had something that was running on his laptop, some sort of server that was, you know, I don't know, very important to him, right? He could take that, and he could just squeeze it on to Jen's laptop, right? He could do whatever he needed to do, and then he could take it and put it back, right? So this is kind of a neat idea. So it's also interesting to know the virtualization is not a new idea, right? And they're actually, you know, if you're a sort of history of operating systems geek, they like to point out all these, you know, places in the past where people had similar ideas and these early systems that were built to facilitate a lot of these same things. And in 1974, there was a paper that essentially identified the three requirements for a virtual machine monitor, right? So if I'm going to write a piece of software that's going to create a virtual machine, it has to be able to do three things, right? The first thing is that the software that runs inside my virtual machine should execute identically to the way it would on real hardware. Modulo timing, right? Like we would assume the timing is not going to be the same. The virtual machine may be slower, probably slower, right? The modulo timing, the operating system that runs inside my virtual machine should not be able to detect that it is running on virtualized hardware as opposed to running on physical hardware. There should be no difference in its execution, right? At the same time, I also need, I also want to achieve good performance, right? And in order to do this, right, the big trick that makes virtualization work is that, and the big thing that distinguishes virtualization from something like simulation, for example, is that on a virtualized machine, most instructions execute on physical hardware, right? They're not emulated, they're not simulated by the virtual machine monitor. I want to allow as many instructions as possible to use the hardware resources because that's what's fast, right? So as much as possible, I want to allow instructions that are executed inside the virtual machine to run on the physical machine, right? And there's some exceptions to this, which we'll talk about. And the virtual machine monitor should be in control of all the hardware resources that are provided to it, right? So whatever hardware I've been given, I should not allow the code that's running inside the virtual machine to affect stuff outside of it, right? So if I give a virtual machine on my system a gigabyte of RAM, it shouldn't suddenly be consuming two, right? Like that's the physical machine, right? Like your physical machines don't get to start and make up new RAM, right? And the virtual machine shouldn't eat, right? So as Guru and some other people pointed out earlier, there's two general sort of approaches to virtualization, right? The full virtualization approach says, I want to be able to take an unmodified guest operating system, right? So I take a binary, right? I take a binary operating system that's been compiled for real hardware and I can run it inside my virtual machine, right? That is the idea behind full virtualization. Paravirtualization, on the other hand, so how many of you have heard of Zen? Okay, so Zen, and there were some other systems that were the first to propose this paravirtualization approach, which says that their point was kind of like full virtualization is hard, right? And it could potentially cause some significant performance overheads. And so let's compromise just a little bit, right? Let's just have some small changes that I'm gonna make to the guest operating system, right? So now the guest operating system is going to be compiled for a virtual environment, right? But if I make some small changes to the guest operating system, I can potentially improve performance quite a bit, right? So this is, and those small changes are made specifically to improve interaction with the virtual machine monitor and make virtualization easier, right? So we're gonna talk about full virtualization, like, so it's kind of, well, I don't know, they're both interesting, right? So again, so the goal of full virtualization is to run the unmodified operating system in a virtual machine that essentially appears to be an application running next to other applications on the host operating system, right? So why is this difficult? Let's say, I've got my virtual machine monitor and I simulate boot somehow and now I've got my guest operating system that's running inside of it, why is this so difficult? What's the challenge here? What is the guest operating system going to try to do? Yeah, it's gonna try to manage the hardware resources on the machine, right? All of them, potentially, right? It's gonna say, hey, I'm in charge on the operating system, right? This is an interesting machine you have here, right? You know, okay, it's only got a gigabyte of memory, but oh, this is this TLB, for example. That's mine to manage, right? Hey, I can put things in the TLB and take them out or whatever, so yeah, I mean, the guest OS is going to try to do this and so there's a couple of bits of subtlety here, right? So first of all, the guest OS is gonna try to handle and manage virtual resources on the machine, right? The next thing that's very interesting, right? So let's say I have a, let's say I have a application that's running inside my virtual machine and let's say, let's use MIPS as an example. Let's say that application makes a system call, right? So how does it do that, first of all? What's the instruction on MIPS that I used to initiate a system call? CIS call, right? So normally what should happen, this is a good review, what should happen when the CIS call instruction is executed, Spencer? Yeah, you guys remember what happens? You know, I, you know, this is a software exception. I'm supposed to jump to a particular point of code and start executing instructions, right? You know, who installs those exception handlers? Yeah, that's part of the operating system code, okay? So now I've got a application running inside my virtual machine, okay? So now that application, right? So the virtual machine is running, that application wants to do a system call. Who should handle that system call? Yeah, the guest operating system, right? But if I don't do anything clever, where is, what's gonna happen when I execute that system call? Where is the hardware, what is the hardware going to try to do? Remember, this is hard, this is hardwired into the hardware, right? What will the hardware try to do? There's someone new, Wendley. Track it to the hostOS? Yeah, so the hardware wants to go to the hostOS, right? The hardware is hardwired. The hostOS installed those exception handlers there, right? So the hardware wants to go to the hostOS, right? The thing I need to do is I need to get the guestOS to handle the trap, right? Now, okay, just to blow your mind a little bit more, right? So what happens if the virtual machine monitor itself issues a system call? Who should handle that? What's that? I hear mixtures of two answers. The host, right? So, you know, because the virtual machine might cause a page fall. Sorry, the virtual machine monitor. Virtual machine monitor might cause a page fall. The virtual machine monitor might have files that it uses to run. It's an application running on the system, right? So traps that are generated inside the guestOS need to be handled by, sorry, traps that are, man, this stuff even bends my brain a little bit. Traps that are generated by applications running inside the virtual machine need to be handled by the guest operating system, right? Not by the host operating system. The other thing that's hard is that the guest operating system is gonna try to execute these privileged instructions, right? So when the guest operating system executes a privileged instruction, let's say the guest operating system tries to do something like modify the TLB, right? Let's say, you know, again, this is, okay, fine. This is not 86 anymore, right? Why could it be a problem for the guest operating system to try to change virtual address mappings on the machine? What could that allow it to do? So first of all, do I need to allow the guest operating system to alter virtual memory mappings on the machine, Nick? Yeah, well, the answer is yes, right? Sometimes, right? Because it needs to do that to handle traps inside the guest operating system, right? If a page fault occurs that's generated by an application that's running inside the virtual machine, the guest operating system needs to adjust the underlying physical hardware accordingly, right? But what could, if I gave the guest operating system permission to modify the TLB in any way, what could that allow it to do, Tim? Right, if I can load translations in the TLB, I can load translations to point to anywhere in memory, right? So suddenly, hey, my virtual machine doesn't have a gigabyte of memory anymore, now it's got four, right? Because I can see the whole machine and I can see things that are outside of my machine, right? So this is essentially what happens if I try to run the guest OS and I just give it kernel privileges, right? Let's say, I just say, okay, I'm gonna allow the guest OS to just run just like the host OS does, right? With kernel privileges. So what happens there is that I potentially give it an access to the entire machine and that violates that safety requirement that I have, right? If I try to run the guest OS with user privileges, that's generally okay, but I need to figure out what to do about these privilege instructions, right? So let's talk a little bit about this, right? So what would I like to happen? My guest operating system is running inside the virtual machine. So here's my trick, right? I have not given it kernel privilege, right? Spencer. Well, who is it gonna be caught by first, right? So if I'm running in user privilege, the guest OS is running inside the virtual machine, it executes a privileged instruction, who catches it first? The host OS, right? And then who needs to handle it? The virtual machine monitor, right? So ideally what happens is the CPU is going to trap, right? The trap is going to be initially handled by the, so this is what I want to happen, right? Sorry, I got ahead of myself, right? What I want to happen is I want the trap to be handled by the virtual machine monitor, right? Because this trap is going to change the state of the virtual machine, right? So the virtual machine monitor is going to check and make sure the guest OS is doing something legitimate. So what's an illegitimate thing that it could try to do that we just discussed? What's a trap that I might need to kill the guest operating system for? Yeah. What's that? Well, not writing to the TLB, writing what to the TLB? Nothing. Yeah, what can it, so I want to allow it to write to the TLB, right? But what do I not want it to allow it to write to the TLB? Paul. Haha, addresses, addresses where? What, I mean what memory should it not be able to see, right, this is the guest operating system, right? It should not be able to load a translation that points where? Yeah, outside of the addresses of the memory that's been allocated for the virtual machine, right? So I need to make sure that it's doing something legitimate. If it is doing something legitimate, that remember the virtual machine monitor is adjusting the state of this virtual machine, right? So if the trap that was generated by the guest OS is legitimate, I adjust the state of the virtual machine, right, and I continue, okay? So any instruction that has this property that can be handled this way is referred to as classically virtualizable, right? And it lends itself to this technique, right? Where traps are vectored to the virtual machine monitor, the virtual machine monitor handles them, checks the trap, sees, you know, if the guest OS is doing something legitimate and then adjusts the state of the world, right? And this approach is called trap and emulate, right? So I trap the instruction, right? I trap all privilege instructions because I'm gonna run the guest operating system without kernel privilege, right? And those traps are passed to the virtual machine monitor. The virtual machine monitor essentially emulates the effect of the instruction on the virtual machine, right? All right, what time is it? Yeah, so, okay, so now let's just look at one other corner case, right? So let's say that this happens, right? And the virtual machine, the trap is handed to the virtual machine, what are the two things that I might need to do? What are two, so this is, again, mind melt. So what are the two things that can now cause a trap inside the virtual machine? Broadly speaking, right? Traps could be generated by what or what, right? There would need to be handled differently, Tim. What's one source of traps? Well, these are all exceptions, right? But the question is who was running when the exception happened, right? No, no, so these are things that are handed to the VMM, right? Traps that are generated by the virtual machine monitor will be handled by who, the host, right? But what is running, I mean, again, broadly speaking, what is running inside the virtual machine? That would create two different types of traps. Mukta, what's one thing? The best of us, right? So the best of us is one source of traps. What's the other source of traps? Applications, right? So this now causes a difference in handling inside the virtual machine monitor. If the trap is caused by an application, the trap actually needs to be handled by the guest operating system, right? So remember, on physical hardware, traps that are caused by applications are handled by the operating system. On virtual hardware, I have to do the same thing, right? The best of us is gonna handle the trap. The best of us isn't going to know that the trap was first handled by the host operating system, then vector to the virtual machine monitor and then hand it off to the guest OS, right? It's just gonna run and handle the trap, right? However, if the trap was generated by the guest OS itself, remember, the guest OS is running without kernel privilege so it's gonna generate these traps, then those traps are handled directly by the virtual machine monitor itself, right? Because those traps affect the hardware, right? They affect the virtual machine and the virtual machine monitor is implemented, right? I know this stuff doesn't make sense the first time. You see it. It didn't make sense to me at least the first 10 times I thought about it, right? But it actually does make a certain amount of sense. All right. Let's stop here. And on Monday morning, we will resume and we'll finish talking about the layered nature of traps on virtual machines.